creacion de consola windows server 2003

DESARROLLO DE WINDOWS SERVER 2003 proporcionan experiencia práctica para muchas configuraciones de sistemas operativos. Las guías comienzan estableciendo una infraestructura de red común a través de la instalación de Windows Server 2003, la configuración de Active Directory®, la instalación de una estación de trabajo Windows XP Professional y, por último, la incorporación de esta estación de trabajo a un dominio. Las guías detalladas posteriores asumen que posee esta infraestructura de red común. Si no desea seguir esta infraestructura de red común, tendrá que efectuar las modificaciones pertinentes mientras utiliza estas guías.
La infraestructura de red común requiere que se sigan las instrucciones de las guías siguientes.
Una vez configurada la infraestructura de red común, pueden utilizarse todas las guías detalladas adicionales. Tenga en cuenta que algunas guías detalladas pueden tener requisitos previos adicionales además de los requisitos de infraestructura de red común. Todos los requisitos adicionales se indicarán en la guía detallada específica.
Microsoft Virtual PC


Las guías detalladas de desarrollo de Windows Server 2003 se pueden implementar en un entorno de laboratorio físico o mediante tecnologías de creación de entornos virtuales como Microsoft Virtual PC 2004 o Microsoft Virtual Server 2005. La tecnología de máquina virtual permite a los usuarios ejecutar varios sistemas operativos simultáneamente en un único servidor físico. Virtual PC 2004 y Virtual Server 2005 están diseñados para aumentar la eficacia operativa de las pruebas y desarrollo de software, la migración de aplicaciones heredadas y los escenarios de consolidación de servidores.
En las guías detalladas de desarrollo de Windows Server 2003 se asume que todas las configuraciones se realizarán en un entorno de laboratorio físico, aunque la mayoría de ellas se pueden aplicar a un entorno virtual sin necesidad de modificarlas.
La aplicación de los conceptos proporcionados en estas guías detalladas a un entorno virtual se escapa al alcance de este documento.
Notas importantes


Las compañías, organizaciones, productos, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares y datos mencionados aquí son ficticios. No se pretende indicar, ni debe deducirse ninguna asociación con compañías, organizaciones, nombres de dominio, direcciones de correo electrónico, logotipos, personas, lugares o datos reales.
Esta infraestructura común está concebida para su uso en una red privada. El nombre ficticio de la compañía y el nombre DNS (Sistema de nombres de dominio) utilizados en la infraestructura común no están registrados para su uso en Internet. No debe utilizar estos nombres en una red pública ni en Internet.
El objetivo de la estructura del servicio Active Directory para esta infraestructura común es mostrar cómo funciona la administración de cambios y configuración de Windows Server 2003 con Active Directory. No se ha diseñado como un modelo para configurar Active Directory en una organización.
Introducción


La Consola de administración de Directivas de grupo (GPMC) de Microsoft es una nueva herramienta para la administración de Directivas de grupo que ayuda a los administradores a administrar una empresa de forma más rentable al mejorar la capacidad de administración y aumentar la productividad. Consta del nuevo complemento Microsoft Management Console (MMC) y de un conjunto de interfaces programables mediante secuencias de comandos.
GPMC simplifica la administración de la Directivas de grupo al proporcionar un único lugar para administrar aspectos esenciales de la Directiva de grupo. Atiende los requisitos principales de implementación de la Directiva de grupo exigidos por los clientes mediante las siguientes funciones.
• Una interfaz de usuario (IU) que simplifica enormemente el uso de la Directiva de grupo.
• Operaciones de copia de seguridad/restauración de objetos de Directiva de grupo.
• Operaciones de importar/exportar y copiar/pegar objetos de Directiva de grupo y filtros del Instrumental de administración de Windows (WMI).
• Administración simplificada de la seguridad relacionada con la Directiva de grupo.
• Informes HTML (Lenguaje de marcado de hipertexto) de la configuración de objetos de Directiva de grupo y datos del Conjunto resultante de directivas (RSoP).
• Secuencias de comandos de tareas relacionadas con directivas expuestas dentro de esta herramienta (y no de la configuración de un objeto de Directiva de grupo).
Hasta ahora, los administradores necesitaban utilizar varias herramientas de Microsoft para administrar la Directiva de grupo, como los complementos Usuarios y equipos de Active Directory, Sitios y servicios de Active Directory y Conjunto resultante de directivas. GPMC integra las funciones de Directiva de grupo existentes en estas herramientas en una única consola unificada con nuevas capacidades.
Una característica integrada en GPMC es la compatibilidad para administrar varios dominios y bosques, lo que permite a los administradores administrar la Directiva de grupo de toda la empresa. Los administradores tienen un control total sobre los bosques y dominios incluidos en GPMC, lo que permite mostrar únicamente las partes pertinentes de un entorno.
Nota: en esta guía detallada sólo se ofrecen instrucciones sobre el uso de GPMC para administrar objetos de Directiva de grupo. No se incluyen instrucciones sobre su configuración. Para obtener información sobre cómo configurar objetos de Directiva de grupo, consulte la Guía detallada de introducción al conjunto de características de Directiva de grupo.
Requisitos previos
• Parte 1: Instalar Windows Server 2003 como un controlador de dominio

• Guía detallada de configuración de controladores de dominio adicionales

• Guía detallada de administración de Active Directory

• Guía detallada de uso del Asistente para delegación de control

• Guía detallada de introducción al conjunto de características de Directiva de grupo

• Guía detallada de aplicación de directivas de contraseñas seguras

Principio de la página
Instalar y configurar GPMC


Instalar GPMC
La instalación de GPMC es un proceso simple que requiere la ejecución de un paquete de Windows Installer (.MSI). Para descargar la última versión, visite el sitio de Windows Server System para la administración de Directivas de grupo en
Para instalar la Consola de administración de Directivas de grupo
1. En el servidor HQ-CON-DC-01, desplácese a la carpeta que contiene gpmc.msi, haga doble clic en el paquete gpmc.msi y, a continuación, haga clic en Siguiente.
2. Haga clic en Acepto para aceptar el Contrato de licencia de usuario final (CLUF) y, a continuación, haga clic en Siguiente.
3. Haga clic en Finalizar para completar la instalación de GPMC.
Una vez finalizada la instalación, la ficha Directiva de grupo que aparecía en la página Propiedades de sitios, dominios y unidades organizativas de los complementos de Active Directory se actualiza con un vínculo directo a GPMC. La funcionalidad que existía anteriormente en la ficha Directiva de grupo ya no está disponible, puesto que todas las funciones para administrar la Directiva de grupo están disponibles en GPMC.
Para abrir el complemento GPMC
1. En el servidor HQ-CON-DC-01, haga clic en el botón Inicio, en Ejecutar, escriba GPMC.msc y, a continuación, haga clic en Aceptar.
Nota: puede utilizar también alguno de los métodos siguientes para ejecutar GPMC.
• Haga clic en el acceso directo Administración de directiva de grupo en la carpeta Herramientas administrativas en el menú Inicio o en el Panel de control.
• Crear una consola MMC personalizada: haga clic en el botón Inicio y en Ejecutar, escriba MMC y, a continuación, haga clic en Aceptar. Seleccione Archivo, haga clic en Agregar o quitar complemento y luego en Agregar. Haga clic para resaltar Administración de directiva de grupo, haga clic en Agregar, en Cerrar y después en Aceptar.

Configurar GPMC


para varios bosques
Se pueden agregar fácilmente varios bosques al árbol de la consola GPMC. De forma predeterminada, sólo se puede agregar un bosque a GPMC si existe una relación de confianza bidireccional con el bosque del usuario que ejecuta GPMC. Puede habilitar de manera opcional GPMC para que funcione sólo con una relación de confianza unidireccional o incluso sin que exista ninguna relación de confianza. La incorporación de un bosque adicional a GPMC se realiza resaltando Administración de directiva de grupo en la raíz del árbol, seleccionando Acción del menú contextual y haciendo clic en AddForest. Como el entorno de ejemplo sólo contiene un bosque, la ejecución de estos pasos se escapa al alcance de esta guía detallada.
Nota: si agrega bosques sin relación de confianza, algunas funciones no estarán disponibles. Por ejemplo, no estará disponible la característica de creación de modelos de Directiva de grupo y no será posible abrir el Editor de objetos de Directiva de grupo para los objetos de Directiva de grupo del bosque sin relación de confianza. El escenario de bosque sin relación de confianza sirve principalmente para habilitar la copia de objetos de Directiva de grupo entre bosques.
Administrar varios dominios simultáneamente


GPMC permite administrar varios dominios al mismo tiempo, con cada dominio agrupado por bosque en la consola. De forma predeterminada, sólo se muestra un dominio en GPMC. Cuando inicie por primera vez GPMC mediante el complemento preconfigurado (gpmc.msc) o una consola MMC personalizada, GPMC mostrará el dominio que contiene la cuenta de usuario utilizada para iniciar GPMC. Puede especificar dominios en cada uno de los bosques que desee administrar mediante GPMC agregando o quitando los dominios mostrados en la consola.
Nota: puede agregar dominios con relaciones de confianza externas, aunque no mantenga una relación de confianza con todo el bosque. De forma predeterminada, debe haber una relación de confianza bidireccional entre el dominio que desea agregar y el dominio del objeto de usuario. También puede agregar dominios en una relación de confianza unidireccional deshabilitando la característica de detección de relaciones de confianza de GPMC, en el cuadro de diálogo Opciones del menú Ver. Para agregar dominios con relaciones de confianza externas, primero debe utilizar el cuadro de diálogo AddForest para agregar un dominio de un bosque que contenga los dominios con relaciones de confianza externas. Una vez agregado el bosque, puede agregar todos los dominios de ese bosque en los que se confíe haciendo clic con el botón secundario del mouse (ratón) en el nodo Dominios y haciendo clic en Show Domains.
Para agregar el dominio secundario vancouver.contoso.com a la consola
1. En la ventana Administración de directiva de grupo, haga clic en el signo más (+) situado junto a Bosque:contoso.com para expandir el árbol y, a continuación, haga clic en el signo más (+) situado junto a Dominios.
2. Haga clic con el botón secundario del mouse en Dominios y, a continuación, haga clic en Show Domains.
3. Active la casilla de verificación situada junto a vancouver.contoso.com como se muestra en la Figura 1 y, a continuación, haga clic en Aceptar.

