Linux

FRR y Routers con Linux

  • admin 

FRR y Routers con Linux

Desde que hace unos meses los de Cumulus Linux anunciaran el uso en sus switches Linux de montar VPNs con VxLAN + EVPN (usando BGP para advertir las MACs de los equipos a los extremos remotos), y posteriormente anunciar que iban a remplazar el quagga de sus equipos por el FRR (un fork de quagga), el tema de usar servidores con Linux para remplazar a routes y switches de alto rendimiento ya está al alcance de todos.

El tema de VxLAN (transporte de VLANs encapsuladas por IP) usando como mecanismo de señalización y control las extensiones de BGP para advertir las MACs y comunicar las VLANs entre los puntos remotos permite hacer todo tipo de virguerías en los datacenters para transportar VPNs de nivel 2 y 3 de forma eficiente a gran escala y sin necesidad de tener que montar un core MPLS por debajo. A partir de la versión 3.0 del FRR ya se soportan todas las recomendaciones que permiten montar las EVPNs con VxLAN (son los drafts draft-ietf-bess-evpn:

https://github.com/FRRouting/frr/wiki/Major-Changes

Los del FRR se han puesto mucho las pilas para competir y llegar a superar incluso a los más avanzados, como Juniper y Arista.

Después en los grupos de operadores de red se han disparado las presentaciones de casos de uso y aplicaciones utilizando el FRR como equipos de core.

Aquí un ejemplo del hardware compacto para router de alto rendimiento (esto es del grupo de operadores de red suizo):

http://www.swinog.ch/meetings/swinog32/p/Manuel_Schweizer_Free-Range-Routing-FRR.pdf

Los equipos de 1U compactos a los que hace referencia son estos:

https://www.lanner-america.com/product/nca-5510/

Y efectivamente, soportan tarjetas de hasta 100G.

Aquí en la sesión anterior del swinog, otra charla sobre el tema de las VPNs multitenant utilizando el FRR con VxLAN + EVPN:

http://www.swinog.ch/meetings/swinog31/p/06_Attilla_de_Groot_Multi-tenancy_with_EVPN-VxLAN_in_Open_Networking.pdf

Hay muchos ejemplos del mismo tipo de solución. Aquí en la misma sesión que la anterior hay una charla de Huawei explicando en más detalle el tema del por qué es una buena elección y el por qué se está quedando desbancado el MPLS para dar ese tipo de soluciones a las VPNs de nivel 2 y nivel 3:

http://www.swinog.ch/meetings/swinog31/p/04_Christian_Kuster_VXLAN_-_Thinking_outside_the_(DC)Box.pdf

Desde hace cosa de un año voy siguiendo de vez en cuando esta solución, y por lo que veo ya ha pasado el punto de ser algo puramente experimental con unas cuantas soluciones y acercamientos de los principales impulsores a ser una solución disponible y 100% open source. Ya no hace falta comprarse un switch de Cumulus con licencias para tener una solución lista para producción. Ahora es sólo cuestión de poner una pareja de servidores y tarjetas de red intel conectadas a los switches del core para dar ese tipo de funcionalidades. Esto ya está disponible, pero dentro de unos meses alcanzará un nivel de madurez bastante extenso a todo tipo de plataformas, incluidos los routers CPE.

Me han sorprendido mucho los del FRR. Hace unos meses pensaba que se iba a quedar un poco como el quagga con unas cuantas mejoras adicionales y poco más, pero se han puesto las pilas a base de bien.

How To Disable ipv6 Fedora 17/18

Source: http://lifeofageekadmin.com/how-to-disable-ipv6-fedora-1718/

IPV6 is coming, but it is not here yet, so say you want to disable it on your Fedora 18 system. Pretty simple to do. First let’s edit the /etc/sysctl.conf file.

$ sudo vi /etc/sysctl.conf

Add and save the changes

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

To eliminate the default ipv6 addresses still appear on the interfaces open a terminal and type

Type ifconfig to get the inet6 info and the adapter

$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 84  bytes 7100 (6.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84  bytes 7100 (6.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::a00:27ff:fedc:5b71  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:dc:5b:71  txqueuelen 1000  (Ethernet)
        RX packets 234990  bytes 115274228 (109.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 210670  bytes 40730873 (38.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
$ sudo ip addr del ::1/128 dev lo
$ sudo ip addr del fe80::a00:27ff:fedc:5b71/64 dev p2p1

$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 84  bytes 7100 (6.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84  bytes 7100 (6.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 08:00:27:dc:5b:71  txqueuelen 1000  (Ethernet)
        RX packets 235487  bytes 115320518 (109.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 210678  bytes 40731473 (38.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Comment out ::1 in /etc/hosts

$ sudo vi /etc/hosts

# ::1 localhost

Hot Plugging: hotplug

  • admin 

Fuente: http://debian-handbook.info/browse/stable/sect.hotplug.html

Introduction

The hotplug kernel subsystem loads drivers for peripherals that can be hotplugged. This includes USB peripherals (increasingly common), PCMCIA (common expansion cards for laptops), IEEE 1394 (also called “Firewire” or “I-Link”), some SATA hard drives, and even, for some high-end servers, PCI or SCSI devices.

The kernel has a database that associates each device ID with the required driver. This database is used during boot to load all the drivers for the peripheral devices detected on the different buses mentioned, but also when an additional hotplug device is connected.

Once a driver is loaded, a message is sent to udevd so it will be able to create the corresponding entry in /dev/.
The Naming Problem

Before the appearance of hotplug connections, it was easy to assign a fixed name to a device. It was based simply on the position of the devices on their respective bus. But this is not possible when such devices can come and go on the bus. The typical case is the use of a digital camera and a USB key, both of which appear to the computer as disk drives. The first one connected may be /dev/sdb and the second /dev/sdc (with /dev/sda representing the computer’s own hard drive). The device name is not fixed; it depends on the order in which devices are connected.

Additionally, more and more drivers use dynamic values for devices’ major/minor numbers, which makes it impossible to have static entries for the given devices, since these essential characteristics may vary after a reboot.

udev was created precisely to solve this problem.

NOTE: IN PRACTICE Network card management
Many computers have multiple network cards (sometimes two wired interfaces and a wifi interface), and with hotplug support on most bus types, the 2.6 kernel no longer guarantees fixed naming of network interfaces. But a user who wants to configure their network in /etc/network/interfaces needs a fixed name!

It would be difficult to ask every user to create their own udev rules to address this problem. This is why udev was configured in a rather peculiar manner; on first boot (and, more generally, each time that a new network card appears) it uses the name of the network interface and its MAC address to create new rules that will reassign the same name on subsequent boots. These rules are stored in /etc/udev/rules.d/70-persistent-net.rules.
This mechanism has some side effects that you should know about. Let’s consider the case of computer that has only one PCI network card. The network interface is named eth0, logically. Now say the card breaks down, and the administrator replaces it; the new card will have a new MAC address. Since the old card was assigned the name, eth0, the new one will be assigned eth1, even though the eth0 card is gone for good (and the network will not be functional because /etc/network/interfaces likely configures an eth0 interface). In this case, it is enough to simply delete the /etc/udev/rules.d/70-persistent-net.rules file before rebooting the computer. The new card will then be given the expected eth0 name.

How udev Works
When udev is notified by the kernel of the appearance of a new device, it collects various information on the given device by consulting the corresponding entries in /sys/, especially those that uniquely identify it (MAC address for a network card, serial number for some USB devices, etc.).
Armed with all of this information, udev then consults all of the rules contained in /etc/udev/rules.d/ and /lib/udev/rules.d/. In this process it decides how to name the device, what symbolic links to create (to give it alternative names), and what commands to execute. All of these files are consulted, and the rules are all evaluated sequentially (except when a file uses “GOTO” directives). Thus, there may be several rules that correspond to a given event.
The syntax of rules files is quite simple: each row contains selection criteria and variable assignments. The former are used to select events for which there is a need to react, and the latter defines the action to take. They are all simply separated with commas, and the operator implicitly differentiates between a selection criterion (with comparison operators, such as == or !=) or an assignment directive (with operators such as =, += or :=).
Comparison operators are used on the following variables:

 

  • KERNEL: the name that the kernel assigns to the device;
  • ACTION: the action corresponding to the event (“add” when a device has been added, “remove” when it has been removed);
  • DEVPATH: the path of the device’s /sys/ entry;
  • SUBSYSTEM: the kernel subsystem which generated the request (there are many, but a few examples are “usb”, “ide”, “net”, “firmware”, etc.);
  • ATTR{attribut}: file contents of the attribute file in the /sys/$devpath/ directory of the device. This is where you find the MAC address and other bus specific identifiers;
  • KERNELS, SUBSYSTEMS and ATTRS{attributes} are variations that will try to match the different options on one of the parent devices of the current device;
  • PROGRAM: delegates the test to the indicated program (true if it returns 0, false if not). The content of the program’s standard output is stored so that it can be reused by the RESULT test;
  • RESULT: execute tests on the standard output stored during the last call to PROGRAM.

The right operands can use pattern expressions to match several values at the same time. For instance, * matches any string (even an empty one); ? matches any character, and [] matches the set of characters listed between the square brackets (or the opposite thereof if the first character is an exclamation point, and contiguous ranges of characters are indicated like a-z).
Regarding the assignment operators, = assigns a value (and replaces the current value); in the case of a list, it is emptied and contains only the value assigned. := does the same, but prevents later changes to the same variable. As for +=, it adds an item to a list. The following variables can be changed:

  • NAME: the device filename to be created in /dev/. Only the first assignment counts; the others are ignored;
  • SYMLINK: the list of symbolic links that will point to the same device;
  • OWNER, GROUP and MODE define the user and group that owns the device, as well as the associated permission;
  • RUN: the list of programs to execute in response to this event.

The values assigned to these variables may use a number of substitutions:
$kernel or %k: equivalent to KERNEL;
$number or %n: the order number of the device, for example, for sda3, it would be “3”;
$devpath or %p: equivalent to DEVPATH;
$attr{attribute} or %s{attribute}: equivalent to ATTRS{attribute};
$major or %M: the kernel major number of the device;
$minor or %m: the kernel minor number of the device;
$result or %c: the string output by the last program invoked by PROGRAM;
and, finally, %% and $$ for the percent and dollar sign, respectively.
The above lists are not complete (they include only the most important parameters), but the udev(7) manual page should be.
A concrete example
Let us consider the case of a simple USB key and try to assign it a fixed name. First, you must find the elements that will identify it in a unique manner. For this, plug it in and run udevadm info -a -n /dev/sdc (replacing /dev/sdc with the actual name assigned to the key).
# udevadm info -a -n /dev/sdc
[…]
looking at device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0/block/sdc’:
KERNEL==»sdc»
SUBSYSTEM==»block»
DRIVER==»»
ATTR{range}==»16″
ATTR{ext_range}==»256″
ATTR{removable}==»1″
ATTR{ro}==»0″
ATTR{size}==»126976″
ATTR{alignment_offset}==»0″
ATTR{capability}==»53″
ATTR{stat}==» 51 100 1208 256 0 0 0 0 0 192 25 6″
ATTR{inflight}==» 0 0″
[…]
looking at parent device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0’:
KERNELS==»9:0:0:0″
SUBSYSTEMS==»scsi»
DRIVERS==»sd»
ATTRS{device_blocked}==»0″
ATTRS{type}==»0″
ATTRS{scsi_level}==»3″
ATTRS{vendor}==»I0MEGA »
ATTRS{model}==»UMni64MB*IOM2C4 »
ATTRS{rev}==» »
ATTRS{state}==»running»
[…]
ATTRS{max_sectors}==»240″
[…]
looking at parent device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2’:
KERNELS==»9:0:0:0″
SUBSYSTEMS==»usb»
DRIVERS==»usb»
ATTRS{configuration}==»iCfg»
ATTRS{bNumInterfaces}==» 1″
ATTRS{bConfigurationValue}==»1″
ATTRS{bmAttributes}==»80″
ATTRS{bMaxPower}==»100mA»
ATTRS{urbnum}==»398″
ATTRS{idVendor}==»4146″
ATTRS{idProduct}==»4146″
ATTRS{bcdDevice}==»0100″
[…]
ATTRS{manufacturer}==»USB Disk»
ATTRS{product}==»USB Mass Storage Device»
ATTRS{serial}==»M004021000001″
[…]
To create a new rule, you can use tests on the device’s variables, as well as those of one of the parent devices. The above case allows us to create two rules like these:
KERNEL==»sd?», SUBSYSTEM==»block», ATTRS{serial}==»M004021000001″, SYMLINK+=»usb_key/disk»
KERNEL==»sd?[0-9]», SUBSYSTEM==»block», ATTRS{serial}==»M004021000001″, SYMLINK+=»usb_key/part%n»
Once these rules are set in a file, named for example /etc/udev/rules.d/010_local.rules, you can simply remove and reconnect the USB key. You can then see that /dev/usb_key/disk represents the disk associated with the USB key, and /dev/usb_key/part1 is its first partition.
GOING FURTHER Debugging udev’s configuration

Like many daemons, udevd stores logs in /var/log/daemon.log. But it is not very verbose by default, and it’s usually not enough to understand what’s happening. The udevadm control –log-priority=info command increases the verbosity level and solves this problem. udevadm control –log-priority=err returns to the default verbosity level.

Proceso de arranque en Linux

El Proceso de arranque en Linux es el proceso de inicialización del sistema operativo Linux. Es en muchos aspectos similar a los procesos de arranque de BSD y otros sistemas Unix, de los cuales deriva.

 

Descripción general del proceso típico

En Linux, el flujo de control durante el arranque es desde el BIOS, al gestor de arranque y al núcleo (kernel). El núcleo inicia el planificador (para permitir la multitarea) y ejecuta el primer espacio de usuario (es decir, fuera del espacio del núcleo) y el programa de inicialización (que establece el entorno de usuario y permite la interacción del usuario y el inicio de sesión), momento en el que el núcleo se inactiva hasta que sea llamado externamente.

La etapa del cargador de arranque no es totalmente necesaria. Determinadas BIOS pueden cargar y pasar el control a Linux sin hacer uso del cargador. Cada proceso de arranque será diferente dependiendo de la arquitectura del procesador y el BIOS.

  1. El BIOS realiza las tareas de inicio específicas de la plataforma de hardware.
  2. Una vez que el hardware es reconocido y se inicia correctamente, el BIOS carga y ejecuta el código de la partición de arranque del dispositivo de arranque designado, que contiene la fase 1 de un gestor de arranque Linux. La fase 1 carga la fase 2 (la mayor parte del código del gestor de arranque). Algunos cargadores pueden utilizar una fase intermedia (conocida como la fase 1.5) para lograr esto, ya que los modernos discos de gran tamaño no pueden ser totalmente leídos sin código adicional.
  3. El gestor de arranque a menudo presenta al usuario un menú de opciones posibles de arranque. A continuación, carga el sistema operativo, que descomprime en la memoria, y establece las funciones del sistema como del hardware esencial y la paginación de memoria, antes de llamar a la función start_kernel().
  4. La función start_kernel() a continuación realiza la mayor parte de la configuración del sistema (interrupciones, el resto de la gestión de memoria, la inicialización del dispositivo, controladores, etc), antes de continuar por separado el proceso inactivo y planificador, y el proceso de Init (que se ejecuta en el espacio de usuario).
  5. El planificador toma control efectivo de la gestión del sistema, y el núcleo queda dormido (inactivo).
  6. El proceso Init ejecuta secuencias de comandos (Scripts) necesarios para configurar todos los servicios y estructuras que no sean del sistema operativo, a fin de permitir que el entorno de usuario sea creado y pueda presentarse al usuario con una pantalla de inicio de sesión.

En el apagado, Init es llamado a cerrar toda las funcionalidades del espacio de usuario de una manera controlada, de nuevo a través de secuencias de comandos, tras lo cual el Init termina y el núcleo ejecuta el apagado.

Espacio de usuario temprano

El espacio de usuario temprano se utiliza en las versiones más recientes del kernel de Linux para sustituir tantas funciones como sea posible que originalmente se harían en el núcleo durante el proceso de inicio. Los usos típicos del espacio de usuario temprano son para detectar que controladores de dispositivos (Drivers) son necesarios para cargar el sistema de archivos del espacio de usuario principal y cargarlos desde un sistema de archivos temporal.

Fase del cargador de arranque

Un cargador de arranque (boot loader en inglés) es un programa diseñado exclusivamente para cargar un sistema operativo en memoria. La etapa del cargador de arranque es diferente de una plataforma a otra.

Como en la mayoría de arquitecturas este programa se encuentra en el MBR, el cual es de 512 bytes, este espacio no es suficiente para cargar en su totalidad un sistema operativo. Por eso, el cargador de arranque consta de varias etapas. Las primeras operaciones las realiza el BIOS. En esta etapa se realizan operaciones básicas de hardware. En esta primera etapa se localiza el sector de arranque (o MBR) y se carga el cargador de este sector (normalmente una parte de LILO o GRUB).

A partir de ese momento, el proceso de arranque continúa de la siguiente manera:

La primera etapa del cargador de arranque carga el resto del gestor de arranque, que normalmente da un mensaje que pregunta que sistema operativo (o tipo de sesión) el usuario desea inicializar. Bajo LILO, esto se hace a través del mapa instalado que lee el archivo de configuración /etc/lilo.conf para identificar los sistemas disponibles. Incluye datos como la partición de arranque y la localización del kernel para cada uno, así como las opciones personalizadas en su caso. El sistema operativo seleccionado es cargado en la memoria RAM, un sistema de archivos mínimo inicial se establece en la memoria RAM desde un archivo de imagen (» initrd «), y junto con los parámetros adecuados, el control se pasa al sistema operativo activado recientemente.

LILO y GRUB difieren en algunos aspectos:

  • LILO no entiende los sistemas de archivos, por lo que utiliza desplazamientos de disco sin procesar y el BIOS para cargar los datos. Se carga el código del menú y, a continuación, en función de la respuesta, carga, o el sector MBR del disco de 512 bytes como en Microsoft Windows, o la imagen del kernel de Linux.
  • GRUB por el contrario comprende los sistemas de archivos comunes ext2 , ext3 y ext4. Debido a que GRUB almacena sus datos en un archivo de configuración en vez de en el MBR y a que contiene un interfaz de línea de comandos, a menudo es más fácil rectificar o modificar GRUB si está mal configurado o corrupto.

GRUB

GRUB se carga y se ejecuta en 4 etapas:

  1. La primera etapa del cargador la lee el BIOS desde el MBR.
  2. La primera etapa carga el resto del gestor de arranque (segunda etapa). Si la segunda etapa está en una unidad grande, en ocasiones se carga una fase intermedia 1.5, que contiene código adicional para permitir que los cilindros por encima de 1024, o unidades tipo LBA, puedan leerse. El gestor de arranque 1.5 es almacenado (si es necesario) en el MBR o en la partición de arranque.
  3. La segunda etapa del gestor de arranque ejecuta y muestra el menú de inicio de GRUB que permite al usuario elegir un sistema operativo y examinar y modificar los parámetros de inicio.
  4. Después de elegir un sistema operativo, se carga y se le pasa el control.

GRUB soporta métodos de arranque directo, arranque chain-loadingLBAext2ext3ext4 y hasta «un pre-sistema operativo en máquinas x86 totalmente basado en comandos». Contiene tres interfaces: un menú de selección, un editor de configuración, y una consola de línea de comandos.

LILO

LILO es más antiguo. Es casi idéntico a GRUB en su proceso, excepto que no contiene una interfaz de línea de comandos. Por lo tanto todos los cambios en su configuración deben ser escritos en el MBR y luego reiniciar el sistema. Un error en la configuración puede dejar el disco inservible para el proceso de arranque hasta tal grado, que sea necesario usar otro dispositivo (disquete, etc) que contenga un programa capaz de arreglar el error. Además, no entiende el sistema de archivos. En su lugar, la ubicación de los archivos de imagen se almacenan directamente en el MBR y el BIOS se utiliza para acceder a ellos directamente.

Loadlin

Otra forma de cargar Linux es desde DOS o Windows 9x, donde el núcleo de Linux reemplaza completamente la copia de funcionamiento de estos sistemas operativos. Esto puede ser útil en el caso de hardware que necesita ser conectado a través del software y la configuración de estos programas sólo está disponible para DOS y no para Linux, debido a cuestiones de secretos industriales y código propietario. Sin embargo, esta tediosa forma de arranque ya no es necesaria en la actualidad ya que Linux tiene drivers para multitud de dispositivos hardware. Aun así, esto era muy útil en el pasado.

Otro caso es cuando Linux se encuentra en un dispositivo que el BIOS no lo tiene disponible para el arranque. Entonces, DOS o Windows pueden cargar el driver apropiado para el dispositivo superando dicha limitación del BIOS, y cargar Linux desde allí.

Fase del kernel

El kernel de Linux se encarga de todos los procesos del sistema operativo, como la gestión de memoriaplanificador de tareasI/Ocomunicación entre procesos, y el control general del sistema. Este se carga en dos etapa: en la primera etapa el kernel (como un archivo imagen comprimido) se carga y se descomprime en memoria, y algunas funciones fundamentales como la gestión de memoria de base se establecen. El control entonces se cambia a la etapa final para iniciar el kernel principal. Una vez que el núcleo está en pleno funcionamiento – y como parte de su puesta en marcha, después de ser cargado y ejecutado – el kernel busca un proceso de inicio para ejecutar, que (separadamente) fija un espacio de usuario y los procesos necesarios para un entorno de usuario y ultimar la entrada . Al núcleo en sí entonces se le permite pasar a inactivo, sujeto a las llamadas de otros procesos.

Fase de carga del kernel

El kernel es cargado normalmente como un archivo imagen, comprimido dentro de otro con zlib como zImage o bzImage. Contiene una cabecera de programa que hace una cantidad mínima de instalación del hardware, descomprime la imagen completamente en la memoria alta , teniendo en cuenta cualquier disco RAM si está configurado. A continuación, lleva a cabo su ejecución. Esto se realiza llamando la función startup del kernel (en los procesadores x86 a través de la funciónstartup_32() del archivo /arch/i386/boot/head).

Fase de inicio del kernel

La función de arranque para el kernel (también llamado intercambiador o proceso 0) establece la gestión de memoria (tablas de paginación y paginación de memoria), detecta el tipo de CPU y cualquier funcionalidad adicional como capacidades depunto flotante, y después cambia a las funcionalidades del kernel para arquitectura no específicas de Linux, a través de una llamada a la función start_kernel().

start_kernel ejecuta una amplia gama de funciones de inicialización. Establece el manejo de interrupciones (IRQ), configura memoria adicional, comienza el proceso de inicialización (procesa el espacio del primer usuario), y luego comienza la tarea inactiva a través de cpu_idle(). En particular, el proceso de inicio del kernel también monta el disco RAM inicial («initrd«) que se ha cargado anteriormente como el sistema raíz temporal durante la fase de arranque. Esto permite que los módulos controladores se carguen sin depender de otros dispositivos físicos y drivers y mantiene el kernel más pequeño. El sistema de archivos raíz es cambiado más tarde a través de la llamada a pivot_root(), que desmonta el sistema de archivos temporal y lo reemplaza por el real una vez que éste sea accesible. La memoria utilizada por el sistema de archivos temporal es entonces recuperada.

Por lo tanto, el núcleo inicializa los dispositivos, monta el sistema de archivos raíz especificado por el gestor de arranque como de sólo lectura , y se ejecuta Init (/sbin/init), que es designado como el primer proceso ejecutado por el sistema (PID=1). También puede ejecutar opcionalmente initrd para permitir instalar y cargar dispositivos relacionados (disco RAM o similar), para ser manipulados antes de que el sistema de archivos raíz está montado.

En este punto, con las interrupciones habilitadas, el programador puede tomar el control de la gestión general del sistema, para proporcionar multitarea preventiva, e iniciar el proceso para continuar con la carga del entorno de usuario en el espacio de usuario.

El proceso de inicio

El trabajo de Init es «conseguir que todo funcione como debe ser» una vez que el kernel está totalmente en funcionamiento. En esencia, establece y opera todo el espacio de usuario. Esto incluye la comprobación y montaje de sistemas de archivos, la puesta en marcha los servicios de usuario necesarios y, en última instancia, cambiar al entorno de usuario cuando el inicio del sistema se ha completado. Es similar a los procesos Init de Unix y BSD, de la que deriva, pero en algunos casos se ha apartado o se hicieron a la medida. En un sistema Linux estándar, Init se ejecuta con un parámetro, conocido como nivel de ejecución, que tiene un valor entre 1 y 6, y que determina que subsistemas pueden ser operacionales. Cada nivel de ejecución tiene sus propios scripts que codifican los diferentes procesos involucrados en la creación o salida del nivel de ejecución determinado, y son estas secuencias de comandos los necesarios en el proceso de arranque. Los scripts de Init se localizan normalmente en directorios con nombres como «/etc/rc...«. El archivo de configuración de más alto nivel para Init es /etc/inittab.

Durante el arranque del sistema, se verifica si existe un nivel de ejecución predeterminado en el archivo /etc/inittab, si no, se debe introducir por medio de la consola del sistema. Después se procede a ejecutar todos los scripts relativos al nivel de ejecución especificado.

Después de que se han dado lugar todos los procesos especificados, Init se aletarga, y espera a que uno de estos tres eventos sucedan:- que procesos comenzados finalicen o mueran; un fallo de la señal de potencia (energía); o una petición a través de /sbin/telinit para cambiar el nivel de ejecución.

Módulos del Kernel Linux

  • admin 

Fuente: http://web.mit.edu/rhel-doc/3/rhel-sag-es-3/ch-kernel-modules.html

El kernel de Linux tiene un diseño modular. En el momento de arranque, sólo se carga un kernel residente mínimo en memoria. Por ello, cuando un usuario solicita alguna característica que no esta presente en el kernel residente, se carga dinámicamente en memoria un módulo kernel, también conocido algunas veces como un controlador.

Durante la instalación, se prueba el hardware en el sistema. Basado en esta prueba y en la información proporcionada por el usuario, el programa de instalación decide qué módulos necesita cargar en el momento de arranque. El programa de instalación configura el mecanismo de carga dinámica para que funcione de forma transparente.

Si se añade un nuevo hardware después de la instalación y este requiere un módulo kernel, el sistema debe ser configurado para cargar el módulo adecuado para el nuevo hardware. Cuando el sistema es arrancado con el nuevo hardware, se ejecuta el programa Kudzu detecta el nuevo hardware si es soportado y configura el módulo necesario para él. El módulo tambíen puede ser especificado manualmente modificando el archivo de configuración del módulo, /etc/modules.conf.

 

Nota Nota
Los módulos de tarjetas de vídeo usados para desplegar la interfaz del sistema X Window son parte del paquete XFree86, no del kernel; por lo tanto, este capítulo no se aplica a ellos.

Por ejemplo, si un sistema incluye un adaptador de red SMC EtherPower 10 PCI, el archivo de configuración del módulo contiene la línea siguiente:

alias eth0 tulip

Si una segunda tarjeta de red es añadida al sistema y es idéntica a la primera tarjeta, añada la línea siguiente al archivo /etc/modules.conf:

alias eth1 tulip

Consulte el Manual de referencia de Red Hat Enterprise Linux para una lista alfabética de módulos de kernel y hardware soportado por los módulos.

Nota: Kernels antiguos.

40.1. Utilidades del módulo del kernel

Está disponible un grupo de comandos para el manejo de módulos kernel si el paquete modutils está instalado. Use estos comandos para determinar si un módulo ha sido cargado exitósamente o cuando se esté probando módulos diferentes para una nueva pieza de hardware.

El comando /sbin/lsmod muestra una lista de los módulos cargados actualmente. Por ejemplo:

Module                  Size  Used by    Not tainted
iptable_filter          2412   0 (autoclean) (unused)
ip_tables              15864   1 [iptable_filter]
nfs                    84632   1 (autoclean)
lockd                  59536   1 (autoclean) [nfs]
sunrpc                 87452   1 (autoclean) [nfs lockd]
soundcore               7044   0 (autoclean)
ide-cd                 35836   0 (autoclean)
cdrom                  34144   0 (autoclean) [ide-cd]
parport_pc             19204   1 (autoclean)
lp                      9188   0 (autoclean)
parport                39072   1 (autoclean) [parport_pc lp]
autofs                 13692   0 (autoclean) (unused)
e100                   62148   1
microcode               5184   0 (autoclean)
keybdev                 2976   0 (unused)
mousedev                5656   1
hid                    22308   0 (unused)
input                   6208   0 [keybdev mousedev hid]
usb-uhci               27468   0 (unused)
usbcore                82752   1 [hid usb-uhci]
ext3                   91464   2
jbd                    56336   2 [ext3]

Por cada línea, la primera columna es el nombre del módulo, la segunda columna es el tamaño del módulo y la tercera es el recuento de usos.

La información después del recuento de usos varía un poco por módulo. Si se lista (unused) en la línea del módulo, el módulo no está siendo usado actualmente. Si (autoclean) está en la línea para el módulo, este puede ser limpiado automáticamente por el comando rmmod -a. Cuando se ejecuta este comando, cualquier módulo que este etiquetado con autoclean, que no ha sido usado desde la acción previa de autoclean, será descargado. Red Hat Enterprise Linux no realiza esta acción de autoclean por defecto.

Si el nombre de un módulo esta listado al final de la línea entre corchetes, el módulo entre corchetes es dependiente del módulo listado en la primera columna de la línea. Por ejemplo, en la línea

usbcore                82752   1 [hid usb-uhci]

los módulo del kernel hid usb-uhci dependen del módulo usbcore.

La salida /sbin/lsmod es la misma que la salida de /proc/modules.

Para cargar un módulo del kernel, use el comando /sbin/modprobe seguido del nombre del módulo. Por defecto, modprobe intenta cargar el módulo desde los subdirectorios/lib/modules/<kernel-version>/kernel/drivers/. Hay un subdirectorio para cada tipo de módulo, tal como el subdirectorio net/ para los controladores de interfaces de red. Algunos módulos del kernel tienen dependencias, es decir que otros módulos deben ser cargados antes para que el otro se cargue. El comando /sbin/modprobe verifica estas dependencias y carga los módulos necesarios antes de cargar el módulo específico.

Por ejemplo, el comando

/sbin/modprobe hid

carga cualquier dependencia de módulos y luego el módulo hid.

Para imprimir a la pantalla todos los comandos a medida en que /sbin/modprobe los ejecuta, use la opción -v. Por ejemplo:

/sbin/modprobe -v hid

Se despliega una salida similar a lo siguiente:

/sbin/insmod /lib/modules/2.4.21-1.1931.2.399.ent/kernel/drivers/usb/hid.o
Using /lib/modules/2.4.21-1.1931.2.399.ent/kernel/drivers/usb/hid.o
Symbol version prefix 'smp_'

El comando /sbin/insmod también existe para cargar módulos kernel; sin embargo no resuelve dependencias. Por ello se recomienda el uso de /sbin/modprobe.

Para descargar módulos del kernel, use el comando /sbin/rmmod seguido por el nombre del módulo. La utilidad rmmod sólo descarga módulos que ya no son usados y que no son una dependencia de otro módulo en uso.

Por ejemplo, el comando

/sbin/rmmod hid

baja el módulo del kernel hid.

Otra utilidad muy conveniente es modinfo. Use el comando /sbin/modinfo para mostrar información sobre el módulo del kernel. La sintaxis general es:

/sbin/modinfo [options] <module>

Las opciones incluyen -d, lo cual muestra una breve descripción del módulo, y -p lo que lista los parámetros que el módulo soporta. Para una lista completa de las opciones, consulte la página del manual de modinfo (man modinfo).

Cómo cambiar los niveles de ejecución en Fedora 15 y posteriores

Con la aparición de Fedora 15 Lovelock, muchas cosas han cambiado en esta distribución GNU/Linux y una de ellas es la forma de configurar los distintos niveles de ejecución del sistema.

Recordemos que en versiones anteriores, la configuración de los distintos niveles de ejecución que por defecto podía emplear el sistema, se realizaba por medio de la edición del archivo ‘inittab’.

  • $ su -c ‘nano /etc/inittab’

id:nivel-ejecución:initdefault:

Siendo ‘nivel-ejecución’ uno de los siguientes valores:

0 –  Detiene todos los procesos activos en el sistema y realiza un completo apagado del equipo.

1 – Nivel monousuario sin acceso a los servicios de red.

2 – Nivel multiusuario en modo consola sin acceso a los servicios de red.

3 – Nivel multiusuario en modo consola con acceso a los servicios de red.

4 – Nivel no usado.

5 – Nivel multiusuario en modo gráfico (X11).

6 – Detiene todos los procesos activos en el sistema y realiza el reinicio del equipo.

En la actualidad, ha variado sustancialmente ésta forma de establecer los distintos niveles de ejecución del sistema (ahora llamados target), debido al uso de ‘systemd‘ en detrimento del archivo ‘inittab’.

Puesto que el actual sistema cuenta por defecto con dos (target) principales: (multi-user) equivalente al modo 3 y (graphical) equivalente almodo 5, la forma de pasar de un modo a otro, es la siguiente: 

  • $ su -c ‘ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target’ (para el modo 3) ó
  • $ su -c ‘ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target’ (para el modo 5)
  • Reiniciar el sistema.

Linux-Based X Terminals with XDMCP

  • admin 

Fuente: http://www.linuxjournal.com/article/6713

A tutorial for configuring XDMCP on your network so you can use old equipment, cut down on administration duties and cut costs.

Want to get some use out of your early 90s vintage PC, the one barely powerful enough to run Windows 3.1? Need to outfit a group of users with workstations on a budget? Tired of administering a homogeneous workgroup from afar? Want to introduce Linux to a group of Windows or Mac users with the least amount of resistance? Can’t stop tinkering with the oodles of options Linux offers? XDMCP may be for you, even if you answered yes to even one of these questions.The X display manager control protocol (XDMCP for short) provides a means for a user sitting at one (client) computer running X to communicate with another (server) computer running an X display manager. Once a connection is established, the user can log in and run programs as if the user were sitting at the remote computer. The station where the user sits often is referred to as an X terminal, which essentially is a window into the server. All of the software resides on the server, all of the processing is done on the server’s CPU, and all of the files to be accessed reside on the server.So, for those of you trying to reduce administration hassles, this means you have to administer only the servers. The clients’ software remains the same. For those trying to get some use out of old equipment, the speed of the client computers and the size of their hard drives is nearly irrelevant. Even my old Pentium 120 with a CPU upgrade to 180 MHz, 32MB of RAM and a 1GB hard disk provides more than enough muscle to be an X terminal. And, for those trying to outfit a workgroup on a budget, as many as five or six cheap computers can be configured as X terminals for every expensive workstation configured as a server. This would require a fast local network, however. Finally, for those trying to introduce Linux to Windows and Mac users, the only necessary intrusion into their machines is the installation of an X server, and free ones exist.
Basic Configuration

XDMCP is a communication protocol with the power to deliver all the items listed above. A word of caution is in order, however. XDMCP is an inherently insecure protocol. Although technologically nothing is standing in the way of running XDMCP between two computers on the Internet or on an untrusted network, it should never be done. It is too easy for hackers to snoop and grab such critical information as usernames and passwords transmitted over the connection without encryption. XDMCP should be run across only a trusted network. If you need to provide an X terminal across an untrusted network, a slower, slightly less convenient way to do this is mentioned in the security section.

Assuming you have not been scared off, to begin configuring XDMCP, be sure the computer to become the X terminal and the one to become the server are connected over your network. The simplest way to check this is to ping one from the other. If you can ping in both directions, you are ready to begin the configuration.

If you are trying to get some use out of old hardware or trying to outfit a workgroup or lab on a budget, the most powerful machine(s) is your server(s). In the case of bringing the power of Linux to Windows or Mac users, the Linux machine(s) is your server(s). For now, I assume you are configuring only one server. Multiple server set up is discussed later.

The server must be running some display manager, the standard being xdm. Both gdm and kdm, respectively the GNOME and KDE replacements for xdm, are shipped with many distributions and offer preconfigured interfaces that are likely to be sexier than what is offered by xdm. Operationally, they all are capable of providing X terminal services. In fact, if your server boots into a graphical login screen, you already are running a display manager. To find out which one, login and issue the command ps -A | grep dm. The results should be something like

634 ? 00:00:00 cardmgr
857 ? 00:00:00 gdm-binary
889 ? 00:00:00 gdm-binary

which means you are running gdm. If your computer boots into a text login screen, you either can reconfigure it to boot into a graphical login or run a display manager from the command line after logging in as root. This second option is useful only as a temporary solution while you are experimenting, however.

If you intend to use the machine as an XDMCP server, it’s best to configure it to run a display manager upon booting. This is done by modifying /etc/inittab. The default run level is set in the line containing initdefault. It should read

id:5:initdefault:

Once you have made this change, you may reboot or issue the command telinit 5 to get a graphical login. Be sure X is set up with a resolution less than or equal to the resolution to be used on the X terminals.

At this point, the impatient may skip the rest of this section and configure an X terminal. If your distribution shipped with XDMCP enabled and configured to serve fonts and no firewall gets in your way, you should have a fully functional XDMCP server. For the patient, simply continue reading and reconfiguring or verifying that XDMCP is configured correctly.

At this point, I assume you are patient or you’re back here because your attempt to connect an X terminal failed. One likely reason for a failed connection is the firewall on the server or, worse, somewhere else in your network. To temporarily disable the firewall on the server while you attempt to configure XDMCP, issue the commandipchains -F (or iptables -F) on the server. This eliminates the firewall altogether. To be more selective about your firewall policies, you may try the ipchains (or similar iptables) command

ipchains -A input -p udp -i $extint --dport 177 -j ACCEPT

In addition, make the following changes (if necessary) to the following xdm configuration files. In /etc/X11/xdm/xdm-config, change the lineDisplayManager.requestPort: 0 to !DisplayManager.requestPort: 0 (that is, comment it out) so that the server can listen for XDMCP connections. In /etc/X11/xdm/Xaccess, change the line #* # any host can get a login window to * # any host can get a login window so others can access xdm. If you are not using kdm or gdm as your display manager, you are done with this part. However, if you are using kdm, you must edit kdmrc as well. Under Red Hat, this file is located in /etc/X11/xdm. In the [Xdmcp] section, set Enable=true and uncomment the linePort=177. If you are using gdm, you must make the same modifications to gdm.conf, which is located in /etc/X11/gdm under Red Hat.

Configuring an X terminal simply amounts to installing an X server and running an X query. No window manager or desktop environment are necessary. This is why the X terminal’s hardware is relatively unimportant, except perhaps the network interface card. There are at least three ways to configure an X terminal to utilize XDMCP. One way is to setup a dummy terminal to run X with no window manager and no applications and then have the XDMCP server push a login screen onto the terminal. This is covered in this useful mini how-to.

I, however, will stick to configuring a not-quite-so-dumb X terminal. This means the X terminal must have some operating system with a configured X server installed. In case of Linux, Windows or Macintosh, an implementation of XFree86 is available free of charge. For Linux, installing XWindows is an option that should be chosen when the OS is installed. For Windows, consider installing Cygwin with the (optional) XFree86base package and dependencies installed. For Mac, consider installingXDarwin, an implementation of the XFree86 server. X servers are available for many other platforms as well, and any one is sufficient to run an X terminal.

Once you have an X server installed, all you need to do is run it with a query option. Three types of queries are available. If you are running only one XDMCP server, it is best to use a direct query. This is done from a non-X shell, not an xterm. If you are running Linux or UNIX, you should configure the machine to boot to a text login. If this already is the case, you are all set. If not, this is done, under Linux, by modifying the default run level in /etc/inittab. The default run level is set on the line containing initdefault. It should read

id:3:initdefault:

Once you have made this change, you may reboot or issue the command telinit 3 to get a text login. Log in as any user and issue the command X -query my.XDMCP.server, where my.XDMCP.server is either the name or IP address of the XDMCP server. If you are running windows and have installed Cygwin, from the Cygwin bash shell, issue the command XWin.exe -query my.XDMCP.server. If you are running Mac OS and have installed XDarwin, from a terminal issue the same command as used under Linux/UNIX. You should see the graphical login window of your XDMCP server. If you are having font issues, consult this excellent how-toto find the necessary server configurations to resolve the issue.

Customizing the Login Screen

The display manager login screen and chooser interface are fully customizable. If you are running gdm, you may use the graphical setup utility gdmsetup or modify the text file /etc/X11/gdm/gdm.conf. If you are running kdm, modify /etc/X11/xdm/kdmrc. If you are running xdm, start with modifying /etc/X11/xdm/Xresources. If you don’t find everything you want to customize in these files, look at the other files in /etc/X11/xdm/, for example, XSetup_0 or xdm-config. I expect most people choose to use gdm or kdm, so I won’t go into details on xdm customization. Also, because gdm offers a graphical customization tool, I scratch only the surface of customizations, focusing on kdm customization under Red Hat only.

Regardless of which display manager you run, you may want to consider customizing a few things. For example, you may want your own background image and your own welcome message to appear on the login screen, and you definitely want to prevent users from shutting down the server through the login window. For kdm users, the background image is presented on the login screen by an auxiliary program called xsri. Under Red Hat, the script /etc/X11/xdm/XSetup_0 checks for the existence of the program and the associated file /etc/X11/xsrirc. If both exist, xsri is run and the graphic indicated in /etc/X11/xsrirc is displayed on the login screen. So, if you want to change the background image, simply change the graphic file listed in /etc/X11/xsrirc. To change the welcome message, find the GreetString option under the [X-*-Greeter] section of the file kdmrc. You may set this string equal to anything you like, but long messages may not display fully or may distort the appearance of the login window. Macros may be used in the GreetString too. For example, the default greeting is «Welcome to %s at %n» where %s is expanded into the operating system and %n is expanded into the node name (usually the hostname without domain name). Other macros are available and are listed above the GreetString line in kdmrc.

Finally, and most importantly, you need to keep regular users from shutting down the server. Allowing them to shut down is dangerous because they may shut it down while other users are working on the same machine. Again, inside the file kdmrc, find the AllowShutdown option under both the [X-*-Core] section and the [X-:*-Core] section and set them both to Root. This change requires the root password in order to shut down the machine from the login window. Additionally, when a user logs out of a session, the shutdown option does not appear in the ensuing dialog box. However, you may prefer to set these options to None, in which case the shutdown button will not appear at all in the login window.

Multiple Server Setup

Multiple servers may be set up in exactly the manner described in the section on configuring a server, and they can be accessed by X terminals in exactly the manner described in the section on configuring an X terminal. However, this requires the user to pick a server to login to and to know its name or IP address. A more effective method of managing multiple servers is to run a chooser and have users of X terminals submit indirect queries.

To begin, configure each server as described previously. Then, pick one machine to run a chooser. On this machine, modify the file /etc/X11/xdm/Xaccess in one of two ways. The easiest way is to uncomment the line * CHOOSER BROADCAST. When an indirect query is received, the chooser sends out a broadcast query and displays a list of machines that responded to the query. The X terminal user then may select to log in to one of these machines. This setup does not work in all environments, however, and you may not want to give users access to all servers on your network.

To be selective as to which servers are reported by the chooser, comment out the line* CHOOSER BROADCAST by putting a # at the beginning and uncomment the lines#%hostlist host-a host-b and #* CHOOSER %hostlist. Then, replace host-a host-bwith a space-separated list of all hosts that you wish to appear in the chooser. This way, the chooser can send direct queries to each machine in the list and report the results to the chooser.

Finally, to see the chooser from an X terminal, run X with the option -indirect my.XDMCP.chooser, where my.XDMCP.chooser is the name of the machine configured to supply a chooser. Under UNIX, remember the command to run X is X and under Cygwin it is XWin.exe.

Further Information

Advantages: the main advantages of running XDMCP are clear from the goal you wish to meet by running it. However, there are some disadvantages, one big one being the lack of security. Additionally, access to the X terminal’s sound card, floppy drive, CD-ROM drive, scanner and any other local hardware besides the keyboard, mouse and monitor is difficult at best. I do not have a reasonable solution to offer on this issue. Perhaps someone can offer one in a future article.

Security: as stated earlier, XDMCP is an insecure protocol. However, if you require X terminal services over an insecure network, there is at least one option. Instead of setting up your server to run XDMCP, configure it as an SSH (secure shell) server. Then, from the X terminal, start an X session running nothing but an xterm, not even a window manager. From this xterm, issue the command ssh -X loginname@ssh.server, where ssh.server is the name or IP address of the ssh server and loginname is your login on the server. The -X enables X11 forwarding over the secure connection. After logging in, issue startkde to begin a KDE session or gnome-session to begin a GNOME session. Alternatively, you may run a full blown desktop environment on the X terminal, run an xterm there and issue the command ssh -X loginname@ssh.server command where command is the command/program you wish to run. This allows you to run a single program at a time on the remote machine rather than on a desktop environment.

Installing and running an SSH server and client should be straightforward. For example, Red Hat ships with an optional sshd (server) package and the client is installed by default. For Cygwin, an OpenSSH client is an optional package. For more information than you probably care to know about SSH, see www.openssh.org or read the man pages on SSH and sshd.

References

XDMCP How-To by Thomas Chao

XDM-Xterm Mini How-To by Kevin Taylor.

Much of the information for this article was taken from these two documents. Additionally, each how-to contains a list of more reference materials.

Author –> Leon Brin has been a member of the mathematics department at Southern CT State University for three years and a Linux enthusiast for five. He welcomes your comments at brin@southernct.edu.

Particiones en Linux

  • ¿Dónde instalo Linux?

Linux se puede instalar en cualquier disco que tengas en tu sistema y en cualquier particion del disco duro (Primaria o extendida).
No podras tener Linux en una particion compartida con otro sistema operativo, Linux necesita su propia particion/es para funcionar.

  •  ¿Qué es una particion? ¿Cómo creo una particion?

Particionar el disco duro es una manera de dividir el disco físico en varios discos lógicos. O lo que es lo mismo, al particionar un disco, dividimos el disco en varias particiones independientes unas de otras, creando la ilusión de que tenemos diferentes discos, cuando en realidad lo que tenemos es un solo disco físico dividido en partes.

Una particion es una de estas partes (divisiones) del disco.

Existen dos clases de particiones: primarias y extendidas. En un disco solo podras tener como maximo 4 particiones primaria y 1 extendida. En la particion extendida se podran definir todas (bueno tambien existe un limite, pero es alto) las unidades logicas que queramos. Con este sistema podemos tener una gran cantidad de particiones en nuestro disco.

Cualquier disco que tengamos en nuestro ordenador tiene al menos una particion primaria, que en la mayoria de los casos tiene un tamano equivalente al total del disco.

Unos ejemplos aclararan las cosas:

  • Un disco de 1Gb con una sola particion, tendra una particion primaria de 1Gb (total del disco).
  • Ese mismo disco podria tener 4 particiones primarias de 0.25Gb cada una, dando la ilusion de que tenemos 4 discos duros de 0.25Gb en vez de un solo disco de 1Gb.
  • Otra combinacion posible podria ser 4 particiones primarias de 0.10Gb y 1 extendida con 6 unidades logicas de 0.10Gb, en este caso pareceria que tenemos 10 discos duros de 0.10Gb cada uno.

Las combinaciones son multiples y variadas y dependeran de nuestros gustos y de lo que necesitemos.

Casi todos los sistemas operativos traen un programa con el que podemos crear, modificar, borrar las particiones de nuestro disco. En Ms-Dos/Windows de llama FDISK, este programa solo puede trabajar con particiones de Ms-Dos/Windows. En Linux tambien se llama FDISK (/sbin/fdisk), pero es un programa mas potente, capaz de trabajar y crear particiones tanto para Linux como otros sistemas operativos. Si vas a trabajar con Linux, es recomendable el uso del FDISK que viene con tu distribucion, para evitar problemas.

Al contrario que Ms-Dos, Windows, OS/2, las diferentes particiones en linux no se denominan C:, D:, E:, …., etc, existe una denominacion propia:

Si los discos son IDE:

  • /dev/hda: Disco duro IDE como master en el canal IDE 1.
  • /dev/hda1: Particion primaria 1 en /dev/hda
  • /dev/hda2: Particion primaria 2 en /dev/hda
  • /dev/hda3: Particion primaria 3 en /dev/hda
  • /dev/hda4: Particion primaria 4 en /dev/hda
  • /dev/hda5: Particion extendida 1 en /dev/hda
  • /dev/hda6: Particion extendida 2 en /dev/hda
  • …..
  • …..
  • /dev/hda16: Particion extendida 16 en /dev/hda
  • /dev/hdb: Disco duro IDE como esclavo en el canal IDE 1.
  • /dev/hdb1: Particion primaria 1 en /dev/hdb
  • ……..
  • ……..
  • /dev/hdc: Disco duro IDE como master en el canal IDE 2.
  • /dev/hdc1: Particion primaria 1 en /dev/hdc
  • ……..
  • ……..
  • /dev/hdd: Disco duro IDE como esclavo en el canal IDE 2.
  • /dev/hdd1: Particion primaria 1 en /dev/hdd
  • ……..
  • ……..

Si los discos son SCSI:

  • /dev/sda: Disco duro SCSI nr.1.
  • /dev/sda1: Particion primaria 1 en /dev/sda
  • ……..
  • ……..
  • /dev/sdb: Disco duro SCSI nr.2.
  • /dev/sdb1: Particion primaria 1 en /dev/sdb
  • ……..
  • ……..

IMPORTANTE: Es muy importante saber lo que se esta haciendo cuando trabajeis con programas que modifican la tabla de particiones de un disco. Al cambiar la tabla de particiones de vuestro disco, se pierden los datos contenidos en las particiones afectadas. Realizar copias de seguridad de los datos que querais mantener antes de usar FDISK.

  • ¿Porque necesito diferentes particiones?

El particionar el disco, es simplemente una manera de organizar tu disco duro. Podrás organizarlo con una sola particion o en varias. Es el usuario el que deberá decidir cuantas particiones tendra su disco, y el tamano de las mismas, hay que recordar, que al menos hay que tener una particion primaria.

Desventajas de tener vuestro disco dividido en diferentes particiones.

  • Ninguna

Ventajas en tener vuestro disco particionado en varias particiones:

  • Si teneis un error/problema en una de ellas, las demas no se veran afectadas.
  • Poder tener diferentes sistemas operativos en vuestra maquina, totalmente independientes unos de otros.
  • Poder tener vuestros archivos de datos en particiones totalmente independientes.
  • Poder borrar/cambiar el contenido de una particion, sin que esto afecte a las demas.

  • ¿Cuantas particiones necesito para Linux?

La respuesta rapida y facil es: recomendable al menos dos, una para el sistema/datos y otra para Swap. Usualmente se suelen tener tres, una para el sistema/programas (/), otra para los datos (/home) y otra para swap.

La respuesta larga y no tan facil es mas complicada de explicar: Todo dependera muchisimo del uso que se le vaya a dar al sistema.

Para sistemas que se utilicen de forma particular y por uno o pocos usuarios bastara con las dos/tres particiones antes mencionadas, esto evitara los problemas de saber que cantidad de espacio necesitan las diferentes particiones y el quedarnos sin espacio en alguna particion vital, mientras que nos sobra en otras.

Para sistemas servidores, con gran cantidad de servicios y usuarios es muy recomendable tener varias particiones/discos. Existe un documento (HOWTO: Multi Disk System Tuning) muy bueno y quizas complicado para el principiante que explica cuantas particiones y discos y que tamano deberian tener en funcion del uso que se le vaya a dar al sistema, lo podeis encontrar en http://www.nyx.net/~sgjoen/disk.html o en cualquier servidor con documentacion Howto. Otro documento (HOWTO: Linux Partition) mas sencillo, se puede encontrar enhttp://linux-es.uio.no/docs/HOWTO/mini/Partition.

  • ¿Qué es la Swap?

La swap es un espacio reservado en tu disco duro para poder usarse como una extension de memoria virtual de tu sistema. Es una técnica utilizada desde hace tiempo para hacer creer a los programas que existe mas memoria RAM de la que en realidad existe. Es el propio sistema operativo el que se encarga de pasar datos a la swap cuando necesita mas espacio libre en la RAM y viceversa.

En Linux, la memoria total disponible por el sistema estara formada por la cantidad de memoria RAM instalada + la swap disponible. El acceso a la swap (disco duro) es mas lento que el acceso a la memoria RAM, por lo que si nuestro ordenador esta muy cargado de trabajo y hace un uso intensivo de la swap, la velocidad del sistema disminuira. Un uso muy intensivo y continuado de la swap es un indicativo de que necesitamos mas memoria en nuestro sistema para que funcione desahogado con el uso que le estamos dando.

En linux generalmente se usa como minimo una particion dedicada a swap (aunque tambien se puede tener un fichero swap).

  • ¿Cuanta Swap necesito?
  • En equipos con memoria RAM de hasta 1 Giga debería ser igual de grande la SWAP que la RAM.
  • Entre 2 y 4 Gigas, debería ser la SWAP la mitad de grande que la RAM.
  • Con más de 4 Gigas no se debería sobrepasar los 2 Gigas de SWAP como mucho.

 


Linux Directory Structure

  • admin 

Note: Files are grouped according to purpose. Ex: commands, data files, documentation.
Parts of a Unix directory tree. See the FSSTND standard (Filesystem standard)

/			Root
|---root		The home directory for the root user
|---home		Contains the user's home directories
|    |----ftp		Users include many services as listed here
|    |----httpd
|    |----samba
|    |----user1
|    |----user2
|---bin			Commands needed during bootup that might be needed by normal users
|---sbin		Like bin but commands are not intended for normal users.  Commands run by LINUX.
|---proc		This filesystem is not on a disk.  Exists in the kernels imagination (virtual).  This directory
|    |			Holds information about kernel parameters and system configuration.
|    |----1		A directory with info about process number 1.  Each process
|				has a directory below proc.  
|---usr			Contains all commands, libraries, man pages, games and static files for normal
|    |			operation.
|    |----bin		Almost all user commands.  some commands are in /bin or /usr/local/bin.
|    |----sbin		System admin commands not needed on the root filesystem.  e.g., most server 
|    |			programs.
|    |----include	Header files for the C programming language.  Should be below /user/lib for
|    |			consistency.
|    |----lib		Unchanging data files for programs and subsystems
|    |----local		The place for locally installed software and other files.
|    |----man		Manual pages
|    |----info		Info documents
|    |----doc		Documentation for various packages
|    |----tmp
|    |----X11R6		The X windows system files.  There is a directory similar to usr below this 
|    |			directory.
|    |----X386		Like X11R6 but for X11 release 5
|---boot		Files used by the bootstrap loader, LILO.  Kernel images are often kept here.
|---lib			Shared libraries needed by the programs on the root filesystem
|    |----modules 	Loadable kernel modules, especially those needed to boot the system after
|			 disasters.
|---dev			Device files for devices such as disk drives, serial ports, etc.
|---etc			Configuration files specific to the machine.
|    |----skel		When a home directory is created it is initialized with files from this directory
|    |----sysconfig 	Files that configure the linux system for networking, keyboard, time, and more.
|---var			Contains files that change for mail, news, printers log files, man pages, temp files
|    |----file
|    |----lib		Files that change while the system is running normally
|    |----local		Variable data for programs installed in /usr/local.
|    |----lock		Lock files.  Used by a program to indicate it is using a particular device or file
|    |----log		Log files from programs such as login and syslog which logs all logins,
|    |			logouts, and other system messages.
|    |----run		Files that contain information about the system that is valid until the system is
|    |			next booted
|    |----spool		Directories for mail, printer spools, news and other spooled work.
|    |----tmp		Temporary files that are large or need to exist for longer than they should in
|    |			/tmp.
|    |----catman	A cache for man pages that are formatted on demand
|---mnt			Mount points for temporary mounts by the system administrator.
|---tmp			Temporary files.  Programs running after bootup should use /var/tmp.

Administración Usuarios Linux

Linux es un sistema multiusuario, por lo tanto, la tarea de añadir, modificar, eliminar y en general administrar usuarios se convierte en algo no solo rutinario, sino importante, además de ser un elemento de seguridad que mal administrado o tomado a la ligera, puede convertirse en un enorme hoyo de seguridad. En este manual aprenderás todo lo necesario para administrar completamente tus usuarios en GNU/Linux.

Tipos de usuarios

Los usuarios en Unix/Linux se identifican por un número único de usuario, User ID, UID. Y pertenecen a un grupo principal de usuario, identificado también por un número único de grupo, Group ID, GID. El usuario puede pertenecer a más grupos además del principal.

Aunque sujeto a cierta polémica, es posible identificar tres tipos de usuarios en Linux:

Usuario root

  • También llamado superusuario o administrador.
  • Su UID (User ID) es 0 (cero).
  • Es la única cuenta de usuario con privilegios sobre todo el sistema.
  • Acceso total a todos los archivos y directorios con independencia de propietarios y permisos.
  • Controla la administración de cuentas de usuarios.
  • Ejecuta tareas de mantenimiento del sistema.
  • Puede detener el sistema.
  • Instala software en el sistema.
  • Puede modificar o reconfigurar el kernel, controladores, etc.

Usuarios especiales

  • Ejemplos: bin, daemon, adm, lp, sync, shutdown, mail, operator, squid, apache, etc.
  • Se les llama también cuentas del sistema.
  • No tiene todos los privilegios del usuario root, pero dependiendo de la cuenta asumen distintos privilegios de root.
  • Lo anterior para proteger al sistema de posibles formas de vulnerar la seguridad.
  • No tienen contraseñas pues son cuentas que no están diseñadas para iniciar sesiones con ellas.
  • También se les conoce como cuentas de «no inicio de sesión» (nologin).
  • Se crean (generalmente) automáticamente al momento de la instalación de Linux o de la aplicación.
  • Generalmente se les asigna un UID entre 1 y 100 (definifo en /etc/login.defs)

Usuarios normales

  • Se usan para usuarios individuales.
  • Cada usuario dispone de un directorio de trabajo, ubicado generalmente en /home.
  • Cada usuario puede personalizar su entorno de trabajo.
  • Tienen solo privilegios completos en su directorio de trabajo o HOME.
  • Por seguridad, es siempre mejor trabajar como un usuario normal en vez del usuario root, y cuando se requiera hacer uso de comandos solo de root, utilizar el comando .
  • En las distros actuales de Linux se les asigna generalmente un UID superior a 500.


/etc/passwd

Cualquiera que sea el tipo de usuario, todas las cuentas se encuentran definidas en el archivo de configuración ‘‘, ubicado dentro del directorio . Este archivo es de texto tipo ASCII, se crea al momento de la instalación con el usuario root y las cuentas especiales, más las cuentas de usuarios normales que se hayan indicado al momento de la instalación.

El archivo  contiene una línea para cada usuario, similar a las siguientes:

root:x:0:0:root:/root:/bin/bash
sergio:x:501:500:Sergio González:/home/sergio:/bin/bash

La información de cada usuario está dividida en 7 campos delimitados cada uno por ‘:’ dos puntos.

/etc/passwd
Campo 1 Es el nombre del usuario, identificador de inicio de sesión (login). Tiene que ser único.
Campo 2 La ‘x’ indica la contraseña encriptada del usuario, además también indica que se está haciendo uso del archivo , si no se hace uso de este archivo, este campo se vería algo así como: ‘‘.
Campo 3 Número de identificación del usuario (UID). Tiene que ser único. 0 para root, generalmente las cuentas o usuarios especiales se numeran del 1 al 100 y las de usuario normal del 101 en delante, en las distribuciones mas recientes esta numeración comienza a partir del 500.
Campo 4 Numeración de identificación del grupo (GID). El que aparece es el número de grupo principal del usuario, pero puede pertenecer a otros, esto se configura en .
Campo 5 Comentarios o el nombre completo del usuario.
Campo 6 Directorio de trabajo (Home) donde se sitúa al usuario después del inicio de sesión.
Campo 7 Shell que va a utilizar el usuario de forma predeterminada.

 

/etc/shadow

Anteriormente (en sistemas Unix) las contraseñas cifradas se almacenaban en el mismo  El problema es que ‘passwd’ es un archivo que puede ser leído por cualquier usuario del sistema, aunque solo puede ser modificado por root. Con cualquier computadora potente de hoy en día, un buen programa de descifrado de contraseñas y paciencia es posible «crackear» contraseñas débiles (por eso la conveniencia de cambiar periódicamente la contraseña de root y de otras cuentas importantes). El archivo ‘shadow’, resuelve el problema ya que solo puede ser leido por root. Considérese a ‘shadow’ como una extensión de ‘passwd’ ya que no solo almacena la contraseña encriptada, sino que tiene otros campos de control de contraseñas.

El archivo  contiene una línea para cada usuario, similar a las siguientes:

root:ghy675gjuXCc12r5gt78uuu6R:10568:0:99999:7:7:-1::
sergio:rfgf886DG778sDFFDRRu78asd:10568:0:-1:9:-1:-1::

La información de cada usuario está dividida en 9 campos delimitados cada uno por ‘:’ dos puntos.

/etc/shadow
Campo 1 Nombre de la cuenta del usuario.
Campo 2 Contraseña cifrada o encriptada, un ‘*’ indica cuenta de ‘nologin’.
Campo 3 Días transcurridos desde el 1/ene/1970 hasta la fecha en que la contraseña fue cambiada por última vez.
Campo 4 Número de días que deben transcurrir hasta que la contraseña se pueda volver a cambiar.
Campo 5 Número de días tras los cuales hay que cambiar la contraseña. (-1 significa nunca). A partir de este dato se obtiene la fecha de expiración de la contraseña.
Campo 6 Número de días antes de la expiración de la contraseña en que se le avisará al usuario al inicio de la sesión.
Campo 7 Días después de la expiración en que la contraseña se inhabilitara, si es que no se cambio.
Campo 8 Fecha de caducidad de la cuenta. Se expresa en días transcurridos desde el 1/Enero/1970 (epoch).
Campo 9 Reservado.

 

/etc/group

Este archivo guarda la relación de los grupos a los que pertenecen los usuarios del sistema, contiene una línea para cada usuario con tres o cuatro campos por usuario:

root:x:0:root
ana:x:501:
sergio:x:502:ventas,supervisores,produccion
cristina:x:503:ventas,sergio

 

  • El campo 1 indica el usuario.
  • El campo 2 ‘x’ indica la contraseña del grupo, que no existe, si hubiera se mostraría un ‘hash’ encriptado.
  • El campo 3 es el Group ID (GID) o identificación del grupo.
  • El campo 4 es opcional e indica la lista de grupos a los que pertenece el usuario

 

Actualmente al crear al usuario con  se crea también automáticamente su grupo principal de trabajo GID, con el mismo nombre del usuario. Es decir, si se añade el usuario ‘sergio’ también se crea el /etc/group el grupo ‘sergio’. Aun asi, existen comandos de administración de grupos que se explicarán más adelante.

 pwconv y pwunconv

El comportamiento por defecto de todas las distros modernas de GNU/Linux es activar la protección extendida del archivo , que (se insiste) oculta efectivamente el ‘hash’ cifrado de la contraseña de .

Pero si por alguna bizarra y extraña situación de compatibilidad se requiriera tener las contraseñas cifradas en el mismo archivo de  se usaría el comando :

#> more /etc/passwd
root:x:0:0:root:/root:/bin/bash
sergio:x:501:500:Sergio González:/home/sergio:/bin/bash
...

#> more /etc/shadow
root:ghy675gjuXCc12r5gt78uuu6R:10568:0:99999:7:7:-1::
sergio:rfgf886DG778sDFFDRRu78asd:10568:0:-1:9:-1:-1::

#> pwunconv
#> more /etc/passwd
root:ghy675gjuXCc12r5gt78uuu6R:0:0:root:/root:/bin/bash
sergio:rfgf886DG778sDFFDRRu78asd:501:500:Sergio González:/home/sergio:/bin/bash
...
#> more /etc/shadow
/etc/shadow: No such file or directory

En cualquier momento es posible reactivar la protección de shadow:

#> pwconv
#> ls -l /etc/passwd /etc/shadow
-rw-r--r-- 1 root root 1106 2007-07-08 01:07 /etc/passwd
-r-------- 1 root root  699 2009-07-08 01:07 /etc/shadow

Se vuelve a crear el archivo , además nótese los permisos tan restrictivos (400) que tiene este archivo, haciendo sumamente difícil (no me gusta usar imposible, ya que en informática parece ser que los imposibles ‘casi’ no existen) que cualquier usuario que no sea root lo lea.

 /etc/login.defs

En el archivo de configuración  están definidas las variables que controlan los aspectos de la creación de usuarios y de los campos de  usadas por defecto. Algunos de los aspectos que controlan estas variables son:

  • Número máximo de días que una contraseña es válida PASS_MAX_DAYS
  • El número mínimo de caracteres en la contraseña PASS_MIN_LEN
  • Valor mínimo para usuarios normales cuando se usa  UID_MIN
  • El valor  por defecto UMASK
  • Si el comando  debe crear el directorio home por defecto CREATE_HOME

Basta con leer este archivo para conocer el resto de las variables que son autodescriptivas y ajustarlas al gusto. Recúerdese que se usaran principalmente al momento de crear o modificar usuarios con los comandos  y  que en breve se explicaran.

Añadir usuarios con 

 o  es el comando que permite añadir nuevos usuarios al sistema desde la línea de comandos. Sus opciones más comunes o importantes son las siguientes:

  • -c añade un comentario al momento de crear al usuario, campo 5 de 
  • -d directorio de trabajo o home del usuario, campo 6 de 
  • -e fecha de expiración de la cuenta, formato AAAA-MM-DD, campo 8 de 
  • -g número de grupo principal del usuario (GID), campo 4 de 
  • -G otros grupos a los que puede pertenecer el usuario, separados por comas.
  • -r crea una cuenta del sistema o especial, su UID será menor al definido en  en la variable UID_MIN, además no se crea el directorio de inicio.
  • -s shell por defecto del usuario cuando ingrese al sistema. Si no se especifica, bash, es el que queda establecido.
  • -u UID del usuario, si no se indica esta opción, automáticamente se establece el siguiente número disponible a partir del último usuario creado.

Ahora bien, realmente no hay prácticamente necesidad de indicar ninguna opción ya que si hacemos lo siguiente:

#> useradd juan

Se creará el usuario y su grupo, asi como las entradas correspondientes en /etc/passwd, /etc/shadow y /etc/group. También se creará el directorio de inicio o de trabajo: /home/juan y los archivos de configuración que van dentro de este directorio y que más adelante se detallan.

Las fechas de expiración de contraseña, etc. Quedan lo más amplias posibles asi que no hay problema que la cuenta caduque, asi que prácticamente lo único que faltaría sería añadir la contraseña del usuario y algún comentario o identificación de la cuenta. Como añadir el password o contraseña se estudiara en un momento y viendo las opciones con ‘-c’ es posible establecer el comentario, campo 5 de /etc/passwd:

#> useradd -c "Juan Perez Hernandez" juan

Siempre el nombre del usuario es el último parámetro del comando. Asi por ejemplo, si queremos salirnos del default, podemos establecer algo como lo siguiente:

#> useradd -d /usr/juan -s /bin/csh -u 800 -c "Juan Perez Hernandez" juan

Con lo anterior estamos cambiando su directorio de inicio, su shell por defautl sera csh y su UID será el 800 en vez de que el sistema tome el siguiente número disponible.

Modificar usuarios con 

Como su nombre lo indica, usermod permite modificar o actualizar un usuario o cuenta ya existente. Sus opciones más comunes o importantes son las siguientes:

  • -c añade o modifica el comentario, campo 5 de 
  • -d modifica el directorio de trabajo o home del usuario, campo 6 de 
  • -e cambia o establece la fecha de expiración de la cuenta, formato AAAA-MM-DD, campo 8 de
  • -g cambia el número de grupo principal del usuario (GID), campo 4 de 
  • -G establece otros grupos a los que puede pertenecer el usuario, separados por comas.
  • -l cambia el login o nombre del usuario, campo 1 de  y de 
  • -L bloque la cuenta del usuario, no permitiendolé que ingrese al sistema. No borra ni cambia nada del usuario, solo lo deshabilita.
  • -s cambia el shell por defecto del usuario cuando ingrese al sistema.
  • -u cambia el UID del usuario.
  • -U desbloquea una cuenta previamente bloqueada con la opción -L.

Si quiseramos cambiar el nombre de usuario de ‘sergio’ a ‘sego’:

#> usermod -l sego sergio

Casi seguro también cambiará el nombre del directorio de inicio o HOME en /home, pero si no fuera así, entonces:

#> usermod -d /home/sego sego

Otros cambios o modificaciones en la misma cuenta:

#> usermod -c "supervisor de area" -s /bin/ksh -g 505 sego

Lo anterior modifica el comentario de la cuenta, su shell por defecto que ahora sera Korn shell y su grupo principal de usuario quedó establecido al GID 505 y todo esto se aplicó al usuario ‘sego’ que como se observa debe ser el último argumento del comando.

El usuario ‘sego’ salió de vacaciones y nos aseguramos de que nadie use su cuenta:

#> usermod -L sego

Eliminar usuarios con userdel

Como su nombre lo indica, userdel elimina una cuenta del sistema, userdel puede ser invocado de tres maneras:

#> userdel sergio

Sin opciones elimina la cuenta del usuario de  y de , pero no elimina su directorio de trabajo ni archivos contenidos en el mismo, esta es la mejor opción, ya que elimina la cuenta pero no la información de la misma.

#> userdel -r sergio

Al igual que lo anterior elimina la cuenta totalmente, pero con la opción -r además elimina su directorio de trabajo y archivos y directorios contenidos en el mismo, asi como su buzón de correo, si es que estuvieran configuradas las opciones de correo. La cuenta no se podrá eliminar si el usuario esta logueado o en el sistema al momento de ejecutar el comando.

#> userdel -f sergio

La opción -f es igual que la opción -r, elimina todo lo del usuario, cuenta, directorios y archivos del usuario, pero además lo hace sin importar si el usuario esta actualmente en el sistema trabajando. Es una opción muy radical, además de que podría causar inestabilidad en el sistema, asi que hay que usarla solo en casos muy extremos.

Cambiar contraseñas con 

Crear al usuario con  es el primer paso, el segundo es asignarle una contraseña a ese usuario. Esto se logra con el comando  que permitirá ingresar la contraseña y su verificación:

#> passwd sergio
Changing password for user prueba.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
#>

El usuario  es el único que puede indicar el cambio o asignación de contraseñas de cualquier usuario. Usuarios normales pueden cambiar su contraeña en cualquier momento con tan solo invocar  sin argumentos, y podrá de esta manera cambiar la contraseña cuantas veces lo requiera.

 tiene integrado validación de contraseñas comunes, cortas, de diccionario, etc. asi que si por ejemplo intento como usuario normal cambiar mi contraseña a ‘qwerty’ el sistema me mostrará lo siguiente:

$> passwd 
Changing password for user prueba.
New UNIX password:
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
$>

Nótese que al ingresar ‘qwerty’ como contraseña se detectó que es una secuencia ya conocida como contraseña y me manda la advertencia: «BAD PASSWORD: it is based on a dictionary word», sin embargo me permite continuar, al ingresar la verificación. Es decir, passwd avisa de malas o débiles contraseñas pero permite establecerlas si realmente se desea.

Resumiendo entonces, se podría decir que todo este tutorial se reduce a dos líneas de comandos para crear y dejar listo para trabajar a un usuario en Linux:

#> useradd ana
#> passwd ana

Se crea el usuario ‘ana’,  hace todo el trabajo de establecer el shell, directorio de inicio, copiar archivos iniciales de configuración de la cuenta, etc. y después  establece la contraseña. Asi de simple.

 tiene varias opciones que permiten bloquear la cuenta ‘-l’, desbloquearla ‘-u’, y varias opciones más que controlan la vigencia de la contraseña, es decir, es otro modo de establecer los valores de la cuenta en. Para más información consulta las páginas del manual:

$> man passwd

 

Archivos de configuración

Los usuarios normales y  en sus directorios de inicio tienen varios archivos que comienzan con «.» es decir están ocultos. Varían mucho dependiendo de la distribución de Linux que se tenga, pero seguramente se encontrarán los siguientes o similares:

#> ls -la
drwx------ 2 ana  ana  4096 jul  9 09:54 .
drwxr-xr-x 7 root root 4096 jul  9 09:54 ..
-rw-r--r-- 1 ana  ana    24 jul  9 09:54 .bash_logout
-rw-r--r-- 1 ana  ana   191 jul  9 09:54 .bash_profile
-rw-r--r-- 1 ana  ana   124 jul  9 09:54 .bashrc

 aquí podremos indicar alias, variables, configuración del entorno, etc. que deseamos iniciar al principio de la sesión.

 aquí podremos indicar acciones, programas, scripts, etc., que deseemos ejecutar al salirnos de la sesión.

 es igual que .bash_profile, se ejecuta al principio de la sesión, tradicionalmente en este archivo se indican los programas o scripts a ejecutar, a diferencia de .bash_profile que configura el entorno.

Lo anterior aplica para terminales de texto 100%.

Si deseamos configurar archivos de inicio o de salida de la sesión gráfica entonces, en este caso, hay que buscar en el menú del ambiente gráfico algún programa gráfico que permita manipular que programas se deben arrancar al iniciar la sesión en modo gráfico. En la mayoría de las distribuciones existe un programa llamado «sesiones» o «sessions», generalmente esta ubicado dentro del menú de preferencias. En este programa es posible establecer programas o scripts que arranquen junto con el ambiente gráfico, sería equivalente a manipular ‘bashrc’.

Además Linux permite que el usuario decida que tipo de entorno Xwindow a utilizar, ya sea algún entorno de escritorio como KDE o Gnome o algún manejador de ventanas como Xfce o Twm. Dentro del Home del usuario, se creará un directorio o archivo escondido «.» , por ejemplo ‘.gnome’ o ‘.kde’ donde vendrá la configuración personalizada del usuario para ese entorno. Dentro de este directorio suele haber varios directorios y archivos de configuración. Estos son sumamente variados dependiendo de la distribución y del entorno. No es recomendable modificar manualmente (aunque es perfectamente posible) estos archivos, es mucho mas sencillo modificar vía las interfases gráficas que permiten cambiar el fondo, protector de pantalla, estilos de ventanas, tamaños de letras, etc.

Resumen de comandos y archivos de administración de usuarios

Existen varios comandos más que se usan muy poco en la administración de usuarios, que sin embargo permiten administrar aun más a detalle a tus usuarios de Linux. Algunos de estos comandos permiten hacer lo mismo que los comandos previamente vistos, solo que de otra manera, y otros como ‘chpasswd’ y ‘newusers’ resultan muy útiles y prácticos cuando de dar de alta a múltiples usuarios se trata.

A continuación te presento un resumen de los comandos y archivos vistos en este tutorial más otros que un poco de investigación

Comandos de administración y control de usuarios
adduser Ver useradd
chage Permite cambiar o establecer parámetros de las fechas de control de la contraseña.
chpasswd Actualiza o establece contraseñas en modo batch, múltiples usuarios a la vez. (se usa junto con newusers)
id Muestra la identidad del usuario (UID) y los grupos a los que pertence.
gpasswd Administra las contraseñas de grupos (/etc/group y /etc/gshadow).
groupadd Añade grupos al sistema (/etc/group).
groupdel Elimina grupos del sistema.
groupmod Modifica grupos del sistema.
groups Muestra los grupos a los que pertence el usuario.
newusers Actualiza o crea usuarios en modo batch, múltiples usuarios a la vez. (se usa junto chpasswd)
pwconv Establece la protección shadow (/etc/shadow) al archivo /etc/passwd.
pwunconv Elimina la protección shadow (/etc/shadow) al archivo /etc/passwd.
useradd Añade usuarios al sistema (/etc/passwd).
userdel Elimina usuarios del sistema.
usermod Modifica usuarios.

 

Archivos de administración y control de usuarios
.bash_logout Se ejecuta cuando el usuario abandona la sesión.
.bash_profile Se ejecuta cuando el usuario inicia la sesión.
.bashrc Se ejecuta cuando el usuario inicia la sesión.
/etc/group Usuarios y sus grupos.
/etc/gshadow Contraseñas encriptadas de los grupos.
/etc/login.defs Variables que controlan los aspectos de la creación de usuarios.
/etc/passwd Usuarios del sistema.
/etc/shadow Contraseñas encriptadas y control de fechas de usuarios del sistema.

 

Ambientes gráficos y Web

Si usas Linux con Xwindow (gnome, kde, etc.) encontrarás dentro de los menús una o varias opciones gráficas de administración de usuarios, asi como programas basados en Web como webmin que entre muchas otras cosas te permiten un control total de la administración de usuarios y grupos. Estos programas de gestión de usuarios son sumamente intuitivos y en una sola pantalla a través de sus opciones puedes controlar prácticamente todas las funciones expuestas en este tutorial, en lo particular recomiendo webmin por su confiablidad y alto nivel de configuración, además que es accesible via web.
Usuarios y grupos en Fedora

Programa de control de usuarios, disponible en Fedora a través del menú Escritorio -> Administración -> Usuarios y grupos, o desde una terminal de comandos o shell con el comando , debes de ser root en cualquier caso.
Usuarios y grupos en Fedora

Webmin en el módulo de añadir usuarios. Excelente herramienta de configuración y administración de múltiples aspectos de Linux.