Figura 1. Mostrar dominios
En cada dominio disponible en GPMC, se utiliza el mismo controlador de dominio para todas las operaciones del dominio. Éstas incluyen todas las operaciones en los objetos de Directiva de grupo, unidades organizativas, principales de seguridad y filtros de WMI que residen en ese dominio. Asimismo, cuando el Editor de objetos de Directiva de grupo se abre desde GPMC, siempre utiliza el mismo controlador de dominio empleado en GPMC para el dominio donde se encuentra el objeto de Directiva de grupo.
GPMC permite seleccionar el controlador de dominio que se utiliza para cada dominio. Tiene cuatro opciones para elegir.
• Usar el emulador de controlador de dominio principal (PDC) (opción predeterminada).
• Usar cualquier controlador de dominio disponible.
• Usar cualquier controlador de dominio que ejecute un sistema operativo de la familia Windows Server 2003. Esta opción es útil si va a restaurar un objeto de Directiva de grupo eliminado que contiene opciones de instalación de software de Directiva de grupo.
• Usar un controlador de dominio específico.
Para cambiar el controlador de dominio utilizado por GPMC para el dominio vancouver.contoso.com
1. En la ventana Administración de directiva de grupo, en la carpeta Dominios, haga clic con el botón secundario del mouse en vancouver.contoso.com y, a continuación, haga clic en Cambiar el controlador de dominio.
2. En el cuadro de diálogo Cambiar el controlador de dominio, haga clic en This domain controller y, a continuación, haga clic para resaltar hq-con-dc-03.vancouver.contoso.com como se muestra en la Figura 2.
3. Haga clic en Aceptar para continuar.


Administrar objetos de Directiva de grupo


Ver objetos de Directiva de grupo del dominio
En cada dominio GPMC proporciona una vista basada en directivas de Active Directory y de los componentes asociados a la Directiva de grupo, como objetos de Directiva de grupo, filtros WMI y vínculos de objetos de Directiva de grupo. La vista de GPMC es similar a la vista del complemento de MMC Usuarios y equipos de Active Directory en la que se muestra la jerarquía de unidades organizativas. Sin embargo, GPMC difiere de este complemento porque en lugar de mostrar usuarios, equipos y grupos en las unidades organizativas, muestra los objetos de Directiva de grupo que están vinculados a cada contenedor, así como los propios objetos.
En cada nodo de dominio de GPMC se muestran los siguientes elementos.
• Todos los objetos de Directiva de grupo vinculados al dominio.
• Todas las unidades organizativas de nivel superior y una vista de árbol de las unidades organizativas anidadas y los objetos de Directiva de grupo vinculados a cada unidad organizativa.
• El contenedor Objetos de Directiva de grupo que muestra todos los objetos de Directiva de grupo del dominio.
• El contenedor Filtros de WMI que muestra todos los filtros de WMI del dominio.
Para ver objetos de Directiva de grupo asociados a un contenedor determinado
1. En el árbol Dominios, haga clic en el árbol contoso.com. Los objetos de Directiva de grupo asociados al contenedor (la raíz del dominio) aparecen como se muestra en la Figura 3. Este concepto se puede aplicar a cualquier contenedor de dominio.


Para ver todos los objetos de Directiva de grupo asociados a un contenedor determinado
1. En el árbol Dominios, haga clic en el signo más (+) situado junto a contoso.com y, a continuación, haga clic en Objetos de Directiva de grupo.
Buscar objetos de Directiva de grupo

Se pueden buscar objetos de Directiva de grupo en el nivel de bosque o de dominio. Para ajustar los resultados de búsqueda en un conjunto grande de objetos de Directiva de grupo se pueden utilizar uno o varios parámetros de búsqueda.
Para buscar un objeto de Directiva de grupo específico en el bosque contoso.com mediante varios parámetros de búsqueda
1. En el árbol de la consola, haga clic con el botón secundario del mouse en Bosque:contoso.com y, a continuación, haga clic en Buscar.
2. En el cuadro Search item, seleccione Nombre del GPO, escriba Password para Valor y, a continuación, haga clic en Agregar.
3. En el cuadro Search item, seleccione Configuración del equipo, seleccione Seguridad para Valor y, a continuación, haga clic en Agregar.
4. Haga clic en Buscar. Los resultados deben ser similares a los que se muestran en la Figura 4.

Figura 4. Búsqueda de objetos de Directiva de grupo basada en criterios
5. Cuando obtenga los resultados de la búsqueda, puede realizar alguna de las operaciones siguientes:
• Para abrir el objeto de Directiva de grupo y modificarlo, haga clic en Editar.
• Para guardar los resultados de búsqueda, haga clic en Save results. En el cuadro de diálogo Save GPO Search Results, especifique el nombre del archivo donde desea guardar los resultados y, a continuación, haga clic en Guardar.
• Para desplazarse a un objeto de Directiva de grupo incluido en la búsqueda, haga doble clic en el objeto de Directiva de grupo en la lista de resultados de búsqueda.
• Para borrar los resultados de búsqueda, haga clic en Borrar.
• Para cerrar el cuadro de diálogo Search for Group Policy Objects, haga clic en Cerrar.

Definir el ámbito de los objetos de Directiva de grupo


El valor de la Directiva de grupo sólo resulta visible cuando se aplican correctamente los objetos de Directiva de grupo a los contenedores de Active Directory que desea administrar. El proceso de determinar qué usuarios y equipos van a recibir la configuración de un objeto de Directiva de grupo recibe el nombre de “definir el ámbito del objeto de Directiva de grupo”. El ámbito de un objeto de Directiva de grupo se define a partir de tres factores.
• Los sitios, los dominios o las unidades organizativas donde el objeto de Directiva de grupo está vinculado El mecanismo principal utilizado para aplicar la configuración de un objeto de Directiva de grupo a usuarios y equipos consiste en vincular el objeto a un sitio, dominio o unidad organizativa en Active Directory. La ubicación donde el objeto de Directiva de grupo está vinculado se denomina Ámbito de administración o SOM (también llamada SDOU en notas del producto anteriores). Hay tres tipos de SOM: sitios, dominios y unidades organizativas. Un objeto de Directiva de grupo puede estar vinculado a varios SOM y un SOM puede tener varios objetos de Directiva de grupo vinculados a él. Un objeto de Directiva de grupo debe estar vinculado a un SOM para que se aplique.
• Los filtros de seguridad del objeto de Directiva de grupo De forma predeterminada, a todos los usuarios autenticados que se encuentran en el SOM (y sus nodos secundarios) en el que está vinculado un objeto de Directiva de grupo se les aplica la configuración del objeto de Directiva de grupo. Puede delimitar aún más qué usuarios y equipos recibirán la configuración de un objeto de Directiva de grupo administrando permisos para el objeto de Directiva de grupo. Esto proceso se denomina filtrado de seguridad. Para que un objeto de Directiva de grupo se aplique a un usuario o equipo, ese usuario o equipo debe tener los permisos Leer y Aplicar directiva de grupo sobre el objeto. De manera predeterminada, los objetos de Directiva de grupo tienen permisos que admiten que el grupo Usuarios autenticados tenga esos dos permisos. Así es como todos los usuarios autenticados reciben la configuración de un nuevo objeto de Directiva de grupo cuando está vinculado a un SOM (unidad organizativa, dominio o sitio). No obstante, estos permisos se pueden cambiar para limitar el ámbito del objeto de Directiva de grupo a un conjunto específico de usuarios grupos o equipos incluidos en el SOM donde está vinculado.
• El filtro de WMI para el objeto de Directiva de grupo Los filtros de WMI permiten que los administradores determinen de forma dinámica el ámbito de los objetos de Directiva de grupo en función de sus atributos (disponibles en WMI) del equipo de destino. Un filtro de WMI consta de una o varias consultas contra el repositorio de WMI del equipo de destino que dan como resultado verdadero o falso. El filtro de WMI es un objeto independiente del objeto de Directiva de grupo en el directorio. Para aplicar un filtro de WMI a un objeto de Directiva de grupo, el filtro se vincula al objeto. Esto se muestra en la sección de filtros de WMI de la ficha Ámbito de un objeto de Directiva de grupo. Cada objeto de Directiva de grupo sólo puede tener un filtro de WMI, pero el mismo filtro de WMI puede estar vinculado a varios objetos de Directiva de grupo. Cuando un objeto de Directiva de grupo que está vinculado a un filtro de WMI se aplica al equipo de destino, el filtro se evalúa en dicho equipo. Si el filtro de WMI da como resultado falso, el objeto de Directiva de grupo no se aplica. Si da como resultado verdadero, el objeto de Directiva de grupo se aplica.
Para definir el ámbito del objeto Directiva de contraseñas del dominio incluido en la búsqueda anterior
1. En el panel de resultados Search for Group Policy Objects, haga doble clic en Directiva de contraseñas del dominio y, a continuación, haga clic en Cerrar.
Nota: cuando se cierra el cuadro de diálogo Search for Group Policy Objects, el foco pasa al objeto de Directiva de grupo anteriormente seleccionado en GPMC. Aparecerá la página GPO Scope, que se muestra en la Figura 5.


Para ver las directivas que aplica un objeto de Directiva de grupo
1. En el panel de resultados Directiva de contraseñas del dominio, haga clic en la ficha Configuración y luego en Show All. Aparecerá un resumen de todas las opciones de directiva definidas, como se muestra en la Figura 6. Las opciones no definidas no se muestran.


Herencia y orden de los vínculos de las directivas de objetos de Directiva de grupo
En la ficha Group Policy Inheritance para un contenedor dado se muestran todos los objetos de Directiva de grupo (salvo aquéllos vinculados a sitios) que heredan la configuración de los contenedores principales. En la columna de prioridad de esta ficha se muestra la prioridad general de todos los vínculos que se aplican a objetos de ese contenedor, teniendo en cuenta el atributo Orden de vínculos y Obligatoriedad de cada vínculo, así como el valor de Bloquear la herencia.
Para ver la herencia de directivas en un contenedor
1. En la ventana Administración de directiva de grupo, bajo el árbol contoso.com, expanda la unidad organizativa Cuentas y, a continuación, haga clic en la unidad organizativa Oficinas centrales, como se muestra en la Figura 7.


Si varios objetos de Directiva de grupo están vinculado al mismo contenedor y tienen opciones en común, debe haber un mecanismo que reconcilie la configuración. Este comportamiento se controla mediante el orden de vínculos. Cuanto menor sea el número de orden de un vínculo, más prioridad tendrá. La información sobre los vínculos de un contenedor determinado se muestra en la ficha Linked Group Policy Objects del contenedor. En este panel se indica si el vínculo es obligatorio, si está habilitado, el estado del objeto de Directiva de grupo, si se aplica un filtro de WMI, cuándo se ha modificado y el contenedor de dominio donde está almacenado. Los administradores o usuarios que tengan permisos delegados para vincular objetos de Directiva de grupo al contenedor pueden cambiar el orden de los vínculos resaltando un vínculo de objeto de Directiva de grupo y utilizando las teclas de dirección arriba y abajo para subir o bajar el vínculo en la lista.
Para cambiar el orden de los vínculos de directiva en un contenedor
1. En la pantalla Oficinas centrales, haga clic en Linked Group Policy Objects.
2. En la columna GPO, haga clic en Directivas vinculadas y, después, haga clic en la flecha arriba situada justo a la izquierda de la columna Orden de vínculos. Cuando termine, el orden de vinculación de los objetos de Directiva de grupo bajo la unidad organizativa Oficinas centrales aparecerá como se muestra en la Figura 8.


Hacer una copia de seguridad, restaurar, copiar e importar objetos de Directiva de grupo
Hacer una copia de seguridad de un objeto de Directiva de grupo
Cuando se hace una copia de seguridad de un objeto de Directiva de grupo se copian los datos del objeto en el sistema de archivos. La función de copia de seguridad sirve también como utilidad de exportación para los objetos de Directiva de grupo. Se puede utilizar una copia de seguridad de un objeto de Directiva de grupo para restablecerlo al estado de copia de seguridad o para importar la configuración de la copia de seguridad a otro objeto de Directiva de grupo.
Al hacer una copia de seguridad de un objeto de Directiva de grupo se guarda en el sistema de archivos toda la información almacenada en el interior del objeto. Esta información es la siguiente:
• El identificador único global (GUID) del objeto de Directiva de grupo y la configuración del objeto en el dominio
• La lista de control de acceso discrecional (DACL) del objeto de Directiva de grupo
• El vínculo del filtro de WMI, si hay alguno, pero no el filtro en sí
• Los vínculos a directivas de seguridad IP, si existe alguno
• El informe XML (Lenguaje de marcado extensible) de la configuración del objeto de Directiva de grupo, que se puede consultar como HTML desde GPMC
• La marca de fecha y hora de la copia de seguridad
• La descripción especificada por el usuario de la copia de seguridad
Al hacer una copia de seguridad de un objeto de Directiva de grupo sólo se guardan los datos almacenados dentro del objeto. Los datos almacenados fuera del objeto son los siguientes:
• Los vínculos a un sitio, dominio o unidad organizativa
• Los filtros de WMI
• La directiva de seguridad IP
Estos datos no están disponibles cuando se restaura la copia de seguridad al objeto de Directiva de grupo original o cuando se importa a un nuevo objeto.
Para hacer una copia de seguridad del objeto Directiva de contraseñas del dominio
1. En la ventana Administración de directiva de grupo, bajo el árbol contoso.com, haga clic en la carpeta Objetos de Directiva de grupo.
2. En la carpeta Objetos de Directiva de grupo, haga clic con el botón secundario del mouse en el objeto de Directiva de grupo Directiva de contraseñas del dominio y, a continuación, haga clic en Back Up.
3. En el cuadro de diálogo Back Up Group Policy Object, escriba c:\windows para Ubicación, escriba Copia de seguridad de la directiva de contraseñas del dominio para Descripción y, después, haga clic en Back Up.
4. Una vez realizada la copia de seguridad, haga clic en Aceptar para continuar.
Administrar copias de seguridad


En la misma ubicación del sistema de archivos se pueden almacenar varias copias de seguridad del mismo o de otro objeto de Directiva de grupo. Cada copia de seguridad se identifica mediante un identificador de copia de seguridad exclusivo. El grupo de copias de seguridad de una ubicación del sistema de archivos determinada se puede administrar con el cuadro de diálogo Manage Backups de GPMC o mediante interfaces programables con secuencias de comandos. El cuadro de diálogo Manage Backups está disponible haciendo clic con el botón secundario del mouse en el nodo Dominio o en el nodo Objetos de Directiva de grupo de un determinado dominio. Cuando se abre Manage Backups desde el nodo Objetos de Directiva de grupo, la vista se filtra automáticamente para que sólo aparezcan las copias de seguridad de los objetos de Directiva de grupo de ese dominio. Cuando se abre desde el nodo Dominio, en el cuadro de diálogo Manage Backups se muestran todas las copias de seguridad, sean del dominio que sean.
Para administrar las copias de seguridad de objetos de Directiva de grupo disponibles
1. En la ventana Administración de directiva de grupo, bajo el árbol contoso.com, haga clic con el botón secundario del mouse en la carpeta Objetos de Directiva de grupo y, a continuación, haga clic en Manage Backups. La ventana Manage Backups debe tener un aspecto similar al de la Figura 9.

Figura 9. Administrar copias de seguridad
2. En la ventana Manage Backups, haga clic para resaltar la Copia de seguridad de la directiva de contraseñas del dominio creada anteriormente y, después, haga clic en Ver configuración.
3. Revise la información detallada sobre el objeto de Directiva de grupo y, a continuación, cierre Internet Explorer.
Restaurar una copia de seguridad


Cuando se restaura un objeto de Directiva de grupo se vuelve a crear el objeto a partir de los datos incluidos en la copia de seguridad. Una operación de restauración se puede utilizar en las siguientes circunstancias: se ha hecho una copia de seguridad del objeto de Directiva de grupo pero se ha eliminado, o el objeto de Directiva de grupo está activo pero desea restablecerlo a un estado anterior conocido. Una operación de restauración reemplaza los siguientes componentes de un objeto de Directiva de grupo.
• La configuración del objeto
• La lista DACL del objeto
• Los vínculos de filtro de WMI (pero no los propios filtros)
La operación de restauración no restaura objetos que no forman parte del objeto de Directiva de grupo. Estos objetos incluyen vínculos a un sitio, dominio o unidad organizativa, filtros de WMI y directivas IPSec.
Para restaurar el objeto Directiva de contraseñas del dominio
1. En la ventana Manage Backups, haga clic en Restore.
2. Cuando se le indique, haga clic en Aceptar para restaurar la copia de seguridad seleccionada.
3. Haga clic en Aceptar cuando termine la restauración del objeto de Directiva de grupo.
4. En el cuadro de diálogo Manage Backups, haga clic en Cerrar.
Copiar un objeto de Directiva de grupo


La operación de copia permite transferir la configuración de un objeto de Directiva de grupo existente en Active Directory a un nuevo objeto de Directiva de grupo. El nuevo objeto de Directiva de grupo creado durante la operación de copia recibe un nuevo GUID y está desvinculado. Puede utilizar una operación de copia para transferir la configuración a un nuevo objeto de Directiva de grupo del mismo dominio, de otro dominio del mismo bosque o de un dominio de otro bosque. Como la operación de copia utiliza un objeto de Directiva de grupo existente en Active Directory como su origen, se requiere una relación de confianza entre los dominios de origen y de destino. Las operaciones de copia sirven para mover la Directiva de grupo de un entorno de producción a otro. Se utilizan también para migrar una Directiva de grupo que se ha probado en un dominio o bosque de prueba a un entorno de producción, siempre que exista una relación de confianza entre los dominios de origen y de destino.
Para copiar un objeto de Directiva de grupo
1. En el árbol contoso.com de la carpeta Objetos de Directiva de grupo, haga clic con el botón secundario del mouse en el objeto de Directiva de grupo Directivas de usuario forzadas y, después, haga clic en Copiar.
2. Haga clic en el signo más (+) situado junto a vancouver.contoso.com para expandir el dominio y, después, haga clic en el signo más (+) situado junto a Objetos de Directiva de grupo para expandir el árbol.
3. Haga clic con el botón secundario del mouse en Objetos de Directiva de grupo y, a continuación, haga clic en Pegar.
4. En Cross-Domain Copying Wizard, haga clic en Siguiente para continuar.
5. En la pantalla Specify Permissions, seleccione Use the default permissions for new GPOs (opción predeterminada)
Figura 10. Asistente para copiar entre dominios
6. Una vez analizado el objeto de Directiva de grupo original, haga clic en Siguiente para continuar.
7. En la pantalla Completing the Cross-Domain Copying Wizard, confirme la configuración y, a continuación, haga clic en Finalizar.
8. Cuando termine la operación de copia, haga clic en Aceptar.
Nota: el objeto de Directiva de grupo Directivas de usuario forzadas se ha copiado al dominio vancouver.contoso.com, pero no se ha desvinculado del contenedor.
Para vincular el objeto Directivas de usuario forzadas a la raíz de vancouver.contoso.com
1. Haga clic con el botón secundario del mouse en vancouver.contoso.com, haga clic en Link an Existing GPO, haga clic para resaltar Directivas de usuario forzadas y, a continuación, haga clic en Aceptar.
Importar un objeto de Directiva de grupo


La operación de importación transfiere la configuración a un objeto de Directiva de grupo existente en Active Directory mediante un objeto de Directiva de grupo de copia de seguridad en la ubicación del sistema de archivos como origen. Las operaciones de importación sirven para transferir la configuración de un objeto de Directiva de grupo a otro en el mismo dominio, en otro dominio del mismo bosque o en un dominio de un bosque diferente. La operación de importación siempre aplica la configuración de la copia de seguridad a un objeto de Directiva de grupo existente. Borra cualquier configuración que exista previamente en el objeto de Directiva de grupo de destino. La importación no requiere una relación de confianza entre el dominio de origen y el de destino; por tanto, sirve para transferir la configuración entre bosques y dominios que no tiene relaciones de confianza. La importación de la configuración a un objeto de Directiva de grupo no afecta a sus DACL, vínculos en sitios, dominios o unidades organizativas a ese objeto o vínculos a un filtro de WMI.
Para importar la Directiva de contraseñas del dominio de contoso.com a la de vancouver.contoso.com
1. En la ventana Administración de directiva de grupo, haga clic con el botón secundario del mouse en vancouver.contoso.com y, después, haga clic en Create and Link a GPO here.
2. En el cuadro de diálogo New GPO, escriba Directiva de contraseñas del dominio para Nombre y, a continuación, haga clic en Aceptar.
3. En Objetos de Directiva de grupo del árbol vancouver.contoso.com, haga clic con el botón secundario del mouse en el objeto de Directiva de grupo Directiva de contraseñas del dominio y, después, haga clic en Importar configuración.
4. En Import Settings Wizard, haga clic en Siguiente para continuar.
5. En la pantalla Backup GPO, haga clic en Siguiente para continuar sin realizar una copia de seguridad, ya que el objeto de Directiva de grupo no tiene actualmente definiciones de directiva.
6. Acepte la carpeta de copia de seguridad predeterminada, c:\windows, y, a continuación, haga clic en Siguiente para continuar.
7. Como la Directiva de contraseñas del dominio es la única copia de seguridad actual, está seleccionada de forma predeterminada. Haga clic en Siguiente para empezar a importar la configuración de este objeto de Directiva de grupo.
8. Haga clic en Siguiente cuando se analicen los principales de seguridad del objeto de Directiva de grupo y, después, haga clic en Finalizar.
9. Cuando concluya el Import Settings Wizard, haga clic en Aceptar.
Para comprobar la Directiva de contraseñas del dominio de vancouver.contoso.com
1. En Objetos de Directiva de grupo del árbol vancouver.contoso.com, haga clic en el objeto de Directiva de grupo Directiva de contraseñas del dominio y, después, haga clic en Show All en el panel de resultados.
Creación de modelos de objetos de Directiva de grupo
Modelos de Directiva de grupo
Los modelos de Directiva de grupo son una simulación de lo que ocurriría en circunstancias especificadas por un administrador. Requiere que exista al menos un controlador de dominio que ejecute Windows Server 2003, ya que esta simulación se ejecuta mediante un servicio que se ejecuta en un controlador de dominio con Windows Server 2003.
Con los modelos de Directiva de grupo, puede simular los datos de RSoP que se aplicarían a una configuración existente, o puede realizar análisis condicionales simulando cambios hipotéticos en el entorno de directorio y calculando el RSoP de esa configuración hipotética. Por ejemplo, puede simular cambios en la pertenencia a grupos de seguridad, o cambios en la ubicación del objeto de usuario o equipo en Active Directory. Fuera de GPMC, los modelos de Directiva de grupo reciben el nombre de RSoP - modo de planeamiento.
Para simular el efecto de objetos de Directiva de grupo
1. En la ventana Administración de directiva de grupo, haga clic en el signo menos (-) situado junto a Dominios para contraer el árbol.
2. En el árbol Bosque: contoso.com, haga clic con el botón secundario del mouse en Group Policy Modeling y, a continuación, haga clic en Group Policy Modeling Wizard.
3. En la pantalla Group Policy Modeling Wizard, haga clic en Siguiente.
4. En la pantalla Domain Controller Selection, deje la configuración predeterminada y haga clic en Siguiente.
5. En la pantalla Selección de equipo y usuario, bajo Información de usuario, haga clic en Usuario. Haga clic en Examinar, escriba Christine bajo Enter object name to select y, a continuación, haga clic en Aceptar. Active la casilla de verificación Ir directamente a la última página de este asistente sin recoger más información y, después, haga clic en Siguiente. Asistente para crear modelos de Directiva de grupo
6. En la pantalla Resumen de las selecciones, haga clic en Siguiente para iniciar la simulación.
7. Haga clic en Finalizar. El panel de la derecha contendrá los resultados de la simulación.

ACTIVE DIRECTORY

ACTIVE DIRECTORY
(AD) es el término que usa Microsoft para referirse a su implementación de servicio de directorio en una red distribuida de computadores. Utiliza distintos protocolos (principalmente LDAP, DNS, DHCP, Kerberos...).

Su estructura jerárquica permite mantener una serie de objetos relacionados con componentes de una red, como usuarios, grupos de usuarios, permisos y asignación de recursos y políticas de acceso.1

Estructura

Active Directory está basado en una serie de estándares llamados (X.500), aquí se encuentra una definición lógica a modo jerárquico.

Dominios y subdominios se identifican utilizando la misma notación de las zonas DNS, razón por la cual Active Directory requiere uno o más servidores DNS que permitan el direccionamiento de los elementos pertenecientes a la red, como por ejemplo el listado de equipos conectados; y los componentes lógicos de la red, como el listado de usuarios.

Un ejemplo de la estructura descendente (o herencia), es que si un usuario pertenece a un dominio, será reconocido en todo el árbol generado a partir de ese dominio, sin necesidad de pertenecer a cada uno de los subdominios.

A su vez, los árboles pueden integrarse en un espacio común denominado bosque (que por lo tanto no comparten el mismo nombre de zona DNS entre ellos) y establecer una relación de «trust» o confianza entre ellos. De este modo los usuarios y recursos de los distintos árboles serán visibles entre ellos, manteniendo cada estructura de árbol el propio Active Directory.

Funcionamiento
Su funcionamiento es similar a otras estructuras de LDAP (Lightweight Directory Access Protocol), ya que este protocolo viene implementado de forma similar a una base de datos, la cual almacena en forma centralizada toda la información relativa a un dominio de autenticación. La ventaja que presenta esto es la sincronización presente entre los distintos servidores de autenticación de todo el dominio.

A su vez, cada uno de estos objetos tendrá atributos que permiten identificarlos en modo unívoco (por ejemplo, los usuarios tendrán campo «nombre», campo «email», etcétera, las impresoras de red tendrán campo «nombre», campo «fabricante», campo «modelo», campo "usuarios que pueden acceder", etc). Toda esta información queda almacenada en Active Directory replicándose de forma automática entre todos los servidores que controlan el acceso al dominio.

De esta forma, es posible crear recursos (como carpetas compartidas, impresoras de red, etc) y conceder acceso a estos recursos a usuarios, con la ventaja que estando todos estos objetos memorizados en Active Directory, y siendo esta lista de objetos replicada a todo el dominio de administración, los eventuales cambios serán visibles en todo el ámbito. Para decirlo en otras palabras, Active Directory es una implementación de servicio de directorio centralizado en una red distribuida que facilita el control, la administración y la consulta de todos los elementos lógicos de una red (como pueden ser usuarios, equipos y recursos).

Intercambio entre dominios

Para permitir que los usuarios de un dominio accedan a recursos de otro dominio, Active Directory usa un trust (en español, relación de confianza). El trust es creado automáticamente cuando se crean nuevos dominios. Los límites del trust no son marcados por dominio, sino por el bosque al cual pertenece. Existen trust transitivos, donde los trust de Active Directory pueden ser un acceso directo (une dos dominios en árboles diferentes, transitivo, una o dos vías), bosque (transitivo, una o dos vías), reino (transitivo o no transitivo, una o dos vías), o externo (no transitivo, una o dos vías), para conectarse a otros bosques o dominios que no son de Active Directory. Active Directory usa el protocolo V5 de Kerberos, aunque también soporta NTLM y usuarios webs mediante autenticación SSL / TLS
Confianza transitiva
Las Confianzas transitivas son confianzas automáticas de dos vías que existen entre dominios en Active Directory.
Confianza explícita
Las Confianzas explícitas son aquellas que establecen las relaciones de forma manual para entregar una ruta de acceso para la autenticación. Este tipo de relación puede ser de una o dos vías, dependiendo de la aplicación.

Las Confianzas explícitas se utilizan con frecuencia para acceder a dominios compuestos por ordenadores con Windows NT 4.0.
Confianza de Acceso Directo

La Confianza de acceso directo es, esencialmente, una confianza explícita que crea accesos directos entre dos dominios en la estructura de dominios. Este tipo de relaciones permite incrementar la conectividad entre dos dominios, reduciendo las consultas y los tiempos de espera para la autenticación.
Confianza entre bosques

La Confianza entre bosques permite la interconexión entre bosques de dominios, creando relaciones transitivas de doble vía. En Windows 2000, las confianzas entre bosques son de tipo explícito, al contrario de Windows Server 2003.
editar Direccionamientos a recursos

Los direccionamientos a recursos de Active Directory son estándares con la Convención Universal de Nombrado (UNC), Localizador Uniforme de Recursos (URL) y nombrado de LDAP.

Cada objeto de la red posee un nombre de distinción (en inglés, Distinguished name (DN)), así una impresora llamada Imprime en una Unidad Organizativa (en inglés, Organizational Units, OU) llamada Ventas y un dominio foo.org, puede escribirse de las siguientes formas para ser direccionado:

• en DN sería CN=Imprime,OU=Ventas,DC=foo,DC=org, donde
o CN es el nombre común (en inglés, Common Name)
o DC es clase de objeto de dominio (en inglés, Domain object Class).
• En forma canónica sería foo.org/Ventas/Impr.
• me
Los otros métodos de direccionamiento constituyen una forma local de localizar un recurso

• Distinción de Nombre Relativo (en inglés, Relative Distinguised Name (RDN)), que busca un recurso sólo con el Nombre Común (CN).
• Globally Unique Identifier (GUID), que genera una cadena de 128 bits que es usado por Active Directory para buscar y replica
• r información
Ciertos tipos de objetos poseen un Nombre de Usuario Principal (en inglés, User Principal Name (UPN)) que permite el ingreso abreviado a un recurso o un directorio de la red. Su forma es objetodered@dominio
Diferencias entre Windows NT y Active Directory

A diferencia del anterior sistema de administración de dominios de Windows NT Server, que preveía únicamente el dominio de administración, Active Directory permite también crear estructuras jerárquicas de dominios y subdominios, facilitando la estructuración de los recursos según su localización o función dentro de la organización a la que sirven. Otra diferencia importante es el uso de estándares como X.500 y LDAP para el acceso a la información.

Interfaces de progre
mación
Las interfaces de servicio de Active Directory (ADSI) entregan al programador una interfaz orientada a objetos, facilitando la creación de programas de directorios mediante algunas herramientas compatibles con lenguajes de alto nivel, como Visual Basic, sin tener que lidiar con los distintos espacios de nom
bres.
Mediante las ADSI se permite crear programas que realizan un único acceso a varios recursos del entorno de red, sin importar si están basados en LDAP u otro protocolo. Además, permite generar secuencias de comandos para los adm
inistradores.
También se puede desarrollar la Interfaz de mensajería (MAPI), que permite generar programas MAPI.
Requisitos de instalación
Para crear un dominio hay que cumplir, por lo menos, con l
os siguientes requisitos recomendados:
• Tener cualquier versión Server de Windows 2000, 2003 (Server, Advanced Server o Datacenter Server) o Windows 2008, en el caso de 2003 server, tener instalado el service pack 1 en la máquina.
• Protocolo TCP/IP instalado y configurado manualmente, es decir, sin contar con una dirección asignada por DHCP,
• Tener un servidor de nombre de DNS, para resolver la dirección de los distintos recursos físicos presentes en la red
• Poseer más de 250 MB en una unidad de disco forma
•
• teada en NTFS.
Alternativas
Samba es un programa de código libre, que tiene disponible un controlador de dominios compatible con Windows NT 4.

El programa de código libre Mandriva Directory Server ofrece una interfaz web para manejar el controlador de dominios de Samba y el servicio de directorios de LDAP.

Otra alternativa es Novell eDirectory, que es Multiplataforma: se puede correr sobre cualquier sistema operativo: Linux, AIX, Solaris, Novell Netware, UNIX e integra LDAP v.3 Nativo. Es el precursor en materia de estructuras de Directorio, ya que fue introducido en 1990 con la versión de Novell Netware 4.0. Aunque AD de Microsoft alcanzó mayor popularidad, todavía no puede igualar la fiabilidad y calidad de eDirectory y su capacidad Multiplataforma.

Sun Java ES Directory Server[1] y OpenDS [2] son otras alternativas, el primero desarrollado en C y el segundo basado en java. El primero es un producto de Sun Microsystems y el segundo una alternativa de código abierto.

Una alternativa que integra OpenLDAP, Heimdal kerberos, Samba y además certificación digital y Bind9 (modificado para usar LDAP como backend) es WBSAgnitio ([3]).

Referencias
1. Introducción a Active Directory, Microsoft (en español)
2. Designing a Windows Server 2003 Active Directory, Sams (en inglés)
3. Interfaces de programación, Microsoft (en español)
4. Conceptos Fundamentales de Active Directory, Grupos de usuario de Microsoft (en español)
5. Active Directory, Wikipedia

Windows Server 2003

Windows Server 2003
es un sistema operativo de la familia Windows de la marca Microsoft para servidores que salió al mercado en el año 2003. Está basada en tecnología NT y su versión del núcleo NT es la 5.2.
En términos generales, Windows Server 2003 se podría considerar como un Windows XP modificado para labores empresariales, no con menos funciones, sino que estas están deshabilitadas por defecto para obtener un mejor rendimiento y para centrar el uso de procesador en las características de servidor; por ejemplo, la interfaz gráfica denominada Luna de Windows XP viene desactivada por lo que sólo se utiliza la interfaz clásica de Windows.

Características
Sus características más importantes son:
Sistema de archivos NTFS:
1. cuotas
2. cifrado y compresión de archivos, carpetas y no unidades completas.
3. permite montar dispositivos de almacenamiento sobre sistemas de archivos de otros dispositivos al estilo Unix
Gestión de almacenamiento, backups... incluye gestión jerárquica del almacenamiento, consiste en utilizar un algoritmo de caché para pasar los datos menos usados de discos duros a medios ópticos o similares más lentos, y volverlos a leer a disco duro cuando se necesitan.
Windows Driver Model: Implementación básica de los dispositivos más utilizados, de esa manera los fabricantes de dispositivos sólo han de programar ciertas especificaciones de su hardware.
ActiveDirectory Directorio de organización basado en LDAP, permite gestionar de forma centralizada la seguridad de una red corporativa a nivel local.
Autentificación Kerberos5
DNS con registro de IP's dinámicamente
Políticas de seguridad

Servidores
Los servidores que maneja Windows 2003 son:
Servidor de archivos
Servidor de impresiones
Servidor de aplicaciones
Servidor de correo (SMTP/POP)
Servidor de terminal
Servidor de Redes privadas virtuales (VPN) (o acceso remoto al servidor)
Controlador de Dominios (mediante Active Directory)
Servidor DNS
Servidor DHCP
Servidor de Streaming de Vídeo
Servidor WINS
Servidor RIS Remote Installation Services (Servicios de instalación remota)

Servidor de impresión
Teniendo ya en cuenta que para activar el servidor de impresión en Windows Server 2003 tiene que tener instalado el Windows Server, luego implementar una red cliente servidor y configurar la impresora en las PC y esta listo para que la pueda utilizar, ya sea del servidor o de una "PC hijo "



Mejoras respecto a Windows 2000 Server
Diferencias principales con Windows 2000 Server
1. Durante la instalación arranca con el mínimo de servicios activados para no comprometer la seguridad del sistema
2. Mejoras en el manejo de políticas de seguridad
3. Active Directory ya no utiliza NetBIOS sino que es necesaria la presencia de un DNS que soporte Service Records (detección de servicios ofrecidos


Versiones
Actualmente existen cinco versiones de Windows 2003, aunque todas ellas cuentan a su vez con versiones de 32 y 64 bits (excepto Web Edition). Las versiones son:
Web Edition Diseñado para los servicios y el hospedaje Web.
Standard Edition El más versátil de todos, ofrece un gran número de servicios útiles para empresas de cualquier tamaño.
Enterprise Edition Para empresas de mayor tamaño que la Standard Edition.
Datacenter Edition Para empresas que requieran bases de datos más escalables y un procesamiento de transacciones de gran volumen.
SmallBusiness Edition Dirigido para empresas pequeñas que tengan menos de 25 estaciones de trabajo.

Service Pack 1 (SP1)
El 30 de marzo de 2005, Microsoft lanza (Service Pack 1), para todas las versiones de Windows 2003. Con él, dotan al Sistema operativo de las mejoras incluidas en el SP2 de Windows XP, tales como una nueva interfaz para el Cortafuegos (aunque al tratarse de un servidor, el cortafuegos estará deshabilitado por defecto), o la corrección de todos los bugs aparecidos hasta la fecha en Windows Server 2003. El soporte de Windows Server 2003 Service Pack 1 finalizó el 14 de abril de 2009


Service Pack 2 (SP2)
El 12 de marzo de 2007 se lanzó el Service Pack 2 de Windows Server 2003. Este SP2 está concebido como una actualización para Windows Server 2003 R2, a su vez una actualización del Server 2003 original que Microsoft lanzó en diciembre de 2005. No obstante, este Service Pack se instala tanto sobre versiones R2 del sistema como sobre la versión original.
Entre las novedades que podemos encontrar en este Service Pack destacamos:
Microsoft Management Console (MMC) 3.0, que hace del proceso de creación de directivas (policy) de grupos introducido en el anterior service pack, algo más intuitivo y manejable.
Windows Deployment Services en substitución de Remote Installation Services para la realización de instalaciones remotas del sistema (sin encontrarse delante de la computadora en la cual se va a instalar ni tener el DVD del sistema en el lector de esta).
Scalable Networking Pack (SNP) permite escalar las redes corporativas (hacerlas crecer y controlar dicho crecimiento en la dirección que queramos) para hacer frente a las crecientes demandas de ancho de banda por parte de algunas aplicaciones concretas.
El cliente de conexión a redes inalámbricas soporta ahora autentificación WPA2.
Incluye todas las actualizaciones de seguridad y parches lanzados hasta la fecha.
Este Service Pack ya puede descargarse para su instalación o en formato de imagen ISO para grabar en CD o DVD para las plataformas de 32 y 64 bits. El Soporte Técnico para este Service Pack finalizará 12 ó 24 meses presentado el próximo Service Pack, o cuando finalice el ciclo de vida del producto, lo que ocurra primero.

Referencias
↑. Microsoft. Consultado el 28-02-2010.

LINUX
Historia
En abril de 1991, Linux Torvalds, de 21 años, empezó a trabajar en unas simples ideas para un núcleo de sistema operativo. Comenzó con un intento por obtener un núcleo de sistema operativo gratuito similar a Unix que funcionara con microprocesadores Intel 80386. Luego, el 25 de agosto de 1991, Torvalds escribió en el grupo de noticias comp.os.minix:4
"Estoy haciendo un sistema operativo (gratuito, sólo un hobby, no será nada grande ni profesional como GNU) para clones AT 386(486). Llevo en ello desde abril y está empezando a estar listo. Me gustaría saber su opinión sobre las cosas que les gustan o disgustan en minix, ya que mi SO tiene algún parecido con él.[...] Actualmente he portado bash(1.08) y gcc(1.40), y parece que las cosas funcionan. Esto implica que tendré algo práctico dentro de unos meses..."
Después de esto, muchas personas ayudaron con el código. En septiembre de 1991 se lanzó la versión 0.01 de Linux. Tenía 10.239 líneas de código. En octubre de ese año, se lanzó la versión 0.02 de Linux; luego, en diciembre se lanzó la versión 0.11. Esta versión fue la primera en ser self-hosted (autoalbergada). Es decir, Linux 0.11 podía ser compilado por una computadora que ejecutase Linux 0.11, mientras que las versiones anteriores de Linux se compilaban usando otros sistemas operativos. Cuando lanzó la siguiente versión, Torvalds adoptó la GPL como su propio boceto de licencia, la cual no permitía su redistribución con otra licencia que no sea GPL.
Se inició un grupo de noticias llamado alt.os.linux y el 19 de enero de 1992 se publicó en ese grupo el primer post. El 31 de marzo,alt.os.linux se convirtió en comp.os.linux. XFree86, una implementación del X Window System, fue portada a Linux, la versión del núcleo 0.95 fue la primera en ser capaz de ejecutarla. Este gran salto de versiones (de 0.1x a 0.9x) fue por la sensación de que una versión 1.0 acabada no parecía estar lejos. Sin embargo, estas previsiones resultaron ser un poco optimistas: desde 1993 a principios de 1994, se desarrollaron 15 versiones diferentes de 0.99 (llegando a la versión 0.99r15).
El 14 de marzo de 1994, se lanzó Linux 1.0.0, que constaba de 176.250 líneas de código. En marzo de 1995 se lanzó Linux 1.2.0, que ya estaba compuesto de 310.950 líneas de código.
En mayo de 1996 Torvalds decidió adoptar al pingüino Tux como mascota para Linux.
La versión 2 de Linux se lanzó el 9 de junio de 1996 y fue un gran éxito. A éste le siguieron grandes desarrollos:
 25 de enero de 1999: se lanzó Linux 2.2.0 con 1.800.847 líneas de código.
 18 de diciembre de 1999: se publicaron parches de IBM Mainframe para 2.2.13, permitiendo de esta forma que Linux fuera usado en ordenadores corporativos.
 4 de enero de 2001: se lanzó Linux 2.4.0 con 3.377.902 líneas de código.
 17 de diciembre de 2003: se lanzó Linux 2.6.0 con 5.929.913 líneas de código.
 24 de diciembre de 2008: se lanzó Linux 2.6.28 con 10.195.402 líneas de código.5
 20 de octubre de 2010: se lanzó Linux 2.6.36 con 13.499.457 líneas de código.6
Actualmente se puede bajar el código fuente desde su sitio web oficial.

Arquitectura

Actualmente Linux es un núcleo monolítico híbrido. Los controladores de dispositivos y las extensiones del núcleo normalmente se ejecutan en un espacio privilegiado conocido como anillo 0(ring 0), con acceso irrestricto al hardware, aunque algunos se ejecutan en espacio de usuario. A diferencia de los núcleos monolíticos tradicionales, los controladores de dispositivos y las extensiones al núcleo se pueden cargar y descargar fácilmente como módulos, mientras el sistema continúa funcionando sin interrupciones. También, a diferencia de los núcleos monolíticos tradicionales, los controladores pueden ser prevolcados (detenidos momentáneamente por actividades más importantes) bajo ciertas condiciones. Esta habilidad fue agregada para gestionar correctamente interrupciones de hardware, y para mejorar el soporte de multiprocesamiento simétrico.
El hecho de que Linux no fuera desarrollado siguiendo el diseño de un micronúcleo (diseño que, en aquella época, era considerado el más apropiado para un núcleo por muchos teóricos informáticos) fue asunto de una famosa y acalorada discusión entre Linus Torvalds y Andrew S. Tanenbaum

Jerarquía de directorios

En Linux existe un sistema de archivos que carga y contiene todos los directorios, redes, programas, particiones, dispositivos, etc. que el sistema sabe reconocer, o por lo menos, identificar. Este sistema de ficheros y directorios, tiene como base al carácter (/); ese mismo carácter sirve también para demarcar los directorios, como por ejemplo: "/home/usuario/imagen.jpg". El directorio especificado por una ruta consistente sólo por este carácter contiene toda la jerarquía de los directorios que constituyen todo el sistema. A este directorio suele llamárselo directorio raíz. En Linux, a los discos no se les asigna una letra como en Windows (p.e. "C:"), sino que se les asigna un directorio de la jerarquía del directorio raíz (/), como por ejemplo: "/media/floppy". Es práctica común en el sistema de ficheros de Linux, utilizar varias sub-jerarquías de directorios, según las diferentes funciones y estilos de utilización de los archivos.8 Estos directorios pueden clasificarse en:
 Estáticos: Contiene archivos que no cambian sin la intervención del administrador (root), sin embargo, pueden ser leídos por cualquier otro usuario. (/bin, /sbin, /opt, /boot, /usr/bin...)
 Dinámicos: Contiene archivos que son cambiantes, y pueden leerse y escribirse (algunos solo por su respectivo usuario y el root). Contienen configuraciones, documentos, etc. Para estos directorios, es recomendable una copia de seguridad con frecuencia, o mejor aún, deberían ser montados en una partición aparte en el mismo disco, como por ejemplo, montar el directorio /home en otra partición del mismo disco, independiente de la partición principal del sistema; de esta forma, puede repararse el sistema sin afectar o borrar los documentos de los usuarios. (/var/mail, /var/spool, /var/run, /var/lock, /home...)
 Compartidos: Contiene archivos que se pueden encontrar en un ordenador y utilizarse en otro, o incluso compartirse entre usuarios.
 Restringidos: Contiene ficheros que no se pueden compartir, solo son modificables por el administrador. (/etc, /boot, /var/run, /var/lock...)

Kernel panic


En Linux, un “panic” es un error insalvable del sistema detectado por el núcleo en oposición a los errores similares detectados en el código del espacio de usuario. Es posible para el código del núcleo indicar estas condiciones mediante una llamada a la función de pánico situada en el archivo header sys/system.h. Sin embargo, la mayoría de las alertas son el resultado de excepciones en el código del núcleo que el procesador no puede manejar, como referencias a direcciones de memorias inválidas. Generalmente esto es indicador de la existencia de un bug en algún lugar de la cadena de alerta. También pueden indicar un fallo en el hardware como un fallo de la RAM o errores en las funciones aritméticas en el procesador, o por un error en el software. En muchas ocasiones es posible reiniciar o apagar adecuadamente el núcleo mediante una combinación de teclas comoALT+SysRq+RSEIUB.

Lenguajes de programación
Linux está escrito en el lenguaje de programación C, en la variante utilizada por el compilador GCC (que ha introducido un número de extensiones y cambios al C estándar), junto a unas pequeñas secciones de código escritas con el lenguaje ensamblador. Por el uso de sus extensiones al lenguaje, GCC fue durante mucho tiempo el único compilador capaz de construir correctamente Linux. Sin embargo, Intelafirmó haber modificado su compilador C de forma que permitiera compilarlo correctamente.
Asimismo se usan muchos otros lenguajes en alguna forma, básicamente en la conexión con el proceso de construcción del núcleo (el método a través del cual las imágenes arrancables son creadas desde el código fuente). Estos incluyen a Perl, Python y varios lenguajes shell scripting. Algunos drivers también pueden ser escritos en C++, Fortran, u otros lenguajes, pero esto no es aconsejable. El sistema de construcción de Linux oficialmente solo soporta GCC como núcleo y compilador de controlador.
[

Portabilidad

Aun cuando Linus Torvalds no ideó originalmente Linux como un núcleo portable, ha evolucionado en esa dirección. Linux es ahora de hecho, uno de los núcleos más ampliamente portados, y funciona en sistemas muy diversos que van desde iPAQ (una handheld) hasta un zSeries (un mainframemasivo). Está planeado que Linux sea el sistema operativo principal de las nuevassupercomputadoras de IBM, Blue Gene cuando su desarrollo se complete.
De todos modos, es importante notar que los esfuerzos de Torvalds también estaban dirigidos a un tipo diferente de portabilidad. Según su punto de vista, la portabilidad es la habilidad de compilar fácilmente en un sistema aplicaciones de los orígenes más diversos; así, la popularidad original de Linux se debió en parte al poco esfuerzo necesario para tener funcionando las aplicaciones favoritas de todos, ya sean GPL o de Código abierto.
Las arquitecturas principales soportadas por Linux son DEC Alpha, ARM, AVR32, Blackfin, ETRAX CRIS, FR-V, H8, IA64, M32R, m68k, MicroBlaze, MIPS, MN10300, PA-RISC, PowerPC, System/390,SuperH, SPARC, x86, x86 64 y Xtensa9


Arquitectura de máquina virtual
El núcleo Linux puede correr sobre muchas arquitecturas de máquina virtual, tanto como host del sistema operativo o como cliente. La máquina virtual usualmente emula la familia de procesadores Intel x86, aunque en algunos casos también son emulados procesadores de PowerPC o AMD.

Formatos binarios soportados
Linux 1.0 admitía sólo el formato binario a.out. La siguiente serie estable (Linux 1.2) agregó la utilización del formato ELF, el cual simplifica la creación de bibliotecas compartidas (usadas de forma extensa por los actuales ambientes de escritorio como GNOME y KDE). ELF es el formato usado de forma predeterminada por el GCC desde alrededor de la versión 2.6.0. El formato a.out actualmente no es usado, convirtiendo a ELF en el formato binario utilizado por Linux en la actualidad.
Linux tiene la capacidad de permitir al usuario añadir el manejo de otros formatos binarios. También binfmt_misc permite correr el programa asociado a un archivo de datos.
[

Versiones
Más allá de haber desarrollado su propio código y de integrar los cambios realizados por otros programas, Linus Torvalds continua lanzando nuevas versiones del núcleo Linux. Estos son llamados núcleos “vanilla”, lo que significa que no han sido modificados por nadie. Muchos desarrolladores de distribuciones Linux modifican dicho núcleo en sus productos, principalmente para agregarle soporte a dispositivos o herramientas que no fueron oficialmente lanzadas como estables, mientras que algunas distribuciones, como Slackware, mantienen el núcleo vanilla.

UNIX

Entre 1965 y 1969, los Laboratorios Bell participaron con General Electric (Más tarde Honeywell) y Project MAC (Del Massachusetts Institute of Technology) en el desarrollo del sistema Multics. Este sistema diseñado para la macrocomputadora GE-645, era demasiado grande y complejo. Los diseñadores de Multics tenían en mente un programa de utilidad general que pudiera ser en esencia "todo para el mundo".

Al avanzar los trabajos se hizo evidente que aunque Multics proporcionaría con toda probabilidad la diversidad de servicios requerida, sería un sistema enorme, costoso y torpe. Por estas y muchas otras razones, los Laboratorios Bell se retiraron del proyecto en 1969. Algunos de los miembros de investigación de Bell comenzaron a trabajar en un sistema mucho menos ambicioso. El grupo, dirigido por Ken Thompson, buscaba crear un ambiente de computación sencillo para investigación y desarrollo de programas potentes. La primera versión de un sistema UNIX se creó para un DEC PDP-7 y se escribió en lenguaje ensamblador.

Thompson llevó a la práctica un sistema de archivos, un mecanismo de control de procesos, programas para el manejo general de archivos y un intérprete de mandatos (Comandos). En 1970 Brian Kernighan acuñó el nombre "UNIX" haciendo un juego de palabras con Multics; de hecho, en el sentido en que Multics era "multi", los sistemas UNIX eran sin duda servicios de computación "uni", limitados.

Cuando apareció la PDP-11, su atractivo precio permitió al grupo adquirir la máquina. No contaba con apoyo para la multiprogramación; la computadora tenía sólo 24K y el sistema ocupaba 16K ; por tanto quedaban 8K reservados para el usuario. El tamaño máximo de archivo era de 64Kbytes. La aplicación principal era el procesamiento de textos. No había protección del almacenamiento, de modo que el sistema podía al ejecutarse caerse con facilidad durante la prueba de un programa nuevo. El disco era pequeño, apenas 500 Kilobytes.

Dennis Ritchie se unió a la labor de desarrollo y ayudó a rescribir los sistemas UNIX en C en 1973. Esto ayudó a que los programas de los sistemas UNIX se volvieran más portátiles y comprensibles.

Las contribuciones de Thompson y Ritchie recibieron como reconocimiento el premio Turing, el de más prestigio en la comunidad de computación.

Antes de la liberalización, AT&T no tenía permiso para competir en la industria de la informática, por lo que ofreció los sistemas UNIX a las universidades por una cuota nominal. Además de distribuir el código fuente, fomentando así el desarrollo adicional y las innovaciones.

Una de las universidades que adquirió una licencia de Unix fue la Universidad de California en Berkeley. La motivación principal era poder experimentar con el primer sistema operativo que incluía código fuente. Al poco tiempo, la gente de Berkeley había escrito varios programas utilitarios para Unix que otros investigadores podrían encontrar útiles. La Universidad decidió entonces distribuir este código a la comunidad y le llamó a sus distribuciones BSD (Berkeley Software Distribution). A pesar que al principio las distribuciones de Berkeley consistían principalmente en herramientas para los usuarios, muy pronto comenzaron a cambiar la forma en que el propio sistema operativo funcionaba. Implementaron el manejo de memoria virtual y programaron el soporte para los protocolos del Arpanet que luego se convertiría en el conocido Internet. Todos estos cambios eran distribuidos como BSD a quienes tenían una licencia de Unix de la división de BTL encargada de administrar este sistema (AT&T).

A mediados de los años ochentas, Richard Stallman, entonces en el Instituto Tecnológico de Massachussets (MIT) decidió dedicarse a la construcción de lo que denominó software libre. El razonamiento de Stallman era que los mayores progresos en la industria del software surgen cuando se coopera entre programadores. Según Stallman, las industrias de la época estaban atentando contra la libertad de los usuarios y programadores de compartir el software, así que decidió programar un sistema parecido a Unix y regalarlo. A este sistema le llamó GNU, un acrónimo recursivo que significa Gnu's Not Unix (GNU no es Unix).

Para las personas deseosas de correr Unix en las ahora populares PCs, quedaba únicamente una alternativa, Minix. Minix era un sistema operativo parecido a Unix desarrollado por el Profesor Andrew Tanenbaum para enseñarle a sus alumnos acerca del diseño de sistemas operativos. Sin embargo, debido al enfoque puramente educacional de Minix, Tanenbaum no permitía que este fuera modificado demasiado ya que esto complicaba el sistema y no permitía que sus estudiantes lo entendieran en un semestre.

Un estudiante de Finlandia, Linus Torvalds, al ver que no era posible extender Minix, decidió escribir su propio sistema operativo compatible con Unix. Miles de personas que querían correr Unix en sus PCs vieron aquí su única alternativa debido a que a Minix le faltaban demasiadas cosas y BSD, a pesar de tener toda la funcionalidad esperada, tenía problemas legales. El proyecto GNU que Stallman había iniciado hacía ya casi diez años había producido para este entonces un sistema casi completo a excepción del kernel, que es el programa que controla el hardware de la máquina. Torvalds decidió utilizar el casi completo sistema GNU y completarlo él mismo con su propio kernel, al resultado le llamó Linux. Richard Stallman insiste aún que el sistema debiera ser llamado GNU/Linux, ya que incluye más código del proyecto GNU que del proyecto Linux.

En 1975 los sistemas UNIX se habían popularizado muchísimo en las universidades y así apareció una organización de usuarios que evolucionó hasta convertirse en el grupo llamado USENIX.

Los sistemas UNIX satisfacen necesidades de los programadores que crean software y de los administradores que deben controlar las labores de desarrollo de programas. Sin embargo, no estaban diseñados para sustituir los sistemas operativos comerciales "de trabajo pesado" que dan apoyo a un procesamiento masivo de datos.

El sistema de tiempo compartido UNIX, séptima edición, editado en 1979, hizo que los sistemas UNIX estuvieran más cerca de convertirse en productos comerciales válidos. Los archivos podían llegar a un tamaño de mil millones de bytes. El sistema se hizo todavía más portátil y se amplió el lenguaje C. Se llevó a la práctica un shell (Intérprete de los mandatos del usuario) más potente que incluía variables de cadena, programación estructurada, manejo de trampas y otras características. Se añadió la capacidad de añadir archivos entre una máquina y otra.

Reconociendo el valor de los sistemas UNIX, Microsoft anunció en 1980 que ofrecería XENIX, una versión comercial de sistema UNIX, en microprocesadores de 16 bits. Para mejorar la viabilidad, Microsoft agrego a cute; recuperación de errores por hardware, reparación automática de archivos después de caídas, detección de fallas en el suministro de energía y errores de paridad, segmentos compartidos de datos y una mejor comunicación entre procesos.

En 1980, la Universidad de California en Berkeley recibió fondos del Departamento de Defensa para evolucionar los sistemas UNIX de sistemas operativos pequeños de tiempo compartido a sistemas apropiados para estudiar ambientes de computación distribuida. Esto redundó en el desarrollo del sistema 4.1 BSD, después AT&T comercializó el sistema UNIX System III en 1982, este evolucionó hasta convertirse en System V.

A mediados de los años noventa, AT&T vendió Unix a Novell, quién tomó como prioridad número uno resolver las demandas. El acuerdo fue que la Universidad de California eliminaría todo el código residual de AT&T y lanzaría una última distribución de BSD totalmente libre de problemas de licenciamiento. Esta distribución fue el 4.4-BSD Lite2. Quien quisiera distribuir BSD debería basar su distribución en 4.4-BSD Lite2 para no tener problemas legales. Inmediatamente los distribuidores de BSD reiniciaron sus labores de distribución migrando lentamente sus sistemas al 4.4-BSD Lite2.
Para este entonces, Linux se había convertido ya en el Unix más popular entre la gente que buscaba alternativas al Windows de Microsoft.

A comienzos de 1984, había sobre 100.000 instalaciones del sistema UNIX en el mundo, funcionando en máquinas con un amplio rango de computadoras, desde microprocesadores hasta mainframes. Ningún otro sistema operativo puede hacer esta declaración. Muchas han sido las razones que han hecho posible la popularidad y el éxito del sistema UNIX:

El sistema está escrito en un lenguaje de alto nivel, haciéndolo fácil de leer, comprender, cambiar, y mover a otras máquinas. Ritchie estimó que el primer sistema en C era de un 20 a un 40 por ciento más grande y lento porque no estaba escrito en lenguaje ensamblador, pero las ventajas de usar un lenguaje de alto nivel superaban largamente a las desventajas.

• Posee una simple interface de usuario con el poder de dar los servicios que los usuarios quieren.
• Provee de primitivas que permiten construir programas complejos a través de programas simples.
• Usa un sistema de archivos jerárquico que permite un mantenimiento fácil y una implementación eficiente.
• Usa un formato consistente para los archivos, el flujo de bytes, haciendo a los programas de aplicación más fáciles de escribir.
• Provee una simple y consistente interface a los dispositivos periféricos.
• Es un sistema multiusuario y multitarea; cada usuario puede ejecutar varios procesos simultáneamente.
• Oculta la arquitectura de la máquina al usuario, haciendo fácil de escribir programas que se ejecutan en diferentes implementaciones hardware.

Sin embargo tiene algunos inconvenientes:

• Comandos poco claros y con demasiadas opciones.
• Escasa protección entre usuarios.
• Sistema de archivo lento.

A pesar de que el sistema operativo y muchos de los comandos están escritos en C, UNIX soporta otros lenguajes, incluyendo Fortran, Basic, Pascal, Ada, Cobol, Lisp y Prolog. El sistema UNIX puede soportar cualquier lenguaje que tenga un compilador o intérprete y una interface de sistema que defina las peticiones del usuario de los servicios del sistema operativo de la forma estándar de las peticiones usadas en los sistemas UNIX.

Principales caracteristicas de UNIX

• Es un sistema operativo multiusuario, con capacidad de simular multiprocesamiento y procesamiento no interactivo.
• Está escrito en un lenguaje de alto nivel: C.
• Dispone de un lenguaje de control programable llamado SHELL.
• Ofrece facilidades para la creación de programas y sistemas y el ambiente adecuado para las tareas de diseños de software.
• Emplea manejo dinámico de memoria por intercambio o paginación.
• Tiene capacidad de interconexión de procesos.
• Permite comunicación entre procesos.
• Emplea un sistema jerárquico de archivos, con facilidades de protección de archivos, cuentas y procesos.
• Tiene facilidad para redireccionamiento de Entradas / Salidas.
• Garantiza un alto grado de portabilidad.

El sistema UNÍX se basa en un Núcleo llamado Kernel, que reside permanentemente en la memoria, y que atiende a todas las llamadas del sistema, administra el acceso a los archivos y el inicio o la suspensión de las tareas de los usuarios.

La comunicación con el sistema UNIX se da mediante un programa de control llamado SHELL. Este es un lenguaje de control, un intérprete, y un lenguaje de programación, cuyas características lo hacen sumamente flexible para las tareas de un centro de cómputo. Como lenguaje de programación abarca los siguientes aspectos:

• Ofrece las estructuras de control normales: secuenciación, iteración condicional, selección y otras.
• Paso de parámetros.
• Sustitución textual de variables y Cadenas.
• Comunicación bidireccional entre órdenes de shell.
• Es posible interconectar procesos entre sí.
• Diferentes usuarios pueden "ver" versiones distintas del sistema operativo debido a la capacidad del shell para configurar diversos ambientes de ejecución

KERNEL

---

El núcleo del sistema operativo Unix (llamado Kernel) es un programa escrito casi en su totalidad en lenguaje C, con excepción de una parte del manejo de interrupciones, expresada en el lenguaje ensamblador del procesador en el que opera.

Las funciones del núcleo son permitir la existencia de un ambiente en el que sea posible atender a varios usuarios y múltiples tareas en forma concurrente, repartiendo al procesador entre todos ellos, e intentando mantener en grado óptimo la atención individual.

El Kernel opera como asignador de recursos para cualquier proceso que necesite hacer uso de las facilidades de cómputo. Es el componente central de Unix y tiene las siguientes funciones:

• Creación de procesos, asignación de tiempos de atención y sincronización.
• Asignación de la atención del procesador a los procesos que lo requieren.
• Administración de espacio en el sistema de archivos, que incluye: acceso, protección y administración de usuarios; comunicación entre usuarios v entre procesos, y manipulación de E/S y administración de periféricos.
• Supervisión de la transmisión de datos entre la memoria principal y los dispositivos periféricos.

El Kernel reside siempre en la memoria central y tiene el control sobre la computadora, por lo que ningún otro proceso puede interrumpirlo; sólo pueden llamarlo para que proporcione algún servicio de los ya mencionados. Un proceso llama al Kernel mediante módulos especiales conocidos como llamadas al sistema.

El Kernel consta de dos artes principales: la sección de control de procesos y la de control de dispositivos. La primera asigna recursos, programas, procesos y atiende sus requerimientos de servicio; la segunda, supervisa la transferencia de datos entre la memoria principal y los dispositivos periféricos. En términos generales, cada vez que algún usuario oprime una tecla de una terminal, o que se debe leer o escribir información del disco magnético, se interrumpe al procesador central y el núcleo se encarga de efectuar la operación de transferencia.

Cuando se inicia la operación de la computadora, debe cargarse en la memoria una copia del núcleo, que reside en e] disco magnético (operación denominada bootstrap). Para ello, se deben inicializar algunas interfaces básicas de hardware; entre ellas, el reloj que proporciona interrupciones periódicas. El Kernel también prepara algunas estructuras de datos que abarcan una sección de almacenamiento temporal para transferencia de información entre terminales y procesos, una sección para almacenamiento de descriptores de archivos y una variable que indica la cantidad de memoria principal.

A continuación, el Kernel inicializa un proceso especial, llamado proceso 0. En general, los procesos se crean mediante una llamada a una rutina del sistema (fork), que funciona por un mecanismo de duplicación de procesos. Sin embargo, esto no es suficiente para crear el primero de ellos, por lo que el Kernel asigna una estructura de datos y establece apuntadores a una sección especial de la memoria, llamada tabla de procesos, que contendrá los descriptores de cada uno de los procesos existentes en el sistema.

Después de haber creado el proceso 0, se hace una copia del mismo, con lo que se crea el proceso 1; éste muy pronto se encargará de "dar vida" al sistema completo, mediante la activación de otros procesos que también forman parte del núcleo. Es decir, se inicia una cadena de activaciones de procesos, entre los cuales destaca el conocido como despachador, o scheduler, que es el responsable de decidir cuál proceso se ejecutará y cuáles van a entrar o salir de la memoria central. A partir de ese momento se conoce el número 1 como proceso de inicialización del sistema, init.

El proceso init es el responsable de establecer la estructura de procesos en Unix. Normalmente, es capaz de crear al menos dos estructuras distintas de procesos: el modo monousuario y el multiusuario. Comienza activando el intérprete del lenguaje de control (Shell) en la terminal principal, o consola, del sistema y proporcionándole privilegios de "superusuario". En la modalidad de un solo usuario la consola permite iniciar una primera sesión, con privilegios especiales, e impide que las otras líneas de comunicación acepten iniciar sesiones nuevas. Esta modalidad se usa con frecuencia para revisar y reparar sistemas de archivos, realizar pruebas de funciones básicas del sistema y para otras actividades que requieren uso exclusivo de la computadora.

Init crea otro proceso, que espera pacientemente a que alguien entre en sesión en alguna línea de comunicación. Cuando esto sucede, realiza ajustes en el protocolo de la línea y ejecuta el programa login, que se encarga de atender inicialmente a los nuevos usuarios. Si la clave del usuario, y la contraseña proporcionadas son las correctas, entonces entra en operación el programa Shell, que en lo sucesivo se encargará de la atención normal del usuario que se dio de alta en esa terminal.

A partir de ese momento el responsable de atender al usuario en esa terminal es el intérprete Shell. Cuando se desea terminar la sesión hay que desconectarse de Shell (y, por lo tanto, de Unix), mediante una secuencia especial de teclas (usualmente. <> - D). A partir de ese momento la terminal queda disponible para atender a un nuevo usuario.

Administración de archivos

El sistema de archivos de Unix; esta basado en un modelo arborescente y recursivo, en el cual los nodos pueden ser tanto archivos como directorios, y estos últimos pueden contener a su vez directorios o subdirectorios. Debido a esta filosofía, se maneja al sistema con muy pocas órdenes, que permiten una gran gama de posibilidades. Todo archivo de Unix está controlado por múltiples niveles de protección, que especifican los permisos de acceso al mismo. La diferencia que existe entre un archivo de datos, un programa, un manejador de entrada/salida o una instrucción ejecutable se refleja en estos parámetros, de modo que el sistema operativo adquiere características de coherencia y elegancia que lo distinguen.

La raíz del sistema de archivos (conocida como root ) se denota con el símbolo "/", y de ahí se desprende un conjunto de directorios que contienen todos los archivos del sistema de cómputo. Cada directorio, a su vez, funciona como la subraíz de un nuevo árbol que depende de él y que también puede estar formado por directorios o subdirectorios y archivos. Un archivo siempre ocupará el nivel más bajo dentro del árbol, porque de un archivo no pueden depender otros; si así fuera, sería un directorio. Es decir, los archivos son como las hojas del árbol.

Se define en forma unívoca el nombre de todo archivo (o directorio) mediante lo que se conoce como su trayectoria (path name): es decir, el conjunto completo de directorios, a partir de root (/), por los que hay que pasar para poder llegar al directorio o archivo deseado. Cada nombre se separa de los otros con el símbolo /, aunque tan sólo el primero de ellos se refiere a la raíz.