Está en la página 1de 527

Guía de Estudio

LFS201: Fundamentos de Administración de


Sistemas Linux

LFS201: Fundamentos de Administración de Sistemas Linux 1


Contenido
Guía de Estudio..................................................................................................................................1
Capítulo 1. Prólogo...........................................................................................................................23
1.1 Introducción...........................................................................................................................24
1.2 Relacion con LFS101x2...........................................................................................................24
1.3 Uso como preparación para el examen LFCS....................................................................25
1.4 Formato del curso...................................................................................................................27
1.5 La Documentación............................................................................................................27
1.6 Plataforma de trabajo.......................................................................................................28
1.7 Linea de comandos vs. Interfaz Gra.ca............................................................................28
1.8 Distribuciones de Linux a u/lizar............................................................................................29
1.9 Instalacion: que usar para este curso...............................................................................30
1.10 Calendario del curso.........................................................................................................30
1.11 Laboratorios y Ejercicios.......................................................................................................31
1.12 Cambio, repe/ción y guerras santas.................................................................................32
1.13 Acerca de Linux Founda/on.............................................................................................32
1.14 Eventos de Linux Founda/on................................................................................................33
1.15 Cer/.caciones..................................................................................................................34
Laboratorio 1.1.............................................................................................................................35
Capítulo 2. Inicio y Apagado del Sistema..........................................................................................37
Obje/vos de aprendizaje..............................................................................................................37
2.1 Comprendiendo la secuencia de inicio...................................................................................38
2.2 Bios.........................................................................................................................................39
2.3 Gestores de arranque.............................................................................................................39
2.4 Archivos de Con.guracion en /etc..........................................................................................40
2.5 /etc/syscon.g.........................................................................................................................40
2.6 /etc/default............................................................................................................................41
2.7 Apagado y Reinicio.................................................................................................................42
Comprobación de conocimientos 2.1...........................................................................................43
2.8 Laboratorio 2.1.......................................................................................................................44
Obje/vos de aprendizaje (revisión)..............................................................................................44
Capítulo 3. GRUB..............................................................................................................................45

LFS201: Fundamentos de Administración de Sistemas Linux 2


Obje/vos de aprendizaje..............................................................................................................45
3.1 Que es GRUB?........................................................................................................................46
3.2 Selecciones Interac/vas con GRUB en el arranque.................................................................47
3.3 Instalación de GRUB...............................................................................................................48
3.4 Nomenclatura de disposi/vos de GRUB.................................................................................49
3.5 Personalizando el archivo de con.guración GRUB.................................................................50
Comprobación de conocimientos 3.1...........................................................................................52
3.6 Laboratorio 3.1.......................................................................................................................53
Obje/vos de aprendizaje (revision)..............................................................................................54
Capítulo 4. init: SystemV, Upstart, Systemd......................................................................................55
Obje/vos de Aprendizaje.............................................................................................................55
4.1 Proceso init.............................................................................................................................56
4.2 Alterna/vas de arranque........................................................................................................57
4.3 Niveles de ejecución de SysVinit.............................................................................................57
4.4 SysVinit y /etc/ini@ab.............................................................................................................59
4.5 Scripts de inicio de SysVinit....................................................................................................59
4.6 chkcon.g................................................................................................................................61
4.7 .a. service...............................................................................................................................62
4.7 .b. service...............................................................................................................................63
4.8 chkcon.g service en sistemas basados en debian..................................................................63
4.9 Upstart...................................................................................................................................64
4.10 U/lidades de Upstart............................................................................................................65
4.11 systemd................................................................................................................................65
4.12 Archivos de con.guración de systemd..................................................................................66
4.13 systemctl..............................................................................................................................66
Comprobacion de Conocimientos 4.1..........................................................................................69
4.14 Laboratorio 4.1.....................................................................................................................70
4.14 Laboratorio 4.2.....................................................................................................................72
Obje/vos de aprendizaje (Revision).............................................................................................73
Capítulo 5. Diseño del Árbol del Sistema de Archivos de Linux........................................................74
Obje/vos de aprendizaje..............................................................................................................74
5.1 Un sistema de archivos grande...............................................................................................75
5.2 Diferencia de los datos...........................................................................................................75

LFS201: Fundamentos de Administración de Sistemas Linux 3


5.3 FHS Estandar de Jerarquia del sistema de Archivos................................................................76
5.4 Diseño del directorio principal...............................................................................................76
5.5 El directorio y sistema de archivos raíz (/)..............................................................................77
5.6 /bin.........................................................................................................................................77
5.7 /boot......................................................................................................................................78
5.8 Otros archivos y directorios en /boot.....................................................................................79
5.9 /dev........................................................................................................................................80
5.10 /etc.......................................................................................................................................81
5.11 /home...................................................................................................................................81
5.12 /lib........................................................................................................................................82
5.13 /media..................................................................................................................................82
5.14 /mnt.....................................................................................................................................83
5.15 /opt.......................................................................................................................................83
5.16 /proc.....................................................................................................................................84
5.17 /root.....................................................................................................................................85
5.18 /sys.......................................................................................................................................85
5.19 /sbin.....................................................................................................................................85
5.20 /tmp.....................................................................................................................................86
5.21 /usr.......................................................................................................................................86
5.22 /var.......................................................................................................................................87
5.23 /run......................................................................................................................................88
Comprobación de conocimientos 5.1...........................................................................................88
Comprobación de conocimientos 5.2...........................................................................................89
5.24 Laboratorio 5.1.....................................................................................................................89
Obje/vos de aprendizaje (revision)..............................................................................................93
Capítulo 6. Servicios del Kernel y Con.guración...............................................................................94
Obje/vos de Aprendizaje.............................................................................................................94
6.1 Información General del Kernel..............................................................................................95
6.2 Tareas Principales del Kernel..................................................................................................95
6.3 Línea de comandos del Kernel................................................................................................95
6.4 Parametros de Inicio del Kernel..............................................................................................97
6.5 sysctl.......................................................................................................................................98
Comprobación de Conocimientos 6.1..........................................................................................99

LFS201: Fundamentos de Administración de Sistemas Linux 4


6.6 Laboratorio 6.1.......................................................................................................................99
6.6 Laborator/o 6.2....................................................................................................................100
Obje/vos de aprendizaje (Revision)...........................................................................................101
Capítulo 7. Módulos del Kernel......................................................................................................102
Obje/vos de Aprendizaje...........................................................................................................102
7.1 Ventajas de los módulos del Kernel......................................................................................103
7.2 Herramientas de trabajo con módulos.................................................................................103
7.3 Carga y descraga de mósulos................................................................................................104
7.4 modprobe.............................................................................................................................105
7.5 Algunas consideraciones en relación a los modulos.............................................................105
7.6 modinfo................................................................................................................................106
7.7 Parámetros en los Módulos..................................................................................................107
7.8 Con.guracion en los modulos del kernel..............................................................................107
Comprobacion de Conocimientos 7.1........................................................................................107
7.9 Laboratorio 7.1.....................................................................................................................108
Obje/vos de aprendizaje (Revisión)...........................................................................................108
Capítulo 8. Disposi/vos y UDEV......................................................................................................109
Obje/vos de aprendizaje............................................................................................................109
8.1 Nodos de disposi/vo............................................................................................................110
8.2 Numeros mayor y menor......................................................................................................111
8.3 udev......................................................................................................................................112
8.4 Componentes de udev.........................................................................................................113
8.5 udev y hotplug......................................................................................................................113
8.6 El gestor de disposi/vos udev...............................................................................................114
8.7 Archivos de reglas udev........................................................................................................114
8.8 Creando reglas udev.............................................................................................................115
8.9 Algunos ejemplos de archivos y reglas.................................................................................115
Comprobacion de Conocimientos 8.1........................................................................................116
Obje/vos de aprendizaje (revision)............................................................................................116
Capítulo 9. Par/cionamiento y Formateo de Discos...................................................................117
Obje/vos de aprendizaje............................................................................................................117
9.1 Tipos comunes de discos......................................................................................................118
9.2 Geometria del disco.............................................................................................................119

LFS201: Fundamentos de Administración de Sistemas Linux 5


9.3 Par/cionamiento..................................................................................................................120
9.4 Por qué par/cionar?.............................................................................................................121
9.5 Tabla de par/ciones..............................................................................................................122
9.6 Nombres de disposi/vos de disco y nodos...........................................................................123
9.7 Más cerca de nombres de disposi/vos SCSI.........................................................................123
9.8 blkid y lsblk...........................................................................................................................124
9.9 Dimensionando par/ciones..................................................................................................125
9.10 Respaldar y restaurar tablas de par/ciones........................................................................126
9.11 Editores de la tabla de par/ciones.....................................................................................127
9.12 Uso de fdisk........................................................................................................................127
Comprobacion de conocimientos 9.1.........................................................................................128
Comprobacion de conocimientos 9.2.........................................................................................129
9.13 Lab 9.1................................................................................................................................129
9.13 Lab 9.2................................................................................................................................131
9.13 Lab 9.3................................................................................................................................134
9.13 Lab 9.4................................................................................................................................137
Obje/vos de aprendizaje (Revision)...........................................................................................137
Capítulo 10. Cifrado de Discos........................................................................................................138
Obje/vos de aprendizaje............................................................................................................138
10.1 Por qué u/lizar cifrado?......................................................................................................139
10.2 Luks....................................................................................................................................139
10.3 crypsetup............................................................................................................................139
10.4 uso de una par/ción cifrada...............................................................................................140
10.5 Montado en el arranque.....................................................................................................141
Comprobacion de conocimientos 10.1.......................................................................................141
10.6 Laboratorio 6.1...................................................................................................................142
10.6 Laboratorio 6.1...................................................................................................................144
Obje/vos de aprendizaje (Revision)...........................................................................................145
Capítulo 11. Sistemas de archivos Linux y el VFS............................................................................146
Obje/vos de aprendizaje............................................................................................................146
11.1 Conceptos básicos de un sistema de archivos....................................................................147
11.2 Con.guracion del árbol del sistema de archivos.................................................................147
11.3 Virtual File System (VFS).....................................................................................................147

LFS201: Fundamentos de Administración de Sistemas Linux 6


11.4 Sistemas de archivos disponbles........................................................................................149
11.5 Sistemas de archivos transaccionales.................................................................................150
11.6 Sistemas de archivos soportados en el sistema local..........................................................151
11.7 Sistemas de archivos especiales.........................................................................................151
Comprobacion de conocimientos 11.1.......................................................................................152
Comprobacion de conocimientos 11.2.......................................................................................153
11.8 Laboratorio 11.1.................................................................................................................154
Obje/vos de aprendizaje (Revision)...........................................................................................156
Capítulo 12. Caracterís/cas de los sistemas de archivos: atributos, creación, veri.cación, montado
.......................................................................................................................................................157
Obje/vos de aprendizaje............................................................................................................157
12.1 Inodos.................................................................................................................................158
12.2 Archivos de directorio........................................................................................................159
12.3 Atributos extendidos y lsa@r/cha@r....................................................................................159
12.4 Crear y formatear sistemas de archivos..............................................................................160
12.5 Veri.car y reparar sistemas de archivos.............................................................................161
12.6 Montar y desmontar sistemas de archivos.........................................................................162
12.7 mount.................................................................................................................................163
12.8 Opciones de mount............................................................................................................164
12.9 umount...............................................................................................................................165
12.10 Montar sistemas de archivos en el arranque....................................................................166
12.11 Lista de los sistemas de archivos montados actualmente................................................167
Comprobacion de conocimientos 12.1.......................................................................................168
Comprobacion de conocimientos 12.2.......................................................................................168
12.12 Laboratorio 12.1...............................................................................................................169
12.12 Laboratorio 12.2...............................................................................................................171
Obje/vos de aprendizaje (Revision)...........................................................................................174
Capítulo 13. Caracterís/cas del sistema de archivos: intercambio, cuotas, uso.............................175
Obje/vo de aprendizaje.............................................................................................................175
13.1 Intercambio (swap).............................................................................................................176
13.2 Cuotas................................................................................................................................177
13.3 Con.guracion del sistema de cuotas..................................................................................178
13.4 quotacheck.........................................................................................................................179

LFS201: Fundamentos de Administración de Sistemas Linux 7


13.5 Habilitar y deshabilitar cuotas............................................................................................179
13.6 Examinar cuotas.................................................................................................................181
13.7 Con.guracion de cuotas especi.cas...................................................................................181
13.8 Uso del sistema de archivos...............................................................................................182
13.9 Uso del espacio en disco....................................................................................................183
Comprobacion de conocimientos 13.1.......................................................................................183
Comprobacion de conocimientos 13.2.......................................................................................183
Comprobacion de conocimientos 13.3.......................................................................................184
13.10 Laboratorio 13.1...............................................................................................................184
13.10 Laboratorio 13.2...............................................................................................................185
Obje/vos de aprendizaje (Revision)...........................................................................................187
Capítulo 14. Los sistemas de archivos Ext2/Ext3/Ext4....................................................................188
Obje/vos de aprendizaje............................................................................................................188
14.1 Historia de ext4 y datos básicos.........................................................................................189
14.2 Caracteris/ca de ext4.........................................................................................................189
14.3 Diseño de ext4....................................................................................................................190
14.4 Grupos de bloques.............................................................................................................191
14.5 dumpe2fs...........................................................................................................................192
14.6 tune2fs...............................................................................................................................194
14.7 Informacion del superbloque.............................................................................................194
14.8 Bloques de datos e inodos..................................................................................................195
14.9 Mejoras del sistema de archivos ext4.................................................................................196
Comprobacion de conocimientos 14.1.......................................................................................196
14.10 Laboratorio 14.1...............................................................................................................197
14.10 Laboratorio 14.2...............................................................................................................199
Obje/vos de aprendizaje (revision)............................................................................................200
Capítulo 15. Los sistemas de archivos XFS y btrfs...........................................................................201
Obje/vos de aprendizaje............................................................................................................201
15.1 Caracteris/cas de XFS.........................................................................................................202
15.2 Mantenimiento del sistema de archivos XFS......................................................................202
15.3 El sistema de archivos btrfs................................................................................................203
Comprobacion de conocimientos 15.1.......................................................................................204
15.4 Laboratorio 15.1.................................................................................................................204

LFS201: Fundamentos de Administración de Sistemas Linux 8


Obje/vos de aprendizaje (Revision)...........................................................................................205
Capítulo 16. Logical Volume Manager (LVM)..................................................................................206
Obje/vos de aprendizaje............................................................................................................206
16.1 LVM....................................................................................................................................207
16.2 LVM y RAID.........................................................................................................................208
16.3 Columenes y Grupos de volúmenes...................................................................................208
16.4 Herramientas de volúmenes lógicos...................................................................................209
16.5 Creacion de volúmenes lógicos..........................................................................................210
16.6 Desplegar información de los volúmenes lógicos...............................................................211
16.7 Redimensionar volúmenes lógicos.....................................................................................211
16.8 Ejemplos de rendimiento...................................................................................................212
16.9 Snapshots de LVM..............................................................................................................212
Comprobacion de conocimientos 16.1.......................................................................................213
Comprobacion de conocimientos 16.2.......................................................................................214
16.10 Laboratorio 16.1...............................................................................................................214
Obje/vos de aprendizaje (Revision)...........................................................................................216
Capítulo 17. RAID...........................................................................................................................217
Obje/vos de aprendizaje............................................................................................................217
17.1 RAID....................................................................................................................................218
17.2 Niveles de RAID..................................................................................................................219
17.3 Con.guracion de RAID de soNware....................................................................................219
17.4 Monitoreo de RAID.............................................................................................................220
17.5 Discos de reserva de RAID..................................................................................................221
Comprobacion de conocimientos 17.1.......................................................................................222
Comprobacion de conocimientos 17.2.......................................................................................222
17.6 Laboratorio 17.1.................................................................................................................223
Obje/vos de aprendizaje (revision)............................................................................................225
Capítulo 18. Seguridad del sistema local........................................................................................226
Obje/vos de aprendizaje............................................................................................................226
18.1 Seguridad del sistema local................................................................................................227
18.2 Crear uan plo/ca de seguridad...........................................................................................227
18.3 Que incluir en la polí/ca de seguridad...............................................................................228
18.4 Riesgos a evaluar................................................................................................................228

LFS201: Fundamentos de Administración de Sistemas Linux 9


18.5 Elegir una .losoOa de seguridad.........................................................................................229
18.6 Guias generales de seguridad.............................................................................................229
18.7 Actualizaciones y seguridad................................................................................................230
18.8 Acceso al hardware y vulnerabilidades...............................................................................230
18.9 Directrices de acceso al hardware......................................................................................231
18.10 Proteccion de la BIOS.......................................................................................................231
18.11 Proteccion del cargador de arranque con contraseña......................................................232
18.12 Seguridad del sistema de archivos: opciones de mount...................................................233
18.13 setuid y setgid..................................................................................................................233
18.14 Con.guracion de los bits setuid/setgid.............................................................................234
Comprobacion de conocimientos 18.1.......................................................................................234
18.15 Laboratorio 18.1...............................................................................................................235
18.15 Laboratorio 18.2...............................................................................................................236
Obje/vos de aprendizaje (Revision)...........................................................................................237
Capítulo 19. Módulos de seguridad de Linux.................................................................................238
Obje/vos de aprendizaje............................................................................................................238
19.1 Que son los modulos de seguridad de Linux?.....................................................................239
19.2 Alterna/vas de LSM............................................................................................................239
19.3 Resumen de SElinux...........................................................................................................240
19.4 Modulos de SELinux...........................................................................................................240
19.5 Poli/cas de SELinux............................................................................................................242
19.6 Herramientas de contexto..................................................................................................242
19.7 SELinux y herramientas estándar de línea de comandos....................................................243
19.8 Herencia y preservación de contecto de SELinux...............................................................244
19.9 restorecon..........................................................................................................................245
19.19 semanage fcontext...........................................................................................................245
19.11 Uso de booleanos de SELinux...........................................................................................246
19.12 getsebool y setsebool.......................................................................................................247
19.13 heramientas de resolución de problemas........................................................................248
19.14 Recursos adicionales en línea...........................................................................................251
19.15 AppArmor.........................................................................................................................251
Comprobacion de conocimientos 19.1.......................................................................................252
Comprobacion de conocimientos 19.2.......................................................................................252

LFS201: Fundamentos de Administración de Sistemas Linux 10


19.16 laboratorio 19.1................................................................................................................253
Obje/vos de aprendizaje (revision)............................................................................................255
Capítulo 20. Procesos.....................................................................................................................256
Obje/vos de aprendizaje............................................................................................................256
20.1 Procesos, programas y hebras............................................................................................257
20.2 El proceso init.....................................................................................................................257
20.3 Procesos.............................................................................................................................258
20.4 Atributos de un proceso.....................................................................................................259
20.5 Control de procesos con ulimit...........................................................................................259
20.6 Permisos de los procesos y setuid......................................................................................260
20.7 Estados de un proceso........................................................................................................261
20.8 Modos de ejecución...........................................................................................................261
20.9 Modo usuario.....................................................................................................................262
20.10 Modo Kernel.....................................................................................................................262
20.11 Demonios.........................................................................................................................263
20.12 Procesos creados por el kernel.........................................................................................263
20.13 Creacion de procesos y forking.........................................................................................264
20.14 Creacion de procesos en una Shell...................................................................................265
20.15 Uso de nice para establecer prioridades..........................................................................265
20.16 Modi.car el valor de nice.................................................................................................266
Comprobacion de conocimientos 20.1.......................................................................................266
Comprobacion de conocimientos 20.2.......................................................................................267
20.17 Laboratorio 20.1...............................................................................................................267
20.17 Laboratorio 20.2...............................................................................................................269
Obje/vos de aprendizaje (revisión)............................................................................................271
Capítulo 21. Señales.......................................................................................................................272
Obje/vos de aprendizaje............................................................................................................272
21.1 Qué son las señales?..........................................................................................................273
21.2 Tipos de señales.................................................................................................................273
21.3 kill.......................................................................................................................................274
21.4 killall y pkill.........................................................................................................................276
Comprobacion de conocimientos 21.1.......................................................................................276
Comprobacion de conocimientos 21.2.......................................................................................276

LFS201: Fundamentos de Administración de Sistemas Linux 11


Comprobacion de conocimientos 21.3.......................................................................................277
Comprobacion de conocimientos 21.4.......................................................................................277
Obje/vos de aprendizaje (revisión)............................................................................................277
Capítulo 22. Monitoreo del sistema...............................................................................................278
Obje/vos de aprendizaje............................................................................................................278
22.1 Herramientas disponibles de monitoreo............................................................................279
22.2 Los pseudosistemas de archivos /proc y /sys......................................................................280
22.3 Conceptos básicos de /proc................................................................................................280
22.4 un vistazo de /proc.............................................................................................................280
22.5 /proc/sys.............................................................................................................................284
22.6 Condeptos básicos de /sys..................................................................................................285
22.7 Un vistazo de /sys...............................................................................................................286
22.8 sar.......................................................................................................................................288
Comprobacion de conocimientos 22.1.......................................................................................290
Comprobacion de conocimientos 22.2.......................................................................................290
Comprobacion de conocimientos 22.3.......................................................................................290
Comprobacion de conocimientos 22.4.......................................................................................291
22.9 Laboratorio 22.1.................................................................................................................291
Obje/vos de aprendizaje (revision)............................................................................................292
Capítulo 23. Monitoreo de procesos..............................................................................................293
Obje/vos de aprendizaje............................................................................................................293
23.1 Herramientas de monitoreo...............................................................................................294
23.2 Visualizacion del estado de los procesos con ps.................................................................294
23.3 Opcion de formato BSD para ps..........................................................................................295
23.4 Campos de salida de ps......................................................................................................296
23.5 Opcion de formato UNIX para ps........................................................................................297
23.6 Personalizar la salida de ps.................................................................................................298
23.7 Uso de pstree.....................................................................................................................298
23.8 Visulaizar la carga del sistema con top...............................................................................299
23.9 Opciones de top.................................................................................................................300
Comprobacion de conocimientos 23.1.......................................................................................301
Comprobacion de conocimientos 23.2.......................................................................................301
23.10 Laboratorio 23.1...............................................................................................................301

LFS201: Fundamentos de Administración de Sistemas Linux 12


23.10 Laboratorio 23.1...............................................................................................................302
Obje/vos de aprendizaje (Revision)...........................................................................................304
Capítulo 24. Monitoreo y ajuste de E/S..........................................................................................305
Obje/vos de aprendizaje............................................................................................................305
24.1 Cuellos de botella de disco.................................................................................................306
24.2 iostat...................................................................................................................................306
24.3 Opciones de iostat..............................................................................................................307
24.4 Opciones extendidas de iostat............................................................................................308
24.5 iotop...................................................................................................................................309
24.6 Uso de ionice para ajustar prioridades de E/S....................................................................310
Comprobacion de conocimientos 24.1.......................................................................................311
24.7 Laboratorio 24.1.................................................................................................................311
24.7 Laboratorio 24.2.................................................................................................................314
Obje/vos de aprendizaje (Revision)..........................................................................................316
Capítulo 25. Plani.cación de E/S....................................................................................................317
Obje/vos de aprendizaje............................................................................................................317
25.1 Plani.cacion de E/S............................................................................................................318
25.2 Alterna/vas del Plani.cador de E/S....................................................................................318
25.3 Plani.cador de E/S y disposi/vos SSD................................................................................319
25.4 Parametros y cambio del Plani.cador de E/S en /empo de ejecución...............................319
25.5 CFQ (Completely fair Queue Scheduler).............................................................................320
25.6 Parametros ajustables de CFQ............................................................................................321
25.7 Plani.cador Deadline.........................................................................................................321
25.8 Parametros ajustables de Deadline....................................................................................322
Comprobacion de conocimientos 25.1.......................................................................................322
Comprobacion de conocimientos 25.2.......................................................................................322
25.9 Laboratorio 25.1.................................................................................................................323
Obje/vos de aprendizaje (revision)............................................................................................326
Capítulo 26. Memoria: monitoreo y ajustes...................................................................................327
Obje/vos de aprendizaje............................................................................................................327
26.1 Consideraciones al ajustar la memoria...............................................................................328
26.2 Herramientas de monitoreo de memoria...........................................................................328
26.3 /proc/sys/vm......................................................................................................................329

LFS201: Fundamentos de Administración de Sistemas Linux 13


26.4 vmstat.................................................................................................................................331
26.5 /proc/meminfo...................................................................................................................335
26.6 OOM Killer..........................................................................................................................337
Comprobacion de conocimientos 26.1.......................................................................................339
Comprobacion de conocimientos 26.2.......................................................................................339
Comprobacion de conocimientos 26.3.......................................................................................339
Comprobacion de conocimientos 26.4.......................................................................................339
26.7 Laboratorio 26.1.................................................................................................................340
Obje/vos de aprendizaje (revision)............................................................................................340
Capítulo 27. Sistemas de ges/ón de paquetes...............................................................................341
Obje/vos de aprendizaje............................................................................................................341
27.1 Conceptos de empaquetamiento de soNware...................................................................342
27.2 Razones por las cuales usar paquetes................................................................................342
27.3 Tipos de paquetes..............................................................................................................343
27.4 Sistemas disponibles para ges/ón de paquetes.................................................................343
27.5 Niveles de empaquetamiento y variedad de herramientas................................................344
27.6 Fuentes de paquetes..........................................................................................................344
27.7 Creacion de paquetes de soNware.....................................................................................345
Comprobacion de conocimientos 27.1.......................................................................................345
Obje/vos de aprendizaje (revision)............................................................................................345
Capítulo 28. RPM............................................................................................................................346
Obje/vos de aprendizaje............................................................................................................346
28.1 RPM....................................................................................................................................347
28.2 Ventajas en el uso de RPM.................................................................................................347
28.3 Nombres de archivos de paquetes.....................................................................................348
28.4 Directorio de la base de datos............................................................................................348
28.5 Programas auxiliares y ajustes modi.cables.......................................................................349
28.6 Consultas............................................................................................................................349
28.7 Veri.cacion de paquetes....................................................................................................350
28.8 Instalacion de paquetes......................................................................................................352
28.10 Actualizacion de paquetes................................................................................................353
28.11 Refrescar paquetes...........................................................................................................353
28.12 Actualizacion de kernel.....................................................................................................354

LFS201: Fundamentos de Administración de Sistemas Linux 14


28.13 uso de rpm2cpio...............................................................................................................354
Comprobacion de conocimiento 28.1........................................................................................355
Comprobacion de conocimiento 28.2........................................................................................355
28.14 Laboratorio 28.1...............................................................................................................355
28.14 Laboratorio 28.2...............................................................................................................357
Obje/vos de aprendizaje (revision)............................................................................................358
Capítulo 29. DPKG..........................................................................................................................359
Obje/vos de aprendizaje............................................................................................................359
29.1 Conceptos básicos de DPKG...............................................................................................360
29.2 Nombres de archivo de paquete........................................................................................360
29.3 Paquetes de código fuente.................................................................................................360
29.4 Consultas DPKG..................................................................................................................361
29.5 Instalacion/Actualizacion/Desinstalacion...........................................................................362
Comprobacion de conocimientos 29.1.......................................................................................363
19.6 Laboratorio 29.1.................................................................................................................363
Obje/vos de aprendizaje (revision)............................................................................................364
Capítulo 30. yum............................................................................................................................365
Obje/vos de aprendizaje............................................................................................................365
30.1 Instaladores de paquetes...................................................................................................366
30.2 Que es yum?.......................................................................................................................366
30.3 Ubicación de los repositorios yum......................................................................................367
30.4 Archivos de repositorio.......................................................................................................367
30.5 Consultas............................................................................................................................368
30.6 Veri.cacion de paquetes....................................................................................................369
30.7 Instalacion/Actualizacion/Desinstalacion...........................................................................369
30.8 Comandos yum adicionales................................................................................................371
Comprobacion de conocimientos 30.1.......................................................................................372
Comprobacion de conocimientos 30.2.......................................................................................372
Comprobacion de conocimientos 30.3.......................................................................................372
Comprobacion de conocimientos 30.4.......................................................................................372
30.9 Laboratorio 30.1.................................................................................................................373
30.9 Laboratorio 30.2.................................................................................................................374
30.9 Laboratorio 30.3.................................................................................................................375

LFS201: Fundamentos de Administración de Sistemas Linux 15


30.9 Laboratorio 30.4.................................................................................................................376
Obje/vos de aprendizaje............................................................................................................377
Capítulo 31. ZYPPER.......................................................................................................................378
Obje/vos de aprendizaje............................................................................................................378
31.1 Que es zypper?...................................................................................................................379
31.2 Consultas con zypper..........................................................................................................379
31.3 Instalacion/Actualizacion/Desinstalacion...........................................................................380
31.4 Comandos zypper adicionales............................................................................................380
Comprobacion de conocimientos 31.1.......................................................................................381
Comprobacion de conocimientos 31.2.......................................................................................381
Comprobacion de conocimientos 31.3.......................................................................................381
Comprobacion de conocimientos 31.4.......................................................................................381
31.5 Laboratorio 31.1.................................................................................................................382
31.5 Laboratorio 31.2.................................................................................................................383
Obje/vos de aprendizaje (revision)............................................................................................383
Capítulo 32. APT.............................................................................................................................384
Obje/vos de aprendizaje............................................................................................................384
32.1 Que es APT?.......................................................................................................................385
32.2 apt-get................................................................................................................................385
32.3 Consultas con apt-cache.....................................................................................................385
32.4 Instalacion/Actualizacion/Desinstalacion...........................................................................386
Comprobacion de conocimientos 32.1.......................................................................................387
Comprobacion de conocimientos 32.2.......................................................................................387
Comprobacion de conocimientos 32.3.......................................................................................387
Comprobacion de conocimientos 32.4.......................................................................................388
32.5 Laboratorio 32.1.................................................................................................................388
32.5 laboratorio 32.2..................................................................................................................389
32.5 laboratorio 32.3..................................................................................................................390
Obje/vos de aprendizaje (revision)............................................................................................391
Capítulo 33. Ges/ón de cuentas de usuario...................................................................................392
Obje/vos de aprendizaje............................................................................................................392
33.1 Cuentas de usuario.............................................................................................................393
33.2 Atributos de una cuenta de usuario...................................................................................393

LFS201: Fundamentos de Administración de Sistemas Linux 16


33.3 Creación de cuentas de usuario con useradd.....................................................................394
33.4 Modi.cacion y eliminación de cuentas de usuario.............................................................395
33.5 Cuentas bloqueadas...........................................................................................................396
33.6 ID de usuario y /etc/passwd...............................................................................................397
33.7 /etc/shadow.......................................................................................................................398
33.8 Por que usar /etc/shadow?................................................................................................399
33.9 Ges/on de contraseñas......................................................................................................399
33.10 chage: envejecimiento de la contraseña..........................................................................400
33.11 Shell restringida................................................................................................................401
33.12 Cuentas restringidas.........................................................................................................401
33.13 La cuenta root..................................................................................................................402
33.14 SSH...................................................................................................................................403
33.15 Archivos de con.guración de SSH.....................................................................................403
Comprobacion de conocimientos 33.1.......................................................................................405
33.16 Laboratorio 33.1...............................................................................................................406
Obje/vos de aprendizaje (revision)...........................................................................................408
Capítulo 34. Ges/ón de grupos......................................................................................................409
Obje/vos de aprendizaje............................................................................................................409
34.1 Grupos...............................................................................................................................410
34.2 Ges/on de grupos..............................................................................................................410
34.3 Grupos privados de Usuario...............................................................................................411
34.4 pertenecia a grupos............................................................................................................411
Comprobacion de conocimientos 34.1.......................................................................................412
34.5 Laboratorio 34.1.................................................................................................................412
Obje/vos de aprendizaje (revision)............................................................................................414
Capítulo 35. Permisos de archivos y propietarios...........................................................................415
Obje/vos de aprendizaje............................................................................................................415
35.1 Propietario, grupo y mundo...............................................................................................416
35.2 Derechos de acceso a archivos...........................................................................................416
35.3 Permisos de archivo, seguridad y auten/cación.................................................................417
35.4 Modi.cacion de permisos: chmod.....................................................................................417
35.5 chmod: sistaxis numérica de permisos...............................................................................418
35.6 Modi.cacion de ususario y grupo propietario:chown y chgrp............................................418

LFS201: Fundamentos de Administración de Sistemas Linux 17


35.7 umask.................................................................................................................................419
35.8 ACLs de sistema de archivos...............................................................................................420
35.9 Listado y con.guración de ACLs..........................................................................................420
Comprobacion de conocimientos 35.1.......................................................................................421
Comprobacion de conocimientos 35.1.......................................................................................421
35.10 Laboratorio 35.1...............................................................................................................421
35.10 Laboratorio 35.2...............................................................................................................422
Obje/vos de aprendizaje (revision)............................................................................................423
Capítulo 36. Pluggable Authen/ca/on Modules (PAM)..................................................................424
Obje/vos de aprendizaje............................................................................................................424
36.1 PAM: Una aproximación uni.cada para la auten/cación....................................................425
36.2 Proceso de auten/cación...................................................................................................425
36.3 Archivos de con.guración de PAM.....................................................................................426
36.4 Reglas de PAM....................................................................................................................426
36.5 Auten/cacion LDAP............................................................................................................427
Comprobacion de conocimientos 36.1.......................................................................................428
Comprobacion de conocimientos 36.2.......................................................................................428
36.6 Laboratorio 36.1.................................................................................................................428
Obje/vos de aprendizaje (revision)............................................................................................430
Capítulo 37. Métodos de respaldos y recuperación de la información...........................................431
Obje/vos de aprendizaje............................................................................................................431
37.1 Por que realizar respaldos?................................................................................................432
37.2 Que necesita tener un respaldo?........................................................................................433
37.3 Unidades de cinta...............................................................................................................433
37.4 Métodos de respaldo.........................................................................................................434
37.5 Estrategias de respaldo.......................................................................................................434
37.6 Herramientas de respaldo..................................................................................................435
37.7 cpio.....................................................................................................................................436
37.8 Uso de tar para respaldos...................................................................................................437
37.9 Uso de tar para restaurar archivos......................................................................................438
37.10 Respaldos incrementales con tar......................................................................................438
37.11 Compresión: gzip, bzip2, xz y respaldos...........................................................................439
37.12 dd.....................................................................................................................................440

LFS201: Fundamentos de Administración de Sistemas Linux 18


37.13 Ejemplos de dd.................................................................................................................440
37.14 rsync.................................................................................................................................441
37.15 dump y restore.................................................................................................................442
37.16 Opciones de dump...........................................................................................................442
37.17 Respaldo de Nivel 0 con dump.........................................................................................443
37.18 restore..............................................................................................................................444
37.19 mt.....................................................................................................................................444
37.20 SoNware de respaldo........................................................................................................445
Comprobacion de conocimientos 36.1 37.1...............................................................................446
Comprobacion de conocimientos 36.1 37.2...............................................................................446
Comprobacion de conocimientos 36.1 37.3...............................................................................447
37.21 Laboratorio 37.1...............................................................................................................447
37.21 Laboratorio 37.2...............................................................................................................449
37.21 Laboratorio 37.3...............................................................................................................451
Obje/vos de aprendizaje (revision)............................................................................................452
Capítulo 38. Direcciones de red......................................................................................................453
Obje/vos de aprendizaje............................................................................................................453
38.1 Direcciones IP.....................................................................................................................454
38.2 Tipos de direcciones IPv4...................................................................................................454
38.3 Direcciones especiales........................................................................................................455
38.4 Tipos de direcciones IPv6...................................................................................................456
38.5 Clases de direcciones IPv4..................................................................................................456
38.6 Máscara de red...................................................................................................................457
38.7 Hostname...........................................................................................................................458
38.8 Obtener y con.gurar el hostname......................................................................................458
Comprobacion de conocimientos 38.1.......................................................................................460
Comprobacion de conocimientos 38.2.......................................................................................460
Comprobacion de conocimientos 38.3.......................................................................................460
Obje/vos de aprendizaje (revision)............................................................................................460
Capítulo 39. Con.guración de disposi/vos de red..........................................................................461
Obje/vos de aprendizaje............................................................................................................461
39.1 Disposi/vos de red.............................................................................................................462
39.2 Problemas con nombres de disposi/vos de red.................................................................462

LFS201: Fundamentos de Administración de Sistemas Linux 19


39.3 Nombres predecibles de las interfaces de red....................................................................463
39.4 Ejemplos del esquema nuevo de nombres.........................................................................463
39.5 Archivos de con.guración de una NIC................................................................................464
39.6 ifcon.g................................................................................................................................465
39.7 La herramienta ip...............................................................................................................466
39.8 Ejemplos del uso de ip........................................................................................................467
39.9 enrutamiento.....................................................................................................................467
39.10 Ruta por defecto...............................................................................................................468
39.11 Rutas ésta/cas..................................................................................................................469
39.12 Resolución de nombres....................................................................................................470
39.13 /etc/hosts.........................................................................................................................470
39.14 DNS...................................................................................................................................471
39.15 Herramientas de diagnos/co de red.................................................................................472
Comprobacion de conocimientos 39.1.......................................................................................473
Comprobacion de conocimientos 39.2.......................................................................................473
Comprobacion de conocimientos 39.3.......................................................................................473
Comprobacion de conocimientos 39.4.......................................................................................474
Comprobacion de conocimientos 39.5.......................................................................................474
39.16 Laboratorio 39.1...............................................................................................................474
39.16 Laboratorio 39.2...............................................................................................................476
39.16 Laboratorio 39.3...............................................................................................................477
Obje/vos de aprendizaje (revision)............................................................................................477
Capítulo 40. Cortafuegos................................................................................................................478
Obje/vos de aprendizaje............................................................................................................478
40.1 Que es un cortafuegos?......................................................................................................479
40.2 Interfaces y herramientas del cortafuegos.........................................................................479
40.3 .rewalld..............................................................................................................................480
40.4 Estado del servicio .rewalld...............................................................................................481
40.5 Zonas..................................................................................................................................482
40.6 Ges/ón de las zonas...........................................................................................................483
40.7 Ges/ón de fuentes.............................................................................................................484
40.8 Ges/ón de los servicios y puertos......................................................................................484
40.9 Laboratorio 40.1.................................................................................................................485

LFS201: Fundamentos de Administración de Sistemas Linux 20


40.9 Laboratorio 40.2.................................................................................................................487
40.9 Laboratorio 40.3.................................................................................................................488
40.9 Laboratorio 40.4.................................................................................................................489
Obje/vos de aprendizaje (revision)............................................................................................489
Capítulo 41. Resolución básica de problemas................................................................................490
Obje/vos de aprendizaje............................................................................................................490
41.1 Resumen de la resolución básica de problemas.................................................................491
41.2 Técnicas básicas..................................................................................................................491
41.3 Intuicion y experiencia.......................................................................................................491
41.4 cosas para veri.car: la red..................................................................................................492
41.5 Cosas para veri.car: integridad de archivos.......................................................................493
41.6 Fallas en el proceso de arranque........................................................................................493
41.7 Corrupción y recuperación de sistemas de archivos...........................................................494
41.8 Medios de rescate/recuperación........................................................................................495
41.9 Herramientas comunes en medios de rescate/recuperación.............................................495
41.10 Uso de medios de rescate/recuperación..........................................................................495
Comprobacion de conocimientos 41.1.......................................................................................496
Comprobacion de conocimientos 41.2.......................................................................................496
Obje/vos de aprendizaje (revision)............................................................................................497
Capítulo 42. Rescate del sistema....................................................................................................498
Obje/vos de aprendizaje............................................................................................................498
42.1 Medios de arranque de emergencia...................................................................................499
42.2 Uso de medios de rescate...................................................................................................499
42.3 Disposi/o USB de rescate...................................................................................................500
42.4 Modo de emergencia.........................................................................................................500
42.5 Modo monousuario............................................................................................................501
Comprobacion de conocimientos 42.1.......................................................................................501
Comprobacion de conocimientos 4exit
exir2.2........................................................................................................................................501
Comprobacion de conocimientos 42.3.......................................................................................502
Comprobacion de conocimientos 42.4.......................................................................................502
42.6 Laboratorio 42.1.................................................................................................................503
42.6 Laboratorio 42.2.................................................................................................................504

LFS201: Fundamentos de Administración de Sistemas Linux 21


42.6 Laboratorio 42.3.................................................................................................................505
42.6 Laboratorio 42.4.................................................................................................................505
42.6 Laboratorio 42.5.................................................................................................................506
Obje/vos de aprendizaje (revision)............................................................................................507

LFS201: Fundamentos de Administración de Sistemas Linux 22


Capítulo 1. Prólogo
Este curso cubre administración de sistemas Linux modernos. Trata todas las tareas más
importantes, incluyendo: controlar la inicialización del servicio y sistemas; manejar
particiones de disco y sistemas de archivos; establecer una buena seguridad y prácticas
de respaldo; monitoreo, solución de problemas y rescate del sistema ante una falla;
instalación de software y actualizaciones. Las lecciones aprendidas son aplicadas a cada
una de las tres familias de distribuciones de Linux (Red Hat, SUSE y Debian) con un
foco principal en instalaciones Empresariales.

La meta es proveer a los administradores de sistemas de todas las herramientas y


conceptos necesarios para instalar y manejar de forma eficiente una infraestructura de
producción Linux. Los laboratorios prácticos de ejercicios presentarán una gran
oportunidad para probar y aplicar esas lecciones.

LFS201: Fundamentos de Administración de Sistemas Linux 23


1.1 Introducción

Este curso está diseñado principalmente para administradores de sistema.

Estamos asumiendo que la mayoría de ustedes tienen tareas de configurar, ejecutar y


resolver problemas en múltiples máquinas en lo que es llamado un
ambiente Empresarial. Si bien es cierto que probablemente tenga experiencia significante
con otros sistemas operativos, deseamos que usted aprenda cómo hacer las cosas de
forma correcta y nativa en Linux, mientras que se basa en el conocimiento previo que
posee.

También es probable que ya esté utilizando Linux, pero que aún no haya estudiado de
forma seria tópicos más complejos que mantener su sistema personal funcionando
apropiadamente y de forma segura.
Este curso no está diseñado principalmente para:

 Usuarios nuevos sin mucha experiencia previa con cualquier sistema operativo.
A los usuarios de Linux relativamente nuevos se les recomienda tomar este
curso solamente después de haber tomado un curso introductorio como
el LFS101x.2 de Linux Foundation.
 Desarrolladores (a nivel del kernel o de aplicaciones).

La mayoría de los desarrolladores encontrarán interesante este material y entre


más sepa alguien de teoría de sistemas operativos, funcionamiento interno del
kernel, aplicaciones, etc., más también querrá salirse de este curso. También hay
muchos usuarios avanzados quienes realizan ambas cosas, administración de
sistemas y desarrollo.

 Administradores experimentados que se concentran en la optimización del


rendimiento.
Vamos a discutir algunos problemas de ajuste de rendimiento debido a que la
administración y el rendimiento están claramente asociados. Sin embargo, no
vamos a entrar en detalles, ya que este tema se trata en un curso más dedicado y
avanzado como es el LFS426 de Linux Foundation.

1.2 Relación con LFS101x2

Estamos asumiendo que usted ha tomado el curso gratuito Introducción a Linux (2da
Ed.) de Linux Foundation enedX. Este MOOC (Massive Open Online Course) puede ser
encontrado haciendo click aquí, o buscando “Linux” enedx.org. O por otro lado, que usted
tiene conocimiento equivalente o incluso mejor que lo que podría haber obtenido al tomar
ese curso.

LFS201: Fundamentos de Administración de Sistemas Linux 24


LFS101x.2 es gratuito e incluso si usted siente que no tiene que tomar ese curso,
recomendamos que se inscriba en él; al menos puede echar un vistazo rápido del
material. Algunos de los temas contenidos en LFS101x.2 están cubiertos en este curso,
generalmente en un nivel más detallado acorde con nuestra audiencia. El tema de gestión
de paquetes es un ejemplo claro de ello.

En lugar de repetirnos, instamos a que usted se refiera el curso introductorio para temas
básicos no cubiertos aquí.

Existen otros temas que los administradores de sistemas deben saber, que no cubriremos
en este curso. En particular:
 Editores de texto (vi, emacs, nano, gedit, etc.)
 Encontrar documentación de Linux
 Manipulación de texto (sed, grep, awk, cut, paste, tail, head, etc.)
 Utilidades de archivo (find, locate, file, etc.)
 Impresión (configurar impresoras, manejo de trabajos de impresión)
 Interfaces gráficas y su administración
 Programas en el shell bash
 Instalación de sistemas

Antes de tomar este curso, le recomendamos que por lo menos eche un vistazo
a LFS101x.2. Si no se siente cómodo o totalmente familiar con algunas herramientas
básicas y los procedimientos que usaremos en este curso, usted probablemente los
encontrará ahí, ya que este curso pretende tenerlo como complemento.

1.3 Uso como preparación para el examen LFCS

La Linux Foundation ofrece un Programa de Certificación de dos niveles:


 LFCS (Linux Foundation Certified Sysadmin)
 LFCE (Linux Foundation Certified Engineer)

Todos los detalles acerca de este programa se pueden encontrar


en http://training.linuxfoundation.org/certification. Esta información incluye una descripción
detallada de los Dominios y Competencias cubiertas por cada examen.
Los asistentes a este curso (y al curso de introductorio de prerrequisito) habrán cubierto
todas las áreas descritas como necesarias para la certificación LFCS. Además de este
curso, la Linux Foundation ofrece otros recursos para ayudar en la preparación de
exámenes.

LFS201: Fundamentos de Administración de Sistemas Linux 25


LFS201: Fundamentos de Administración de Sistemas Linux 26
1.4 Formato del curso
Con el fin de que sea más fácil distinguir los distintos tipos de contenido en el curso,
utilizamos la codificación de colores y formatos que se muestran a continuación:
 Negrita: nombres de programas o servicios (o utilizado para enfatizar)
 Azul claro: señala enlaces
 Azul oscuro: texto en la línea de comandos
 Verde: salida del sistema en la línea de comandos
 Café: nombres de archivos y contenido de archivos

Para ver los gráficos incluidos en este curso en un formato más grande, simplemente
haga clic en el gráfico y automáticamente se mostrará en una ventana emergente.

1.5 La Documentación

De vez en cuando, vamos a discutir cómo elaborar un comando utilizando un programa de


utilidad de Linux, pero sólo mostraremos uno o unos pocos ejemplos de selección de
opciones, argumentos, etc. Además no consideraremos a los modos menos comunes de
uso; muchos programas son increíblemente versátiles y tienen muchas características
raramente utilizadas.

Mientras que a menudo le diremos explícitamente “lea la página Man para obtener más
detalles”, usted debe asumir que lo estamos diciendo implícitamente todo el tiempo.
Usted debe desarrollar el hábito de la lectura de la documentación de fácil acceso en su
distribución de Linux sin preguntar, para la mayoría de las utilidades.

Además de las páginas man, la mayoría de los programas tienen dentro de sí una ayuda
como también información acerca de su uso. Generalmente esto se accede mediante el
uso de la opción—help, como en df—help.

Si tratamos de incluir toda esa información en el material del curso, sería una duplicación
inútil y de hecho el contenido se diluiría de una mala manera.

LFS201: Fundamentos de Administración de Sistemas Linux 27


1.6 Plataforma de trabajo

Este curso está diseñado para trabajar en plataformas basadas en x86, ya sea en
hardware nativo o como una máquina virtual (VM) bajo un hypervisor,
como KVM, VMWare u Oracle Virtual Box.

Casi todo en este curso es completamente relevante para otras arquitecturas,


pero x86 real o virtual cubre la mayoría de las implementaciones.
No consideraremos 32-bit y asumiremos 64-bit a lo largo del curso. Sin embargo, si usted
está ejecutando un x86 de 32-bit por alguna razón, casi todo lo que estamos haciendo
seguirá siendo válido, aunque no lo hemos probado.

Tampoco estamos apuntando a plataformas de Linux embebido, donde a pesar de que


las implementaciones se basan en el mismo kernel Linux y utilizan muchos de los
mismos ingredientes del espacio de usuario, uno no suele hablar de la administración del
sistema para los dispositivos que se utilizan como soluciones especializadas (appliances).
Existen importantes ingredientes básicos que son muy diferentes, como el uso de
diferentes programas del gestor de arranque y sistemas de archivos. Además, los
recursos tales como memoria, capacidad de almacenamiento y del procesador pueden
diferir grandemente.
Las mismas consideraciones se aplican a Android (una forma particular de Linux
embebido), en donde si bien es cierto que el kernel es Linux, el sistema de archivos y el
espacio de aplicaciones son muy diferentes a lo que se encuentra en un
sistema Linux estándar.

1.7 Línea de comandos vs. Interfaz Grafica

Muchas de las tareas administrativas pueden ser realizadas desde la línea de comandos
o desde una aplicación gráfica. Casi siempre hay más flexibilidad y capacidades
adicionales en el enfoque de la línea de comandos, ya que la capa de abstracción se ha
eliminado. El inconveniente de la línea de comandos, sin embargo, es que el
administrador puede tener que recordar más o buscar información cuando tiene que
completar una tarea.
Hay una gran variedad de entornos de escritorio gráficos utilizados en Linux, los dos más
comunes son GNOME y KDE. Cada uno de ellos viene en múltiples versiones, o
generaciones. There are a variety of graphical desktop environments used in Linux, the
two most common being GNOME and KDE.
En este curso no queremos involucrarnos en interfaces gráficas, debido a que varían
mucho entre las versiones y familias de distribuciones de Linux. Además, muchos
servidores no tienen una interfaz gráfica instalada.

Si ya ha tomado el curso LFS101x.2, entonces estará familiarizado con los temas.


El beneficio es que habrá muy poca diferencia entre las distribuciones para lo que
estamos haciendo, y aparte de las tareas sencillas que implican la gestión de paquetes,
no tendremos que explicar las cosas por separado para cada distribución muy a menudo.
Para este curso, usted puede trabajar desde la línea de comandos en el equipo local,
usando una consola o un emulador de terminal como gnome-terminal corriendo en un
escritorio gráfico. O puede trabajar remotamente mediante una sesión ssh o vpn. Casi
todo lo que estamos haciendo se aplicará igualmente bien en el caso de sesión remota.

LFS201: Fundamentos de Administración de Sistemas Linux 28


Las excepciones surgirán sólo cuando se necesita acceso físico a la máquina, tales como
cuando se intenta iniciar en un entorno de rescate.

LFS201: Fundamentos de Administración de Sistemas Linux 29


1.8 Distribuciones de Linux a utilizar
Hay una lista casi infinita de distribuciones de Linux; simplemente hojee la lista
en http://lwn.net/Distributions.

Sin embargo, nos estamos concentrando en este curso en las


distribuciones Empresariales de Linux. La gran mayoría de estos sistemas utilizan:

1. Red Hat Enterprise Linux: Generalmente lo abreviaremos como RHEL o con la


versión como en RHEL 6 or RHEL 7, lanzada en 2014.

Bajo el paraguas de RHEL incluiremos distribuciones derivadas como


CentOS y Scientific OS; para los efectos de este curso deben ser idénticas, así
como su libre disposición sin cargo. Hay algunas diferencias en la actualización de
paquetes para los sistemas oficiales de RHEL, pero no vamos a investigar lo
suficiente como para verlos aquí. Para nuestros propósitos Oracle Linux es
realmente una copia casi idéntica a RHEL y no merece ninguna discusión distinta
aquí.

Fedora está en la familia Red Hat y en realidad puede ser visto como la versión
hacia donde RHEL se dirige. Las versiones actuales son bastante similares
a RHEL 7. Sin embargo, es raro que Fedora se utilice en implementaciones
Empresariales debido a que es de vanguardia y cambia características
importantes (la versión del kernel, por ejemplo) muy a menudo y por comodidad,
donde más bien la estabilidad es clave.

2. SUSE es una distribución Empresarial completa con una cuota de mercado


significativa. Se relaciona estrechamente con openSUSE, el cual es
a SUSE como Fedora a RHEL. Debido a que no hay ningún clon de SUSE como
lo hay con CentOS y RHEL, nos basaremos en openSUSE como un sistema de
trabajo; las diferencias deben ser pequeñas y en el peor caso los estudiantes se
mantendrán cercanos a desarrollos futuros.

3. Debian (y Ubuntu que es un derivado de Debian) también se utiliza en entornos


empresariales. En su mayor parte cuando hablamos de
sistemas Debian o Ubuntu, vamos a utilizar la versión de Ubuntu LTS 14.04.
Otras distribuciones derivadas de Debian como Linux Mint no serán muy
diferentes.

Todo en este curso se trabajará en las tres principales familias de distribución


mencionadas anteriormente, y cuando sea necesario explicaremos las diferencias que
surjan; estas a menudo surgen sólo en cómo se empaqueta el software y no en la forma
en que se utiliza.
En ningún caso criticamos a alguien que utilice distribuciones menos difundidas aunque
también ampliamente respetadas, como Arch Linux y Gentoo, las cuales se usan en
implementaciones Empresariales. Debido a que ambas son distribuciones de
liberación continua de software (no tienen versiones específicas de lanzamiento, sino

LFS201: Fundamentos de Administración de Sistemas Linux 30


que se actualizan constantemente) son las más utilizadas por administradores muy
expertos en entornos Empresariales.

1.9 Instalación: que usar para este curso

Le invitamos a utilizar su propia instalación local favorita de Linux, usando cualquier


distribución con la que se sienta cómodo. De vez en cuando es posible que usted necesite
instalar un programa o paquete que usamos en este curso y tendrá que ir a buscarlo e
instalarlo, utilizando los métodos habituales de su distribución Linux.

Debido a que no estamos usando un entorno gráfico, usted debe ser capaz de hacer el
trabajo del curso en una máquina en la que inicie sesión de forma remota.

Puede utilizar una máquina física, o una máquina virtual en ejecución bajo
un hipervisor como VMware, Oracle Virtual Box o KVM. En parte porque no nos
estamos concentrando en optimización de rendimiento, una máquina virtual debe
funcionar tan bien como una máquina física; por una parte el rendimiento menor no será
un problema, y por otra, usted puede hacer mucho menos daño.

La Linux Foundation preparó un documento sobre los temas involucrados al realizar una
instalación para LFS101x, el cual es completamente relevante para este curso. Puede
descargarlo haciendo click aquí (si es que se ha registrado para el MOOC) o haciendo clic
en el botón Documento a continuación. Entre otras cosas le dará información sobre las
distintas opciones para hipervisores.

Preparación del sistema en documentación final

1.10 Calendario del curso

Este curso es completamente autodidacta; no hay ningún horario fijo para ir a través del
material. Puede revisar el curso a su propio ritmo y siempre será devuelto a exactamente
donde lo dejó cuando vuelva a iniciar una nueva sesión. Sin embargo, de todas formas
sugerimos evitar pausas largas entre períodos de trabajo, para que el aprendizaje sea
más rápido y la retención del contenido sea mejor.

Usted tiene acceso ilimitado a este curso por 12 meses desde la fecha en la cual se
registró, incluso después de haber completado el curso.

Los capítulos en el curso han sido diseñados para construirse uno sobre el otro.
Probablemente lo mejor para trabajar a través de ellos es de forma secuencial; si se salta
o pasa por algunos capítulos rápidamente, puede encontrar que hay temas en discusión a
los que no ha estado expuesto todavía. Pero todo esto es a su propio ritmo y siempre se
puede volver atrás, por lo que puede hacer su propio camino a través del material.

LFS201: Fundamentos de Administración de Sistemas Linux 31


LFS201: Fundamentos de Administración de Sistemas Linux 32
1.11 Laboratorios y Ejercicios
En todos los cursos de Linux Foundation (en cualquier formato) ponemos un fuerte
énfasis en el aprendizaje mediante la práctica. En las clases presenciales, dirigidas por un
instructor, casi siempre buscamos un equilibrio 50/50 entre la conferencia y debate.
También en trabajar en ejercicios de laboratorio o en tareas, las que llevan a cabo el
trabajo descrito en la clase, o probar con variaciones más ambiciosas. Los instructores
ayudan durante estas sesiones de laboratorio a los estudiantes a descubrir cómo hacer
las cosas, depurar su código y scripts, etc. Al ser este un curso autodidacta, sin un
instructor presencial, estará en sus manos el controlar su presupuesto de tiempo y
asegúrese de tomar suficiente tiempo para hacer los laboratorios.

Para cada ejercicio presentamos la descripción de un archivo que puede descargar. En


muchos casos, también hay un archivo asociado a la solución (en unos pocos casos
también hay un archivo que contiene scripts necesarios para completar el laboratorio).
Tenga en cuenta que en muchos casos las soluciones no son únicas, así que considere
estas respuestas como un método representativo para resolver el problema; ¡usted puede
tener una mejor!

Para mayor comodidad, también puede descargar en un archivo todos los ejercicios de
laboratorio y soluciones. Para ello haga click en el botón Documento que se muestra a
continuación.

Usted también encontrará una serie de preguntas de verificación de conocimientos al final


de cada capítulo. Estas preguntas, al igual que los laboratorios, fueron diseñados con un
objetivo principal en mente: ayudarle a comprender mejor el contenido del curso y reforzar
lo que ha aprendido. Es importante destacar que los laboratorios y preguntas de
verificación de conocimientos no se califican. Nos gustaría hacer hincapié en que no
se le exigirá tomar un examen final para completar este curso.

LFS201: Fundamentos de Administración de Sistemas Linux 33


1.12 Cambio, repetición y guerras santas

Tres piezas importantes de contexto:

1 Las cosas cambian en Linux. No importa lo duro que hemos trabajado para estar al
día, Linux está en constante evolución, tanto a nivel técnico (incluyendo
características del kernel) y al nivel de distribución y la interfaz. Por favor, tenga en
mente que hemos tratado de estar lo más actualizados posible al momento en que
este curso fue publicado, pero habrá cambios y novedades que no hemos discutido,
es inevitable.

2 Hemos repetido unas pocas cosas en el material del curso. Es casi imposible en un
curso de esta amplitud no revisar temas que han sido cubiertos previamente. Los
comentarios cortos son útiles, así que no tendrá que ir recorriendo a través de las
secciones anteriores para refrescar su memoria. Sabemos que hemos hecho esto, y
por lo menos en la mayoría de los casos es por diseño, no por accidente.

3 Hemos intentado evitar guerras santas. Hay muchas áreas donde hay fuertes
desacuerdos de preferencias en la comunidad Linux (y de forma más amplia en el
código abierto). Los ejemplos incluyen el mejor editor: emacs vs vi; el mejor escritorio
gráfico: GNOME vs KDE, etc. Generalmente hemos elegido (cuando sea necesario)
una alternativa particular tan sólo para mantener las cosas claras; por ejemplo
podemos hablar más acerca de GNOME que KDE simplemente porque tiene una
base de usuarios más grande, no porque estamos tomando una posición en cuanto a
que es superior.

1.13 Acerca de Linux Foundation

La Linux Foundation es el consorcio sin fines de lucro dedicado a fomentar el


crecimiento de Linux. Patrocina el trabajo del creador de Linux, Linus Torvalds, y es
apoyado por las principales empresas de tecnología y desarrolladores alrededor del
mundo.
La Linux Foundation promueve, protege y hace que Linux avance a través de los
recursos proveídos por sus miembros y la comunidad de desarrollo de código abierto para
asegurar que Linux siga siendo libre y avanzado técnicamente.
La Linux Founda/on:

LFS201: Fundamentos de Administración de Sistemas Linux 34


 Sirve como portavoz neutral de Linux.

 Patrocina al creador de Linux - Linus


Torvalds - y a otros desarrolladores clave
del kernel para que puedan trabajar a
tiempo completo en la mejora de Linux.
Es de vital importancia que ellos sigan
siendo independientes.

 Genera una investigación original y


contenido que promueve la comprensión
de la plataforma Linux.
 Llega a millones de personas a través de
sus sitios web, incluyendo
http://www.linux.com.

 Fomenta la innovación mediante la organización de grandes eventos de


colaboración (incluyendo LinuxCon) e iniciativas de la industria.

 Gestiona la marca Linux, ofrece protección legal de propiedad intelectual a los


desarrolladores y un fondo de defensa legal. Coordina la colaboración jurídica y
educativa entre la industria y la comunidad, incluyendo trabajo importante para
defender Linux de a amenazas legales.

 Ofrece servicios de estandarización y soporte para desarrolladores de


aplicaciones, incluyendo el Linux Standard Base.

 Desarrolla y ofrece programas de capacitación.

1.14 Eventos de Linux Foundation

La Linux Foundation alberga un número creciente de eventos cada año, incluyendo:


 LinuxCon América del Norte, Europa y Japón
 Linux Kernel Summit
 CloudOpen América del Norte y Japón
 Collaboration Summit
 Embedded Linux Conference América del Norte y Europa
 Enterprise End User Summit
 Android Builders Summit
 Tizen Developer Conference
 Automotive Linux Summit
 ApacheCon
 CloudStack
 Foro KVM
 Linux Storage Filesystem & MM Summit

LFS201: Fundamentos de Administración de Sistemas Linux 35


La Linux Foundation también presta servicios a la comunidad de desarrollo de Linux,
incluyendo un fondo de viajes para desarrolladores de código abierto, apoyo legal y otras
formas de asistencia administrativa. A través de sus grupos de trabajo, los miembros y
desarrolladores pueden colaborar en áreas técnicas clave.

1.15 Certificaciones

La Linux Foundation ofrece varios de tipos de capacitación:


 Sala de clases
 En línea
 En su sitio de trabajo
 En eventos
 Vea los siguientes enlaces para obtener más información sobre cursos específicos
ofrecidos por la Linux Foundation:
 Entrenamiento en Programación y Desarrollo en
Linux: http://training.linuxfoundation.org/linux-courses/development-training
 Cursos de IT Empresarial y Administración de Sistemas
Linux: http://training.linuxfoundation.org/linux-courses/system-administration-
training
 Cursos de Cumplimiento de Normas de Código
Abierto: http://training.linuxfoundation.org/linux-courses/open-source-compliance-
courses

Para información adicional, incluyendo requisitos técnicos y otros aspectos logísticos,


consulte http://training.linuxfoundation.org.

LFS201: Fundamentos de Administración de Sistemas Linux 36


Laboratorio 1.1
Congurar el sistema con sudo

Es muy peligroso ejecutar una terminal de root a menos de que sea absolutamente necesario: un
solo error de /peo o de otro /po puede causar daños graves (incluso no recuperables).

Por lo tanto, el procedimiento recomendado es con.gurar el sistema de tal forma que comandos
únicos puedan ser ejecutados con privilegios de superusuario, a través del mecanismo de sudo.
Con sudo el usuario necesita conocer su propia clave solamente y nunca la del usuario root.

Si usted está usando una distribución como Ubuntu, es posible que no necesite realizar este
laboratorio para tener sudo con.gurado de forma apropiada para el curso. Sin embargo, todavía
necesita asegurarse de comprender el procedimiento.

Para comprobar si su sistema ya está con.gurado para permi/r que la cuenta de usuario que está
usando ejecute sudo, ejecute un comando simple como el siguiente:

$ sudo ls

Se le debería pedir la clave de usuario y luego le debe pedir su contraseña de usuario y, a


con/nuación el comando sería ejecutado. Si en cambio ob/ene un mensaje de error, entonces
necesitará realizar el siguiente procedimiento.

Inicie una terminal de root a través del comando su y luego provea la clave de root, no su clave de
usuario.

En todas las distribuciones recientes de Linux usted debería ir al subdirectorio /etc/sudoers.d y


crear un archivo, generalmente con el nombre del usuario al cual root desea concederle acceso a
sudo. Sin embargo, esta convención no es realmente necesaria, ya que sudo escanearía todos los
archivos en este directorio. El archivo puede contener algo tan simple como lo siguiente:

estudiante ALL=(ALL) ALL

Si el usuario es estudiante.

Una prác/ca an/gua (la que aún funciona) es agregar la línea al .nal del archivo /etc/sudoers. Lo
más recomendable es hacerlo con el programa visudo, ya que se ocupa de que usted esté usando
la sintaxis adecuada mientras edita.

Es posible que necesite con.gurar los permisos adecuados en el archivo, de la siguiente forma:

$ chmod 440 /etc/sudoers.d/estudiante

Tenga en cuenta que algunas distribuciones Linux pueden requerir permisos 400 en vez de 440.
Luego de haber realizado esos pasos, salga de la consola root con exit e intente de nuevo sudo ls.

LFS201: Fundamentos de Administración de Sistemas Linux 37


Hay muchas otras cosas que un administrador puede con.gurar en sudo, incluyendo permisos para
usuarios especí.cos, limitar las búsquedas a ciertos directorios, etc. El archivo /etc/sudoers está
muy bien autodocumentado.

Sin embargo, hay un ajuste adicional que recomendamos altamente que realice, aún si su sistema
ya /ene con.gurado sudo. La mayoría de las distribuciones establecen directorios diferentes para
los directorios en donde se encuentran los ejecutables de los usuarios normales y los de root.

En par/cular los directorios /sbin y /usr/sbin no son encontrados en las búsquedas, ya que sudo
hereda el PATH del usuario, no del superusuario. Por lo tanto, en este curso estaremos
constantemente recordándole la ruta completa de varias herramientas de administración;
cualquier otra mejora en cuanto a la seguridad de esta implementación probablemente no valdría
la pena (como intentar esconder los binarios del superusuario, por ejemplo).

En consecuencia, sugerimos agregar la siguiente línea al archivo .bashrc en su directorio de


usuario:

PATH=$PATH:/usr/sbin:/sbin

No es necesario que reinicie, en vez de eso, puede salir de la sesión y entrar nuevamente, lo cual
sería completamente efec/vo.

LFS201: Fundamentos de Administración de Sistemas Linux 38


Capítulo 2. Inicio y Apagado del Sistema
Es importante delinear los pasos básicos de la secuencia de inicio y comprender el papel
de la BIOS y del UEFI, y de los principales tipos de cargadores de inicio. Los archivos de
configuración en /etc controlan el comportamiento del inicio, particularmente los
de /etc/sysconfig y/etc/default. El apagado y reinicio del sistema se puede realizar de
diferentes maneras.

Objetivos de aprendizaje

Al final de este capítulo, usted debería ser capaz de:


 Explicar el proceso de arranque.
 Identificar varios tipos de cargadores de arranque.
 Describir lo que hace la BIOS.
 Identificar los archivos de configuración importantes.
 Describir cómo el sistema se apaga y reinicia.

LFS201: Fundamentos de Administración de Sistemas Linux 39


2.1 Comprendiendo la secuencia de inicio

Los pasos básicos en el proceso de inicio son:


1 La BIOS/UEFI localiza y ejecuta el gestor de arranque, o cargador de inicio.

2 El gestor de arranque carga el kernel.

El núcleo inicia el proceso init (pid=1).


3
4 init gestiona la inicialización del sistema, utilizando scripts de inicio SysVinit
convencionales, o usando Upstart o systemd.

La secuencia de arranque

Cuando el computador se enciende, éste sólo


puede realizar las operaciones que la BIOS
(Basic Input Output System) le ordena realizar.

Primero, la BIOS ejecuta el POST


(Power On Self Test), el cual verifica la
memoria y el hardware. Luego busca un
programa de arranque en una ubicación o
dispositivo específico. Generalmente el
programa de arranque se encuentra en
el MBR del dispositivo (Master Boot Record).
Entonces el control del computador se
transfiere a este programa de booteo
(generalmente GRUB).

Entonces el programa de arranque carga el


kernel en memoria y lo ejecuta. En
plataformas x86 (y muchas otras), el kernel
tiene que descomprimirse primero. Luego
realiza verificaciones de hardware, gana acceso
a periféricos importantes y en cierto instante
ejecuta el proceso init. El proceso init continúa
con el arranque del sistema, ejecutando los
scripts de inicio si se está usando SysVinit o
administrando ya sea Upstart o systemd.

Los equipos más nuevos están cambiando a UEFI, un reemplazo para la BIOS, que
realiza muchas de las mismas funciones.

LFS201: Fundamentos de Administración de Sistemas Linux 40


2.2 Bios

En la arquitectura x86, la BIOS contiene todo el código requerido para obtener acceso
inicial al teclado, pantalla, unidades de disco, de comunicaciones en serie y un número de
funciones variadas. Una vez que el sistema completo está en marcha, la mayoría de estos
dispositivos habrán mejorado sus capacidades cuando los controladores de dispositivos
especializados y completos se cargan y asumen el control.

La BIOS se coloca típicamente en un chip ROM que viene con el equipo (el que a
menudo se llama BIOS ROM). Esto asegura que la BIOS estará siempre disponible y no
será dañada por fallas en el disco. Esto también hace que sea posible que un equipo
arranque.
Durante el proceso de arranque, la BIOS carga el gestor de arranque desde el MBR.

2.3 Gestores de arranque

Existen diferentes gestores de arranque utilizados en Linux, incluyendo:


 GRUB
 LILO
 efilinux
 Das U-Boot

Prácticamente todas las distribuciones modernas


de Linux (no-embebidas) usan GRUB
(GRand Unified Boot Loader). Las características
de GRUB incluyen la capacidad de arrancar varios
sistemas operativos, tanto en una interfaz gráfica y en
otra basada en texto que permite ser usado a través
de un cable serial, una potente interfaz de línea de
comandos para la configuración interactiva, iniciando
desde la red sin disco de arranque y otras
características avanzadas.
El cargador de Linux (LILO) es viejo y obsoleto.
efilinux es un gestor de arranque alternativo diseñado
específicamente para el mecanismo de UEFI.
Das U-Boot es el cargador más popular para
sistemas Linux embebidos; hay algunos otros, entre
ellos bareboot. Sin embargo, en realidad no estamos
considerando el espacio embebido en este curso.

LFS201: Fundamentos de Administración de Sistemas Linux 41


2.4 Archivos de Configuración en /etc

Más adelante vamos a discutir acerca de donde las distribuciones de Linux cooperan para
colocar ciertos tipos de archivos en lugares estándar en el sistema. En particular, los
archivos de configuración de todo el sistema se colocan generalmente en /etc y sus
subdirectorios, mientras que los específicos del usuario se colocan a menudo en sus
directorios personales.

Las distribuciones desarrollaron sus propias reglas sobre exactamente dónde colocar
información en /etc. Por ejemplo, todos los sistemas derivados de Red Hat hacen uso
extensivo de /etc/sysconfig, mientras que los sistemas basados en Debian han
utilizado /etc/default. Curiosamente, RHEL 7 y SUSE usan ambos.

2.5 /etc/sysconfig

En un sistema RHEL 6:

$ ls -F /etc/sysconfig
atd grub modules samba
auditd htcacheclean netconsole sandbox
authconfig httpd network saslauthd
autofs i18n networking selinux
cbq init network-scripts sendmail
cgconfig ip6tables-config nfs smartmontools
cgred.conf ip6tables-config.rpmnew ntpd snmpd
clock iptables-config ntpdate snmptrapd
collectl iptables-config.rpmnew pluto sshd
console irqbalance prelink sysstat
cpuspeed kdump quota_nld sysstat.ioconf
crond kernel radvd system-config-
firewall
dhcpd keyboard raid-check system-config-
users
dhcpd6 ksm readahead udev
dhcrelay libvirtd readonly-root vncservers
dhcrelay6 libvirt-guests rhn wpa_supplicant
ebtables-config lm_sensors rngd xinetd
firstboot mcelogd rsyslog

Para ver el contenido de un archivo:

$ cat /etc/sysconfig/network

NETWORKING=yes
HOSTNAME=quad64
GATEWAY=192.168.1.1

LFS201: Fundamentos de Administración de Sistemas Linux 42


LFS201: Fundamentos de Administración de Sistemas Linux 43
lo cual configura algunas variables ambientales usadas por varios scripts de inicio.

Los archivos en este directorio son usados a menudo por el script que controla el servicio
asociado en /etc/init.d; por ejemplo, el script /etc/init.d/network incluye la línea
con el siguiente archivo:

. /etc/sysconfig/network

el que define estas variables cuando la red se inicia.

2.6 /etc/default

En un sistema Ubuntu 14.04:

$ ls -F /etc/default
acpid console-setup grub.ucf-dist locale rsyslog
acpi-support crda halt nfs-common saned
alsa cron im-config nss speech-dispatcher
anacron cups irqbalance ntfs-3g sysstat
apport dbus kdump-tools ntpdate ufw
avahi-daemon devpts kerneloops pulseaudio useradd
bridge-utils grub kexec qemu-kvm whoopsie
brltty grub~ keyboard rcS
bsdmainutils grub.d/ libvirt-bin rsync

El uso de este directorio es similar al /etc/sysconfig de Red Hat:

 Los archivos son utilizados para proveer opciones adicionales al iniciar un servicio.

 Normalmente contienen código para configurar variables de entorno.

Por ejemplo, el archivo /etc/default/useradd establece los valores predeterminados


que se utilizan cuando se crean nuevas cuentas de usuario.

LFS201: Fundamentos de Administración de Sistemas Linux 44


2.7 Apagado y Reinicio

shutdown se utiliza para apagar el sistema de forma segura, notificando a todos los
usuarios que el sistema va a apagarse y luego lo detiene de manera elegante y no
destructiva. Después de que está apagado, el sistema es detenido o reiniciado.

Ejemplos de shutdown

$ sudo shutdown -h +1 “Power Failure imminent”


$ sudo shutdown -h now
$ sudo shutdown -r now
$ sudo shutdown now

Las opciones pueden ser listadas fácilmente por el mensaje de ayuda:

$ shutdown—help
shutdown [OPTIONS...] [TIME] [WALL...]
Shut down the system.
help Show this help
H—halt Halt the machine
P—poweroff Power-off the machine
r—reboot Reboot the machine
h Equivalent to—poweroff, overridden by—halt
k Don’t halt/power-off/reboot, just send warnings
no-wall Don’t send wall message before halt/power-off/reboot
c Cancel a pending shutdown

Sin opciones (por ejemplo, shutdown now) el comportamiento por defecto es apagar por
completo el sistema. Algunas distribuciones, como Ubuntu, violan esto y van a modo
monosuario en vez de apagarse.

Un error común es no especificar un argumento de tiempo (tal como now o algún tiempo
real). Esto es requerido.

También existen los comandos heredados reboot, halt y poweroff, los que muchos
usuarios veteranos utilizan con frecuencia.

LFS201: Fundamentos de Administración de Sistemas Linux 45


Comprobación de conocimientos 2.1

LFS201: Fundamentos de Administración de Sistemas Linux 46


2.8 Laboratorio 2.1
Laboratorio 2.1: shutdown vs. halt vs. Reboot

Nota: este ejercicio requiere ser ejecutado desde la consola, es decir, no a través de la red usando
SSH.
1. Lleve el sistema a modo monousuario usando el comando shutdown.
2. Desde el modo monousuario, reinicie el sistema con el comando shutdown.
3. Una vez que el sistema haya reiniciado, apáguelo completamente usando el comando
shutdown.
4. Vuelva a iniciar el sistema.

Laboratorio 2.1: shutdown vs. halt vs. Reboot:

Solución
1. $ sudo shutdown now

2. $ sudo shutdown -r now

3. $ sudo shutdown -h now

4. Presione el botón de apagado o reinicie su máquina virtual.

Objetivos de aprendizaje (revisión)

Usted debería ser capaz de:


 Explicar el proceso de arranque.
 Identificar varios tipos de cargadores de arranque.
 Describir qué hace la BIOS.
 Identificar los archivos de configuración correspondientes.
 Describir cómo el sistema se apaga y reinicia.

LFS201: Fundamentos de Administración de Sistemas Linux 47


Capítulo 3. GRUB
Un sistema que no puede iniciar es bastante inútil. Los sistemas Linux tienen mucha
flexibilidad en la forma de arrancar. Es posible elegir versiones diferentes del kernel u
opciones, o incluso diferentes sistemas operativos en escenarios de inicio múltiple. La
mayoría de los sistemas no embebidos utiliza el Grand Unified Boot Loader para realizar
los primeros pasos de una inicialización exitosa del sistema. GRUB también tiene
capacidades interactivas, así como una utilidad de contraseñas seguras.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Explicar cuál es el rol de GRUB.
 Comprender las diferencias entre las versiones GRUB 1 y GRUB 2.
 Estar familiarizado con las selecciones interactivas que se pueden realizar en el
arranque.
 Saber cómo instalar GRUB.
 Explicar cómo se usan y modifican los archivos de configuración que
GRUB necesita.

LFS201: Fundamentos de Administración de Sistemas Linux 48


3.1 Que es GRUB?

Prácticamente todos sistemas basados en x86 de Linux (dejando de lado la esfera de los
sistemas embebidos) usan GRUB actualmente (GRand Unified Bootloader) para
manejar las primeras fases de arranque del sistema. Otras plataformas pueden tener
otros equivalentes, como ELILO, utilizado en sistemas EFI como IA64 (Itanium) y Das U-
BOOT utilizado en muchas configuraciones de sistemas embebidos.

Algunas características importantes de GRUB son:


 Sistemas operativos alternativos pueden ser elegidos en el momento del arranque.

 Los kernels alternativos o ramdisk inicial pueden ser elegidos durante el arranque
para un determinado sistema operativo.

 Los parámetros de arranque pueden cambiarse fácilmente al arrancar sin tener


que editar archivos de configuración, etc. de antemano.

Las distribuciones de Linux más antiguas (por ejemplo, RHEL 6) usan versiones antiguas
de GRUB, 1.0 o menor, mientras que las más recientes se basan en GRUB 2. Mientras
que los detalles son diferentes entre las versiones, la filosofía básica es la misma.

Configuración básica de los archivos de GRUB 2.

El archivo de configuración básico de arranque se llama:

/boot/grub/grub.cfg o /boot/grub2/grub.cfg

Este archivo es autogenerado por update-grub (o grub2-mkconfig en RHEL 7), basado


en los archivos de configuración en el directorio /etc/grub.d y en/etc/default/grub, y
nunca deberían ser editados a mano. Normalmente esas herramientas son ejecutadas
desde otros scripts provistos por cada distribución, usados para actualizar o compilar
kernels Linux.

Configuración básica de los archivos de GRUB 1.

El archivo de configuración básico de arranque se llama:

/boot/grub/grub.conf o /boot/grub/menu.lst.

Nuevamente, recomendamos no editar a mano el archivo de configuración. Por ejemplo,


en RHEL 5-7 se modifica desde la herramienta grubby. Sin embargo, si usted realiza
cambios, serán mantenidos, mientras que para GRUB 2 cualquier cambio directo
en grub.cfg se pierde tan pronto como el archivo se genera nuevamente.

Para cualquier versión, el archivo de configuración principal contiene algunos parámetros


globales y luego una sección para cada sistema operativo o núcleo configurado.

LFS201: Fundamentos de Administración de Sistemas Linux 49


3.2 Selecciones Interactivas con GRUB en el arranque

Al arranque del sistema, después de las etapas iniciales del POST y BIOS, GRUB se
ejecutará y mostrará un menú.

Este puede o no tener gráficos en él (al menos para el fondo de pantalla de splash). El
menú contiene una lista de imágenes de arranque de uno o más sistemas operativos o
distribuciones de Linux. En GRUB 2 (o, si usas ‘chainloading’ para conectar múltiples
instalaciones de GRUB en el mismo disco, un tema complicado que no trataremos aquí)
también pueden haber submenús con aún más opciones.

Usando las flechas arriba y abajo y la tecla Enter, usted puede seleccionar la opción de
arranque correcta, o puede esperar durante un periodo de tiempo configurable antes de
entrar en la opción predeterminada.

Sin embargo, es posible hacer mucho más. Después de seleccionar una entrada, puede
escribir e para editar y luego entrar en una shell interactiva. En esta shell, puede modificar
la sección en el archivo de configuración que describe esa opción de arranque particular.
Por lo general, esto se hace para modificar la línea de comandos del kernel; por
ejemplo, agregando la palabra single al final de la línea de comando hará que el sistema
arranque en el modo monousuario con el fin de tomar acciones correctivas. Una vez que
el cambio deseado se ha realizado, usted puede presionar la tecla adecuada para iniciar
el sistema.

En la parte inferior de la pantalla verá que aparece información sobre las combinaciones
de teclas exactas, así que no es necesario memorizarlas.

Tenga en cuenta que cualquier cambio que realice en la configuración no es


persistente y se perderá en el próximo inicio. Para realizar cambios permanentes, es
necesario modificar los archivos en el sistema, usando las utilidades adecuadas.

También es posible introducir una shell pura, en lugar de editar una sección en particular.
Puede ejecutar una serie de comandos diferentes e incluso tratar de reinstalar o
reparar GRUB. Si hay problemas serios, como no encontrar un archivo de
configuración, GRUB vuelve al modo de línea de comandos y usted podría rescatar el
sistema sin tener que recurrir a los medios físicos (DVDs).

LFS201: Fundamentos de Administración de Sistemas Linux 50


3.3 Instalación de GRUB

La palabra instalación puede tener significados diversos en relación a GRUB:


1. Instalar el programa grub y sus herramientas asociadas en sus lugares
respectivos. En GRUB 1 hay un solo programa llamado grub, pero en GRUB
2 hay un montón de utilidades con nombres como grub2-* or grub-*; el cómo
están empaquetados depende bastante de la distribución.

2. Instalar los archivos que GRUB necesita para operar en el momento de arranque,
ya sea en /boot/grub o/boot/grub2. Esto es independiente de los archivos que
el kernel Linux necesita (vmlinuz-*, initramfs-*), los cuales deberán estar en
el directorio /boot también.

3. Instalar GRUB como el gestor de arranque en el sistema; generalmente esto se


hace en el comienzo de todo el disco duro, pero también puede ser realizado en
una partición y acceder a él través de ‘chainloading’, es decir de un GRUB a otro.

Si no instala GRUB durante la instalación o si necesita volver a instalarlo en algún


momento más adelante, el procedimiento exacto para hacerlo depende de la versión
de GRUB.

Procedimiento de instalación de GRUB 2.

Para la Versión 2, el procedimiento de instalación es tan simple como:

$ sudo grub2-install /dev/sda

Por favor lea la página del manual con cuidado antes de ejecutar un comando como ese;
hay muchas opciones y hacer algo mal en GRUB puede hacer que el sistema no
arranque. En particular tendrá que indicarle al sistema donde encontrar el
directorio /boot y en qué partición reside.

Procedimiento de instalación para GRUB 1.


En la versión 1 la herramienta pertinente es grub-install. También es posible
ejecutar grub en la línea de comandos, para luego entrar a un programa interactivo. Por
ejemplo:

$ sudo grub
> root (hd0,0)
> setup (hd0)
> exit
$

lo cual debería instalar grub en el primer disco y los archivos de arranque en la primera
partición.

LFS201: Fundamentos de Administración de Sistemas Linux 51


3.4 Nomenclatura de dispositivos de GRUB

En ambas versiones de GRUB, el primer y segundo disco duro es denominado como hd0,
el segundo como hd1, etc. Sin embargo, en la versión 1 las particiones comienzan
contando desde 0 y en la versión 2 desde 1:

 sda1 es (hd0,1) en GRUB 2, pero (hd0,0) en GRUB 1.


 sdc4 es (hd2,4) en GRUB 2, pero (hd2,3) en GRUB 1.

No hay necesidad de enfatizar que confundirse acerca de esto puede ser muy destructivo.
Ambas versiones de GRUB a veces usan la notación de sda# y a veces usan (hd0,#), así
que puede ser aún más confuso.

Dentro del archivo de configuración, cada sección tiene que especificar cuál es la
partición raíz; esto no es lo mismo que lo que queremos decir cuando hablamos del
directorio raíz del sistema. En este contexto significa la partición que contiene el kernel
(en el directorio /boot). Por ejemplo, es muy común tener /boot en su partición propia,
digamos/dev/sda1. Luego, en GRUB 1 podrá encontrar una sección simple como la
siguiente:

title 3.17.3
root (hd0,0)
kernel vmlinuz-3.17.3 ro root=/dev/sda2 quiet
initrd initramfs-3.17.3.img

Sin embargo, si /boot no tiene su propia partición, se vería como lo siguiente:

title 3.17.3
root (hd0,0)
kernel /boot/vmlinuz-3.17.3 ro root=/dev/sda1 quiet
initrd /boot/initramfs-3.17.3.img

También es posible especificar kernel (hd0,0)/vmlinuz .... , y dejar de lado la


línea root.

En GRUB 2 la sintaxis es diferente pero obvia; una mirada rápida


a /boot/grub2/grub.cfg lo dejará claro.

LFS201: Fundamentos de Administración de Sistemas Linux 52


3.5 Personalizando el archivo de configuración GRUB

Nos vamos a concentrar en GRUB 2 porque las versiones anteriores se están volviendo
obsoletas rápidamente. Además es esencialmente el mismo en las diversas distribuciones
de Linux.

Recuerde que no debería editar grub.cfg directamente. Hay dos lugares en el


directorio /etc que deberían requerir atención y se utilizan para
reconstruir grub.cfg cuando el sistema se ve alterado con la instalación de kernel
nuevos, o cuando se ejecuta de forma manual un programa de actualización
(como update-grub).
El primero es /etc/default/grub. En un sistema RHEL 7 luce de la siguiente forma:

$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=”$(sed ‘s, release .*$,,g’ /etc/system-release)”
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT=”console”
GRUB_CMDLINE_LINUX=”vconsole.keymap=us crashkernel=auto
vconsole.font=latarcyrheb-sun16 rhgb quiet”
GRUB_DISABLE_RECOVERY=”true”

Red Hat ha abreviado bastante este archivo en comparación con otras distribuciones. Por
ejemplo, en un sistema Ubuntu 14.4 se ve de la siguiente forma:

$ cat /etc/default/grub
# If you change this file, run ‘update-grub’ afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n ‘Simple configuration’
GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=’lsb_release -i -s 2> /dev/null || echo Debian’
GRUB_CMDLINE_LINUX_DEFAULT=”quiet”
GRUB_CMDLINE_LINUX=”find_preseed=/preseed.cfg auto noprompt
priority=critical locale=en_US”
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel
that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD
...)
#GRUB_BADRAM=”0x01234567,0xfefefefe,0x89abcdef,0xefefefef”
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports
via VBE
# you can see them in real GRUB with the command ‘vbeinfo’
#GRUB_GFXMODE=640x480

LFS201: Fundamentos de Administración de Sistemas Linux 53


# Uncomment if you don’t want GRUB to pass “root=UUID=xxx”
parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY=”true”
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE=”480 440 1”

El otro directorio que importa es /etc/grub.d:

$ ls -l /etc/grub.d
total 76
• rwxr-xr-x 1 root root 9424 Sep 8 17:35 00_header
• rwxr-xr-x 1 root root 6058 Sep 8 17:35 05_debian_theme
• rwxr-xr-x 1 root root 11608 Sep 8 17:35 10_linux
• rwxr-xr-x 1 root root 10412 Sep 8 17:35 20_linux_xen
• rwxr-xr-x 1 root root 1992 Sep 8 17:35 20_linux_xen
• rwxr-xr-x 1 root root 11692 Sep 8 17:35 30_os-prober
• rwxr-xr-x 1 root root 1416 Sep 8 17:35 30_uefi-firmware
• rwxr-xr-x 1 root root 214 Sep 8 17:35 40_custom
• rwxr-xr-x 1 root root 216 Sep 8 17:35 41_custom
• rw-r—r-- 1 root root 483 Sep 8 17:35 README

donde una vez más estamos mostrando Ubuntu 14.04. Cada uno de estos archivos se
ejecutan en orden ascendente cuando se actualiza el archivo de configuración. No los
discutiremos aquí debido a que están bien autodocumentados y recomendamos que les
eche un vistazo.

Para GRUB 1 cada distribución puede tener algunas peculiaridades, pero básicamente se
edita grub.conf directamente o a través de un script como grubby.

LFS201: Fundamentos de Administración de Sistemas Linux 54


Comprobación de conocimientos 3.1

Falso

Verdadero

Falso

Verdadero

LFS201: Fundamentos de Administración de Sistemas Linux 55


Falso

Falso

3.6 Laboratorio 3.1


Laboratorio 3.1: Inicio en modo no gráco usando GRUB

Nota: Este ejercicio requiere ser ejecutado desde la consola, es decir, no a través de SSH.
1. Reinicie su máquina y vaya a la consola interac/va de GRUB presionando e, o cualquier otra
tecla que sea requerida para tal efecto, según se indique en la pantalla.
2. Haga que su sistema inicie en modo no grá.co. La forma de hacerlo dependerá de su sistema
especí.co. En sistemas tradicionales que respetan los runlevels (los cuales trataremos en la
próxima sección) es posible agregar un 3 a la línea de comandos del kernel, en la entrada
especí.ca que seleccionó desde las opciones en el menú de GRUB.

En otros sistemas (incluyendo Ubuntu) es necesario agregar text en cambio.


3. Teclee la tecla apropiada para que el sistema con/núe iniciando.
4. Luego de que el sistema está completamente operacional en modo no grá.co, llévelo a modo
grá.co. Dependiendo de su sistema, uno de los siguientes comandos debería hacerlo:

$ sudo telinit 5
$ sudo service gdm restart
$ sudo service lightdm restart

LFS201: Fundamentos de Administración de Sistemas Linux 56


Objetivos de aprendizaje (revisión)

Usted debería ser capaz de:


 Explicar cuál es el rol de GRUB.
 Comprender las diferencias entre GRUB 1 y GRUB 2.
 Estar familiarizado con las selecciones interactivas que puede hacer en el
arranque.
 Saber cómo instalar GRUB.
 Explicar cómo se usan y modifican los archivos de configuración que
GRUB necesita.

LFS201: Fundamentos de Administración de Sistemas Linux 57


Capítulo 4. init: SystemV, Upstart, Systemd
Cuando un sistema Linux se inicia, muchas tareas deben llevarse a cabo de manera
cooperativa. Los dispositivos tienen que ser reconocidos e inicializados, los servicios del
sistema tienen que ser lanzados, los sistemas de archivos tienen que estar disponibles,
procesos de gestión importantes tienen que iniciarse y el sistema debe estar disponible a
los usuarios para iniciar sesión. Todo esto debe hacerse en la secuencia correcta y lo más
rápidamente posible.

Objetivos de Aprendizaje

Al final de este capítulo usted debería estar capacitado para:


 Entender la importancia del proceso init.
 Explicar cómo funciona el método tradicional de SysVinit, cómo incorpora
los niveles de ejecución y qué sucede en cada uno.
 Saber usar chkconfig y service (y utilidades alternativas) para iniciar y detener
servicios o hacerlos persistentes luego del reinicio del sistema.
 Entender por qué surgieron los métodos alternativos Upstart ysystemd y cómo
funcionan.
 Usar systemctl para configurar y controlar systemd.

LFS201: Fundamentos de Administración de Sistemas Linux 58


4.1 Proceso init

/sbin/init (normalmente llamado init) es el primer proceso (o tarea) a nivel de usuario


que se ejecuta en el sistema y continúa funcionando hasta que el sistema se apaga.
Tradicionalmente ha sido considerado el padre de todos los procesos del usuario, aunque
técnicamente eso no es cierto ya que algunos procesos son iniciados directamente por el
kernel.

init coordina las etapas posteriores del proceso de arranque, configura todos los aspectos
del ambiente e inicia los procesos necesarios para entrar/autenticarse en el
sistema. init también trabaja estrechamente con el kernel para limpiar lo necesario a
medida en que los procesos terminan.

Tradicionalmente casi todas las distribuciones basan el proceso init en el


venerable SysVinit de UNIX. Sin embargo, este esquema fue desarrollado décadas atrás
en circunstancias muy diferentes:
 El objetivo eran sistemas multiusuario de tipo mainframe (y no ordenadores
personales, portátiles y otros dispositivos).
 El objetivo era un sistema de procesador único.
 El tiempo de inicio (y apagado) no era un asunto importante; era mucho más
importante hacer que las cosas funcionaran bien.

El inicio fue visto como un proceso serial, dividido en una serie de etapas secuenciales.
Cada etapa requería ser finalizada antes de que la próxima pudiera iniciar. Por lo tanto, el
arranque no aprovechó el procesamiento en paralelo que podría hacerse en múltiples
procesadores.

En segundo lugar, el apagado/reinicio fue visto como un acontecimiento relativamente


raro y exactamente cuánto demoraban no era considerado importante.

LFS201: Fundamentos de Administración de Sistemas Linux 59


4.2 Alternativas de arranque

Para lidiar con estas limitaciones intrínsecas en SysVinit, se han desarrollado nuevos
métodos para controlar el arranque del sistema. Si bien es cierto que existen otros, dos
esquemas principales fueron adoptados por distribuidores Empresariales:
1. Upstart fue desarrollado por Ubuntu y fue incluido por primera vez en el
lanzamiento de la versión 6.10 en el 2006 y pasó a ser utilizado por defecto en el
lanzamiento de la versión 9.10, el 2009. También fue adoptado en Fedora 9(en el
2008) y en RHEL 6 y sus clones, tales como CentOS, Scientific Linux y Oracle
Linux. En openSUSE fue ofrecido como una opción desde la versión 11.3.
También se ha utilizado en varios dispositivos embebidos y móviles.

2. systemd es más reciente y Fedora fue la primera distribución de las principales


en adoptarlo en el 2011.

RHEL 7 se basa en systemd y cada distribución principal de Linux lo ha adoptado y


usado por defecto, o ha anunciado planes para hacerlo. Los desarrolladores principales
de systemd están estrechamente vinculados a la comunidad del kernel de Linux.
Incluso Ubuntu ha programado el retiro de Upstart en su favor.
La migración a los nuevos esquemas puede ser complicada debido a que los errores de
software y funciones faltantes pueden ser muy incapacitantes, de hecho han habido capas
que requieren compatibilidad esencial. Por lo tanto, los métodos y
utilidades SysVinit persistirán por mucho tiempo aunque bajo el capó, las cosas son muy
diferentes.
La historia de las controversias y todo esto es muy complicado, y personalidades
interesantes han asegurado no que toda la discusión es de carácter técnico. En nuestro
contexto no veremos a través de esta lente.
En adelante vamos a concentrarnos en SysVinit y systemd con una breve sección
sobre Upstart (aunque RHEL 6 y algunas otras distribuciones han estado
usando Upstart, éste ha sido completamente oculto detrás de una capa de compatibilidad
usando las utilidades SysVinit normales).

4.3 Niveles de ejecución de SysVinit

Un sistema SysVinit inicia a través de una secuencia de ‘runlevels’ (niveles de ejecución)


que definen diferentes estados del sistema; están numerados del 0 al 6.

El runlevel 0 está reservado para el apagado del sistema, runlevel 1 para el modo
monousuario y runlevel 6 para reiniciar el sistema. Los otros runlevels se usan para
definir qué servicios están ejecutándose en un sistema normal; según el caso, las
distribuciones definen algo de forma diferente. Por ejemplo, en sistemas basados en Red
Hat, runlevel 2 se define como un sistema en funcionamiento sin red o X, runlevel 3
incluye soporte de red, y runlevel 5 incluye red y X.

LFS201: Fundamentos de Administración de Sistemas Linux 60


El runlevel actual pueden ser desplegado simplemente con el comando runlevel, como se
muestra aquí:

$runlevel
N 5

donde el primer carácter es el nivel previo; N significa desconocido.


telinit puede ser usado para cambiar el nivel de ejecución del sistema. Por ejemplo, para
ir desde runlevel 3 a runlevel 5, ejecute lo siguiente:

$ sudo /sbin/telinit 5

LFS201: Fundamentos de Administración de Sistemas Linux 61


4.4 SysVinit y /etc/inittab

Cuando el proceso init es iniciado, lo primero que hace es leer /etc/inittab.


Históricamente, este archivo ha instruido a init acerca de los scripts que debe ejecutar
para llevar al sistema a cada runlevel. Y se ha hecho con una serie de líneas, una para
cada runlevel:
id:runlevel(s):action:process
donde:
 id: un identificador único de 1 a 4 caracteres para la entrada.
 runlevel(s): cero o más caracteres individuales o identificadores de dígitos, el que
indica en qué nivel de ejecución se realizará la acción.
 action: describe la acción a ser realizada.
 process: especifica el proceso a ser ejecutado.

Sin embargo, en sistemas más recientes como RHEL 6 que enmascaran upstart detrás
de una capa de compatibilidad, la única línea descomentada y lo único que se encuentra
en este archivo es el runlevel predeterminado con la línea:
id:5:initdefault
Este es el runlevel al cual llegará el sistema una vez que haya terminado de iniciar. Sin
embargo, si se especifica otro valor en la línea de comandos del núcleo, init ignora el
valor por defecto (esto se hace añadiendo el dígito entero a la línea de comandos del
núcleo). El runlevel por defecto es generalmente 5 para un sistema completo, lo cual
considera soporte multiusuario, sistema gráfico en red o 3 para un servidor sin una
interfaz gráfica.

4.5 Scripts de inicio de SysVinit

El método tradicional es que primero se ejecute el script rc.sysinit, el cual realiza


numerosas funciones, como iniciar LVM, montar sistemas de archivos, etc. Este script
reside en el directorio /etc, pero probablemente lo encontrará en /etc/rc.d con un enlace
simbólico a /etc.
A continuación, se ejecuta el script rc (en el mismo directorio) con el runlevel deseado
como argumento. Esto hace que el sistema vaya al directorio rc.d/rc[0-6].d y ejecute
todos los scripts que están ahí:

LFS201: Fundamentos de Administración de Sistemas Linux 62


$ ls -lF /etc/rc.d/rc5.d
total 0
lrwxrwxrwx. 1 root root 14 Sep 3 10:05 K05pmcd -> ../init.d/pmcd*
lrwxrwxrwx. 1 root root 14 Sep 3 10:05 K05pmie -> ../init.d/pmie*
lrwxrwxrwx. 1 root root 18 Sep 3 10:05 K05pmlogger -> ../init.d/pmlogger*
lrwxrwxrwx. 1 root root 15 Sep 3 10:05 K05pmmgr -> ../init.d/pmmgr*
lrwxrwxrwx. 1 root root 17 Sep 3 10:05 K05pmproxy -> ../init.d/pmproxy*
lrwxrwxrwx. 1 root root 16 Sep 3 10:05 K05pmwebd -> ../init.d/pmwebd*
lrwxrwxrwx 1 root root 37 Sep 6 08:50 K08vmware-USBArbitrator ->
/etc/rc.d/init.d/vmware-USBArbitrator*
lrwxrwxrwx. 1 root root 20 Sep 3 03:57 K50netconsole ->
../init.d/netconsole*
lrwxrwxrwx. 1 root root 17 Sep 3 09:39 S10network -> ../init.d/network*
lrwxrwxrwx 1 root root 16 Sep 6 08:50 S19vmware -> ../init.d/vmware*
lrwxrwxrwx. 1 root root 17 Sep 3 04:04 S20iprinit -> ../init.d/iprinit*
lrwxrwxrwx. 1 root root 19 Sep 3 04:04 S20iprupdate ->
../init.d/iprupdate*
lrwxrwxrwx. 1 root root 17 Sep 3 10:05 S21iprdump -> ../init.d/iprdump*
lrwxrwxrwx 1 root root 17 Sep 6 08:51 S25vmamqpd -> ../init.d/vmamqpd*
lrwxrwxrwx 1 root root 37 Sep 6 08:50 S50vmware-USBArbitrator ->
/etc/rc.d/init.d/vmware-USBArbitrator*
lrwxrwxrwx. 1 root root 15 Sep 3 03:59 S97rhnsd -> ../init.d/rhnsd*

El script rc.local puede ser usado para iniciar aplicaciones específicas del sistema.
Note lo siguiente:
 Todos los scripts reales están en /etc/init.d: cada directorio de nivel de ejecución
solo enlaza a ellos.
 Los nombres de los scripts de inicio comienzan con s.
 Los nombres de los scripts de detención comienzan con k.

La existencia (o falta) de un vínculo simbólico de un script en un directorio de runlevel


determina si el script se ejecuta en ese runlevel o no.
El número que le sigue a la K o S en cada nombre de script determina el orden en el cual
los scripts son invocados. El nombre del script corresponde también al nombre
del servicio.
Controlar qué scripts de inicialización se ejecutan al entrar a cada runlevel consiste en
gestionar los enlaces simbólicos. Mientras que es posible administrar estos vínculos de
forma manualmente, hay utilidades como chkconfig que están diseñadas para hacer esto
de manera consiste y simple.

LFS201: Fundamentos de Administración de Sistemas Linux 63


4.6 chkconfig

chkconfig se utiliza para consultar y configurar en qué runlevels van a correr los
diferentes servicios del sistema.
Ejemplos de chkconfig
Verifica un servicio en particular para comprobar si está configurado para correr en el
runlevel actual:

$ chkconfig some_service

Esto devolverá “verdadero” si el servicio está configurado para ejecutarse, y por el


contrario, “falso”. Note que aún si el servicio está configurado para correr, podría estar
detenido actualmente.
 Ver qué servicios están configurados para correr en cada uno de los runlevels:

$ chkconfig—list [service names]

 Configurar un servicio para que se ejecute en el próximo reinicio:

$ sudo chkconfig some_service on

 Configurar un servicio para que no se ejecute en el próximo reinicio:

$ chkconfig some_service off

 Tenga en cuenta que las operaciones on y off no inciden en el estado actualdel


servicio para iniciarlo o detenerlo. Esto se realiza de la siguiente forma:

$ sudo service some_service [ stop | start ]

No es difícil añadir sus propios servicios y escribir scripts de inicio. Solamente hay que
poner el script en /etc/init.d, el cual debe tener ciertas características (¡sólo algunas
líneas en el comienzo del archivo!) y luego usar chkconfig –add para habilitarlo
o chkconfig—del para desactivar el uso de las instrucciones on y off.
¿Cómo lo hace chkconfig para determinar qué número debería aparecer luego de
la S o K en un enlace simbólico? ¿Cómo sabe qué runlevels configurar en on u off y qué
estado configurar en los enlaces simbólicos? La información está en los propios scripts,
los cuales contienen una línea en la parte de arriba, como la siguiente:

# chkconfig: 2345 10 90

El primer argumento luego de chkconfig: aquí se definen los runlevels en los cuales el
servicio va a ejecutarse por defecto. En el ejemplo de arriba con los runlevels 2, 3, 4 y 5.
El segundo y tercer número son los prefijos numéricos en los scripts de inicio y detención;
en el caso de arriba inician con S10 y K90.

LFS201: Fundamentos de Administración de Sistemas Linux 64


4.7 .a. service

Cada sistema operativo tiene servicios que generalmente arrancan en la inicialización del
sistema y a menudo permanecen funcionando hasta el apagado. Tales servicios pueden
ser iniciados, detenidos o reiniciados en cualquier momento, lo que generalmente requiere
privilegios de root. En un sistema Linux usando o emulando SysVinit, los servicios están
en el directorio /etc/init.d.

En sistemas basados en Red Hat es posible ver el estado de un servicio en particular de


la siguiente forma:

$ sudo service network status


Configured devices:
lo eth0 eth1 eth2 wlan0
Currently active devices:
lo eth0
$ sudo service vsftpd status
vsftpd (pid 5284) is running...

service tiene diversas opciones, las que varían según el servicio en particular; por
ejemplo:

$ sudo service network


Usage: /etc/init.d/network {start|stop|restart|reload|status}
$ sudo service iptables
Usage: /etc/init.d/iptables {start|stop|restart|condrestart|status|
panic|save}

Todo servicio se dirige al directorio /etc/init.d y ejecuta el script apropiado en ese


directorio con las opciones suministradas.

LFS201: Fundamentos de Administración de Sistemas Linux 65


4.7 .b. service

Es posible ver el estado de todos los servicios en el sistema con:

$ sudo service—status-all
acpid (pid 4170) is running...
anacron (pid 4540) is running...
atd (pid 4553) is running.......
smartd (pid 4614) is running...
smbd is stopped......

El iniciar y detener servicios con service es efectivo sólo durante la operación actual del
sistema; todos los cambios se pierden al reiniciar. Para configurar que un servicio en
particular se active o no durante la inicialización del sistema - en sistemas basados
en Red Hat - se utiliza chkconfig como se describió anteriormente.

4.8 chkconfig service en sistemas basados en debian


En sistemas basados en Debian, incluyendo Ubuntu, las utilidades anteriores
funcionarán solamente si se han instalado los paquetes sysvinit-utils y chkconfig, como
se muestra aquí:
$ sudo apt-get install sysvinit-utils chkconfig

Sin embargo, las versiones recientes de Ubuntu ya no tienen el paquete chkconfig;


tendrá que utilizar la utilidad update-rc.d que se describe más abajo.
Como alternativa, puede utilizar los comandos nativos en estos sistemas. Por ejemplo, el
equivalente de la utilidad service es:

$ sudo invoke-rc.d cups [ status | start | stop ]


$ sudo status cups

para visualizar o cambiar el estado de cups. El comando status es más reciente y es


preferido sobre invoke-rc.d.
Del mismo modo el equivalente de chkconfig sería:

$ sudo update-rc.d cups [ defaults | purge ]


$ sudo sysv-rc-conf cups [ on | off ]

Usted deberá consultar las páginas man para acceder a la documentación completa.

LFS201: Fundamentos de Administración de Sistemas Linux 66


4.9 Upstart

Upstart es manejado por eventos, en lugar de ser un conjunto de procedimientos en


forma serial. Las notificaciones de eventos son enviadas al proceso init para ejecutar
ciertos comandos en el momento justo después de que han cumplido los requisitos
previos. Debido a que Upstart está siendo reemplazado por systemd, no invertiremos
mucho tiempo en él ni hacemos ejercicios al respecto.
Los archivos de configuración de upstart son:

/etc/init/rcS.conf
/etc/rc-sysinit.conf
/etc/inittab
/etc/init/rc.conf
/etc/rc[0-6].d

Cuando el kernel inicia el proceso init, éste ejecuta el script rcS.conf. Esto a su vez,
hace que rc-sysinit.conf se ejecute.

rc-sysinit.conf realizará una serie de tareas, incluyendo iniciar LVM, montar sistemas
de archivos y luego ejecuta todos los scripts para el runlevel por defecto especificado
en /etc/inittab.

Esto se logra mediante la ejecución de rc.conf y pasando al runlevel. Los scripts del
runlevel levantan los servicios en el sistema.
Finalmente, scripts adicionales como prefdm.conf son ejecutados (para el runlevel 5
solamente).

Como se mencionó anteriormente, /etc/inittab está obsoleto y ahora sólo se utiliza


para configurar el runlevel predeterminado mediante la línea initdefault. Otra
configuración se realiza mediante Upstart en el directorio/etc/init. En
general, Upstart se encontrará en el directorio /etc/event.d.

Por ejemplo, el número de consolas tty activas ahora se establece mediante la


variable ACTIVE_CONSOLES en/etc/sysconfig/init, la que es leída por
/etc/init/start-ttys.conf. El valor predeterminado es ACTIVE_CONSOLES=/dev/tty
[1-6], el cual inicia un proceso getty desde tty1 hasta tty6.

LFS201: Fundamentos de Administración de Sistemas Linux 67


4.10 Utilidades de Upstart
Usando initctl usted puede ver, iniciar y detener procesos casi del mismo modo que lo
hace service. La sintaxis es como sigue:

$ initctl options command

donde options puede tener los siguientes valores:


 start: Inicia un proceso

 stop: Detiene un proceso

 restart Reinicia un proceso

 reload Envía la señal HUP a un proceso

 status Consulta el estado de un proceso

 list: Lista los procesos conocidos

 emit Emite un evento

Es posible encontrar un buen resumen de cómo utilizar initctl y muchas otras


características de upstart en http://upstart.ubuntu.com/cookbook.

4.11 systemd
El sistema de administración central systemd y manejador de sesión para Linux está
tomando lugar rápidamente en todas las distribuciones importantes.

systemd es compatible con SysVinit y el concepto de runlevels está soportado a través


de ‘targets’ de nivel de ejecución. El programa telinit es emulado para trabajar con
runlevels.
Las caracterís/cas de systemd y del gestor de sesión incluyen lo siguiente:
 Es compatible con los scripts de SysVinit.
 Inicia más rápido que los sistemas anteriores.
 Provee altas capacidades de paralelización.
 Usa socket y activación D-Bus para iniciar servicios.
 Reemplaza scripts de shell scripts con programas.
 Ofrece inicio de demonios sobre demanda.
 Realiza seguimiento de los procesos usando cgroups.
 Soporta la creación de snapshots y restauración del estado del sistema.
 Mantiene puntos de montaje y automontaje.
 Implementa una elaborada lógica de control de servicio basada en dependencia
transaccional.
 Puede trabajar como un reemplazo de SysVinit.

En vez de utilizar scripts bash, systemd usa archivos.service.

LFS201: Fundamentos de Administración de Sistemas Linux 68


Adicionalmente, systemd clasifica todos los demonios en su propio cgroups del
núcleo Linux (grupos de control).
4.12 Archivos de configuración de systemd

Aunque systemd prefiere utilizar un conjunto de archivos de configuración


correspondientes a un estándar nuevo, también puede utilizar archivos de
configuración heredados dependiente de cada distribución.

Un ejemplo de un archivo de configuración nuevo sería /etc/hostname, el cual


reemplazaría a/etc/sysconfig/network en Red Hat, /etc/HOSTNAME en SUSE y
a /etc/hostname (adoptado como estándar) enDebian.
Otros archivos pueden incluir:
 /etc/vconsole.conf: mapa de teclado por defecto y fuente de consola.

 /etc/sysctl.d/*.conf: directorio para los parámetros sysctl del kernel.

 /etc/os-release: archivo de ID de la distribución.

4.13 systemctl

systemctl es la utilidad principal para manejar servicios. La sintaxis básica es la


siguiente:
$ systemctl [options] command [name]

A continuación puede ver algunos ejemplos de cómo usar systemctl:


 Para ver el estado de todo lo que controla systemd:

$ systemctl

 Para ver todos los servicios disponibles:

$ systemctl list-units -t service—all

 Para mostrar los servicios activos solamente:

$ systemctl list-units -t service

 Para iniciar (activar) una o más unidades:

$ sudo systemctl start foo


$ sudo systemctl start foo.service
$ sudo systemctl start /path/to/foo.service

LFS201: Fundamentos de Administración de Sistemas Linux 69


en donde una unidad puede ser un servicio o un socket.
 Para detener (desactivar):

$ sudo systemctl stop foo.service

 Para habilitar/deshabilitar un servicio:

$ sudo systemctl enable sshd.service


$ sudo systemctl disable sshd.service

Esto es el equivalente de chkconfig—add/--del y no inicia el servicio.

Nota: algunos comandos systemctl de los mostrados arriba pueden ser ejecutados como
usuario normal, sin embargo otros tienen que ser ejecutados como root o con sudo.

Para ver un excelente resumen de cómo pasar desde SysVinit a systemd, consulte la
documentación SysVinit to Systemd Sheatsheet en:
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet.

LFS201: Fundamentos de Administración de Sistemas Linux 70


Tabla 4.13. Hoja de Apuntes de SysVinit a Systemd
(versión resumida)

Versión abreviada de la Hoja de Apuntes de SysVinit a Systemd, mostrando las


equivalencias principales de los comandos service y chkconfig.

LFS201: Fundamentos de Administración de Sistemas Linux 71


Comprobación de Conocimientos 4.1

Respuesta Correcta: SysVinit fue diseñado para mainframes, los que tienen
requerimientos diferentes a computadores de escritorio, sistemas embebidos y
plataformas para dispositivos móviles.

Respuesta Correcta:
 0
 6
 1
 3
 5

LFS201: Fundamentos de Administración de Sistemas Linux 72


4.14 Laboratorio 4.1
Laboratorio 4.1: Agregar un servicio de arranque nuevo con SysVinit

En este y el siguiente ejercicio crearemos un servicio simple de inicio. Primero lo haremos para un
sistema SysVinit. Tenga en cuenta que si está usando un sistema basado en systemd, todo debería
funcionar debido a la capa de compa/bilidad hacia atrás que todas las distribuciones /enen. Sin
embargo, lo haremos de forma na/va systemd en el próximo ejercicio.

Si está en un sistema basado en Debian como Ubuntu, asegúrese de tener instalados los paquetes
sysvinit-u/ls y chkcong. Sin embargo, las versiones recientes de Ubuntu ya no proveen el paquete
chkcon.g; en cambio, tendría que usar la herramienta update-rc.d.

Primero es necesario crear el script especí.co del servicio; usted lo puede crear por sí solo en caso
que lo desee, o u/lizar el procedimiento que se describe a con/nuación (como root). En este
úl/mo caso cree un archivo llamado /etc/init.d/fake_service con el siguiente contenido:
#!/bin/bash
# fake_service
# Starts up, writes to a dummy .le, and exits
#
# chkcon.g: 35 69 31
# descrip/on: This service doesn’t do anything.
# Source func/on library
. /etc/syscon.g/fake_service
case “$1” in
start) echo “Running fake_service in start mode...”
touch /var/lock/subsys/fake_service
echo “$0 start at $(date)” >> /var/log/fake_service.log
if [ ${VAR1} = “true” ]

then

echo “VAR1 set to true” >> /var/log/fake_service.log

.
echo
;;

stop)
echo “Running the fake_service script in stop mode...”
echo “$0 stop at $(date)” >> /var/log/fake_service.log
if [ ${VAR2} = “true” ]
then

echo “VAR2 = true” >> /var/log/fake_service.log

.
rm -f /var/lock/subsys/fake_service
echo

LFS201: Fundamentos de Administración de Sistemas Linux 73


;;
*)
echo “Usage: fake_service {start | stop}”
exit 1

esac
exit

Si está tomando la versión autodidacta en línea del curso, el script está disponible para descargarlo
desde la pantalla Lab.
Asígnele permisos de ejecución (y todos los otros permisos necesarios) al archivo anterior:
$ sudo chmod 755 /etc/init.d/fake_service
Se daría cuenta que el script incluye el archivo /etc/syscong/fake service. En sistemas diferentes
a RHEL debería cambiar esto a /etc/default/fake_service. Créelo e inserte el siguiente contenido:
VAR1=”true”
VAR2=”true”

Compruebe si el script funciona correctamente a través de los siguientes comandos:


$ sudo service fake_service
$ sudo service fake_service start
$ sudo service fake_service stop

Revise el archivo /var/log/fake service.log. ¿Qué con/ene?


Por diversión podría agregar modos adicionales al archivo de script como restart ;
eche un vistazo a otros scripts en el directorio para obtener ejemplos de lo que puede hacer.
Lo siguiente que necesitamos es que el servicio fake service se inicie cada vez que el sistema
arranque y se detenga cuando el sistema se apaga. Si usted hace:
$ sudo chkcon.g—list fake_service
obtendría un error debido a que aún el servicio no se ha con.gurado. Puede hacerlo de forma fácil
como sigue:
$ sudo chkcon.g—add fake_service
ahora puede habilitarlo y deshabilitarlo en el arranque (respec/vamente) de la siguiente forma:
$ sudo chkcon.g fake_service on
$ sudo chkcon.g fake_service od

Para probarlo completamente tendría que reiniciar el sistema con el .n de con.rmar si el servicio
inicia automá/camente. También puede modi.car los runlevels en los cuales el servicio debería
ejecutarse.

LFS201: Fundamentos de Administración de Sistemas Linux 74


4.14 Laboratorio 4.2
Laboratorio 4.2: Agregar un servicio de arranque nuevo con systemd

Como se mencionó en el ejercicio anterior, todavía es posible u/lizar el script de inicio SysVinit con
systemd, pero esto está en desuso.
El procedimiento análogo consiste en crear un archivo (como root) directamente bajo
/etc/systemd/system o en otro lugar en ese árbol de directorios; las distribuciones varían un poco
en esto. Este es un ejemplo de un archivo con contenido mínimo, llamado
/etc/systemd/system/fake2.service:
[Unit]
Descrip/on=fake2
ANer=network.target
[Service]
ExecStart=/bin/echo Estoy iniciando el servicio fake2
ExecStop=/bin/echo Estoy deteniendo el servicio fake2
[Install]
WantedBy=mul/-user.target

Existen muchas con.guraciones que se pueden realizar en el archivo unit. El parámetro


A7er=network.target signi.ca que el servicio debería ser iniciado sólo después de que la red lo
hizo, mientras que WantedBy=mul/-user.target signi.ca que debería iniciarse cuando se alcanzó el
modo mul/usuario. Esto es equivalente a runlevels 2 y 3 en SysVinit. Tenga en cuenta que
graphical.target se correlaciona con runlevel 5.
Cambie los permisos del archivo para hacerlo ejecutable:
$ chmod 755 /etc/systemd/system/fake2.service
Ahora lo único que tenemos que hacer es iniciar el servicio, comprobar su estado y detenerlo:
$ sudo systemctl start fake2.service
$ sudo systemctl status fake2.service
$ sudo systemctl stop fake2.service

Si usted hizo cambios a la sección unit, debe hacer lo siguiente para recargar el servicio con la
información nueva:
$ sudo systemctl daemon-reload y el sistema le mostraría una advertencia.

LFS201: Fundamentos de Administración de Sistemas Linux 75


Para habilitar/deshabilitar que el servicio inicie durante el arranque, puede usar los siguientes
comandos:
$ sudo systemctl enable fake2.service
$ sudo systemctl disable fake2.service

Una vez más, es necesario reiniciar el sistema para asegurarse que los cambios realizados están
siendo efec/vos.

Objetivos de aprendizaje (Revisión)

Usted debería ser capaz de:


 Comprender la importancia del proceso init.
 Explicar cómo funciona el método tradicional de SysVinit, cómo incorpora
los runlevels y lo que sucede en cada uno de ellos.
 Saber cómo usar chkconfig y service (y utilidades alternativas) para iniciar y
detener servicios, o hacerlos persistentes entre reinicios del sistema.
 Entender por qué surgieron los métodos alternativos Upstart y systemd y cómo
funcionan.
 Usar systemctl para configurar y controlar systemd.

LFS201: Fundamentos de Administración de Sistemas Linux 76


Capítulo 5. Diseño del Árbol del Sistema de
Archivos de Linux
Hay muchos tipos de archivos presentes en un sistema Linux. Se diferencian por su
propósito, tamaño, dueño, permisos para ser compartidos. Así mismo, por su
permanencia temporal o definitiva en el sistema. Debido a lo anterior, la organización
coherente de todo el árbol del sistema de archivos es muy importante, como también su
estandarización entre las distribuciones de Linux (en tanto sea posible).

Objetivos de aprendizaje

Al final de este capítulo usted debería estar capacitado para:


 Explicar por qué Linux requiere la organización de un gran árbol de sistemas de
archivos, y cuáles son las principales consideraciones de cómo hacerlo.
 Conocer el rol desempeñado por el Estándar de Jerarquía del Sistema de
Archivos (Filesystem Hierarchy Standard o FHS).
 Describir qué debe estar disponible en el arranque en el directorio raíz (/), y lo que
debe estar disponible una vez que el sistema ha iniciado.
 Explicar cada uno de los subdirectorios principales del árbol en términos de
propósito y contenido.

LFS201: Fundamentos de Administración de Sistemas Linux 77


5.1 Un sistema de archivos grande

Linux, como todos los sistemas operativos basados en UNIX, consiste en un árbol grande
de sistemas de archivos. Generalmente es diagramado como un árbol invertido con
el directorio raíz / en la parte superior del árbol.

Dentro de este tremendo sistema de archivos lógico pueden haber varios, incluso muchos
sistemas de archivos distintos, montados en puntos que corresponden a los
subdirectorios. Estos distintos sistemas de archivos suelen estar en particiones diferentes,
en diversas cantidades y tipos de dispositivos, incluyendo aquellos que se encuentran en
red.

De forma independiente de cómo exactamente las cosas están unidas entre sí, todo se ve
como un gran sistema de archivos; las aplicaciones no se preocupan en absoluto de los
dispositivos físicos en los cuales residen los archivos.

En el pasado los diferentes sistemas operativos tipo UNIX organizaron este gran árbol de
diversas maneras; incluso entre las distribuciones de Linux había muchas diferencias.
Esto hizo que tanto el desarrollo de aplicaciones como llevar a cabo tareas de
administración en más de un tipo de sistema fuera difícil y a menudo frustrante.

Como consecuencia de lo anterior, el ecosistema Linux ha trabajado arduamente para


establecer procedimientos estandarizados para minimizar esos inconvenientes.

5.2 Diferencia de los datos

Cuando se habla de cómo se organizan los archivos y datos en el gran árbol de


directorios, es importante conocer la taxonomía en cuánto a qué tipo de información tiene
que ser leída y cuál escrita. En particular, hay dos tipos de diferencias:
1. Compartidos vs no-compartidos
Los datos compartibles corresponden a los que se pueden compartir entre
diferentes máquinas. Los datos no compartibles son aquellos que son específicos
para un determinado host. Por ejemplo, los directorios personales de los usuarios
pueden ser compartibles, mientras que los archivos de bloqueo de dispositivos no
lo son.

2. Variable vs. Estático


Los archivos estáticos incluyen binarios, bibliotecas, documentación y todo lo que
no cambia sin ayuda del administrador de sistemas. Los archivos variables son
cualquier cosa que puede cambiar, incluso sin ayuda del administrador de
sistemas.

A menudo estas distinciones lógicas están incorporadas como distintos tipos de


información que residen en varios directorios, o incluso en particiones y sistemas de
archivos.

LFS201: Fundamentos de Administración de Sistemas Linux 78


5.3 FHS Estándar de Jerarquía del sistema de Archivos

El Estándar de Jerarquía del Sistema de Archivos (FHS, de Filesystem Hierarchy


Standard), administrado inicialmente por el Free Standards Group y ahora por la Linux
Foundation, especifica los directorios principales que deben estar presentes y describe
sus propósitos. Se puede descargar desde http://www.pathname.com/fhs/.

Al especificar un diseño estándar, el FHS simplifica el tema de la localización de los


archivos. Aunque la mayoría de las distribuciones de Linux respetan el FHS,
probablemente ninguno de ellos lo sigue exactamente. Por otro lado, la última versión
oficial no tiene en cuenta algunos desarrollos nuevos.
A las distribuciones les gusta probar diferentes cosas y eventualmente algunos de los
experimentos terminan siendo ampliamente aceptados.

5.4 Diseño del directorio principal

Los distribuidores de Linux pasan mucho tiempo asegurándose de que el diseño de su


sistema de archivos es coherente y que evoluciona correctamente en el tiempo.

LFS201: Fundamentos de Administración de Sistemas Linux 79


Es posible que haya directorios adicionales en el directorio raíz, específicos a cada
distribución. Estos podrían incluir/misc, que se puede utilizar para información de diverso
tipo y /tftpboot, que se utiliza para el inicio a través de tftp. En caso de haber archivos en
ese directorio, están relacionados con el inicio del sistema sin utilizar un disco duro. Note
que no viola la FHS el tener otros directorios; sin embargo, la norma es violada cuando se
tienen componentes en directorios distintos a los dictados por el estándar.

5.5 El directorio y sistema de archivos raíz (/)

Mientras que todo el sistema de archivos puede ser visto como un gran árbol, como
hemos señalado, pueden haber varias particiones y sistemas de archivos trabajando de
forma unida.

La partición y sistema de archivos en el cual el directorio raíz está contenido en es


bastante especial y a menudo está en una partición dedicada, con otros componentes con
directorios como /home, /var, /opt , etc, los cuales son montados posteriormente.

La partición raíz debe contener todos los archivos esenciales necesarios para iniciar el
sistema y luego montar el resto de los sistemas de archivos. Por lo tanto necesita
utilidades, archivos de configuración, información del cargador de arranque y otros datos
esenciales del inicio. Debe estar habilitado para:
 Iniciar el sistema.
 Restaurar el sistema desde copias de seguridad de medios externos, tales como
cintas y otros medios extraíbles, o NAS, etc.
 Recuperar y/o reparar el sistema; un administrador experimentado debe tener las
herramientas para diagnosticar y reconstruir un sistema dañado.

De acuerdo con el FHS, ninguna aplicación o paquete debería crear nuevos


subdirectorios en el directorio raíz.

5.6 /bin

El directorio /bin es muy importante y éste:


 Contiene programas y scripts ejecutables necesitados tanto por administradores
de sistemas y usuarios sin privilegios, que son necesarios cuando todavía no se
ha montado ningún otro sistema de archivos, por ejemplo, al iniciar en
modo monousuario o en modo de recuperación.
 También puede contener ejecutables que son utilizados indirectamente por scripts.
 No debe contener ningún subdirectorio.

LFS201: Fundamentos de Administración de Sistemas Linux 80


Los programas que deben existir en /bin incluyen:

cat, chgrp, chmod, chown, cp, date, dd, df, dmesg, echo,false, hostname, kill, ln, logi
n, ls, mkdir, mknod, more,mount, mv, ps, pwd, rm, rmdir, sed, sh, stty, su, sync, true
,umount, y uname.

También test puede estar ahí. De forma adicional puede incluirse:

csh, ed, tar, cpio, gunzip, zcat, netstat, y ping.

Los comandos binarios que no son considerados esenciales lo suficiente para ir


en /bin van en /usr/bin. Solamente los programas requeridos por los usuarios que no son
root se colocan en esta categoría.

Nota: Algunas distribuciones muy recientes están abandonando la estrategia de la


separación /bin y /usr/bin (como también /sbin y /usr/sbin) y solo tienen un directorio
con enlaces simbólicos, preservando así una visión de dos directorios. Consideran como
obsoleto el concepto tradicional de permitir la posibilidad de colocar /usr en una partición
separada para ser montada después del inicio.

5.7 /boot

Los archivos esenciales para iniciar el sistema deben estar en el directorio /boot y sus
subdirectorios. Los dos archivos absolutamente esenciales son:
 vmlinuz: El kernel Linux comprimido.
 initramfs: El sistema de archivos de RAM inicial, el cual se monta antes de que
el sistema real de archivos raíz esté disponible.

Estos archivos tienen nombres largos que dependen de la versión del núcleo, en donde el
nombre exacto está en función de la distribución de Linux. Además, en lugar
de initramfs, el archivo puede ser llamado initrd, siglas de disco RAM inicial, el cual si
bien es cierto corresponde al método antiguo, el nombre se usa en algunas distribuciones
todavía.
El contenido exacto de /boot variará según la distribución y el tiempo; en un
sistema RHEL 7 tenemos:
$ ls -lF /boot
total 135336
-rw-r—r-- 1 root root 122094 Nov 4 09:20 config-3.10.0-
123.13.1.el7.x86_64
-rw-r—r-- 1 root root 81386 Dec 7 12:03 config-3.17.5
-rw-r—r-- 1 root root 81896 Dec 15 07:28 config-3.18.0
-rw-r—r-- 1 root root 81896 Dec 16 15:56 config-3.18.1
drwxr-xr-x. 6 root root 4096 Dec 16 15:57 grub2
-rw-r—r--. 1 root root 40732911 Sep 3 04:07 initramfs-0-rescue-
3ª0cc7a6d7bb4525815f4d2b4298e611.img
-rw-r—r-- 1 root root 16406996 Dec 10 07:25 initramfs-3.10.0-
123.13.1.el7.x86_64.img
-rw-r—r-- 1 root root 13967066 Dec 7 12:03 initramfs-3.17.5.img

LFS201: Fundamentos de Administración de Sistemas Linux 81


-rw-r—r-- 1 root root 13914297 Dec 15 07:28 initramfs-3.18.0.img
-rw-r—r-- 1 root root 13915331 Dec 16 15:56 initramfs-3.18.1.img
-rw-r—r--. 1 root root 865512 Sep 3 04:06 initrd-plymouth.img
-rw-r—r-- 1 root root 228603 Nov 4 09:23 symvers-3.10.0-
123.13.1.el7.x86_64.gz
lrwxrwxrwx 1 root root 24 Sep 28 10:18 System.map ->
/boot/System.map-3.15.0+
-rw------- 1 root root 2841409 Nov 4 09:20 System.map-3.10.0-
123.13.1.el7.x86_64
-rw-r—r-- 1 root root 2875608 Dec 7 12:03 System.map-3.17.5
-rw-r—r-- 1 root root 2891484 Dec 15 07:28 System.map-3.18.0
-rw-r—r-- 1 root root 2891509 Dec 16 15:56 System.map-3.18.1
lrwxrwxrwx 1 root root 21 Sep 28 10:18 vmlinuz -> /boot/vmlinuz-
3.15.0+
-rwxr-xr-x. 1 root root 4902000 Sep 3 04:07 vmlinuz-0-rescue-
3ª0cc7a6d7bb4525815f4d2b4298e611
-rwxr-xr-x 1 root root 4904592 Nov 4 09:20 vmlinuz-3.10.0-
123.13.1.el7.x86_64
-rw-r—r-- 1 root root 5363200 Dec 7 12:03 vmlinuz-3.17.5
-rw-r—r-- 1 root root 5404992 Dec 15 07:28 vmlinuz-3.18.0
-rw-r—r-- 1 root root 5405440 Dec 16 15:56 vmlinuz-3.18.1

Hace mucho tiempo estos archivos esenciales se solían poner directamente en /, en vez
de usar un directorio /boot por separado, siguiendo las prácticas tradicionales de UNIX.
Hoy en día esto se considera obsoleto.

5.8 Otros archivos y directorios en /boot

Usted puede haber notado que existen varias versiones del núcleo en /boot, y para cada
uno hay cuatro archivos disponibles (la posibilidad de elegir entre los núcleos se hace
mediante GRUB en el inicio).

Los otros dos archivos además de vmlinuz y initramfs son:


 config: Es el archivo de configuración utilizado al compilar el kernel. Está presente
sólo para referencia y porque puede ser de utilidad al depurar programas.

 System.map: La tabla de símbolos del kernel, la cual es muy útil en la depuración


de programas. Entrega las direcciones hexadecimales de todos los símbolos del
kernel.

Ninguno de estos archivos es requerido para iniciar o ejecutar el sistema.

Las distribuciones pueden poner otros archivos y directorios en /boot, tales como los
sectores de arranque maestros guardados y otros datos no editados a mano.

LFS201: Fundamentos de Administración de Sistemas Linux 82


5.9 /dev

Este directorio contiene archivos de dispositivos especiales (también conocidos


como nodos de dispositivo) los cuales representan los dispositivos incorporados o
conectados al sistema. Estos archivos especiales son esenciales para que el sistema
funcione correctamente.

Dichos archivos de dispositivo representan caracteres (una trama de bytes)


y dispositivos de bloque E/S. Los dispositivos de red no tienen nodos de dispositivo
en Linux y en cambio son referenciados por su nombre, como eth1 owlan0.

Listado de /dev
$ cd /dev ; ls -lF
lrwxrwxrwx 1 root root 3 Aug 28 10:12 cdrom1 -> sr0
....
lrwxrwxrwx 1 root root 15 Aug 28 10:12 fitbit -> bus/usb/003/002
....
crw-rw---- 1 root lp 6, 0 Aug 28 10:12 lp0
crw-rw---- 1 root lp 6, 1 Aug 28 10:12 lp1
....
brw-rw---- 1 root disk 8, 4 Aug 28 10:12 sda4
brw-rw---- 1 root disk 8, 5 Aug 28 10:12 sda5
brw-rw---- 1 root disk 8, 6 Aug 28 10:12 sda6
....
brw-rw----+ 1 root cdrom 11, 0 Aug 28 10:12 sr0

Note que los dispositivos de carácter comienzan con una c, los bloques con una b y los
enlaces simbólicos con una l (L minúscula).

Todas las distribuciones modernas de Linux (no embebidas) utilizan el sistema udev, el
cual crea nodos en /dev sólo a medida en que se necesita, lo que sucede cuando se
encuentran dispositivos, ya sea al inicio o al conectarlos al sistema (discutiremos udev en
una sección posterior).

Si usted fuera a echar un vistazo en el directorio /dev en un sistema de archivos sin


montar, lo encontraría vacío; en el inicio se crea y monta un sistema de archivos virtual
en /dev, el que luego es populado con nodos de dispositivos, como lo requiere udev. Los
sistemas Linux embebidos pueden fijar los nodos de dispositivos y no utilizar udev o
alguna alternativa como mdev.

LFS201: Fundamentos de Administración de Sistemas Linux 83


5.10 /etc

Este directorio contiene los archivos de configuración de la máquina local y algunos


scripts de inicio; aquí no debería haber ningún programa ejecutable binario.
Los archivos y directorios que pueden encontrarse aquí incluyen:

csh.login, exports, fstab, ftpusers, gateways, gettydefs, group, host.conf,


hosts.allow, hosts.deny, hosts,equiv, hosts.lpd, inetd.conf, inittab, issue,
ld.so.conf, motd, mtab, mtools.conf, networks, passwd, printcap, profile,
protocols, resolv.conf, rpc, securetty, services, shells, syslog.conf.

Las distribuciones a menudo agregan archivos de configuración y directorios a /etc. Por


ejemplo, Red Hat añade un número directorios adicionales incluyendo /etc/sysconfig,
donde se alojan archivos y directorios de configuración del sistema.

Otros subdirectorios importantes incluyen /etc/skel, que contiene archivos de plantilla


usados para popular directorios de usuario recién creados. También /etc/init.d, que
contiene scripts de inicio y detención cuando se utiliza la inicialización de System V.

5.11 /home
En los sistemas Linux los directorios de usuarios están en /home,
como /home/coop, /home/alumno, etc. Toda la configuración personal, datos y programas
ejecutables se ponen en esta jerarquía de directorios. /home también puede contener
subdirectorios para varios grupos o asociaciones de usuarios,
como /home/estudiantes, /home/staff,/home/aliens, etc.

En otros sistemas operativos tipo UNIX, existe el concepto del árbol de directorios /home,
pero puede ser sutilmente diferente. Por ejemplo, en Solaris los directorios de usuarios se
crean en /export/home y luego la utilidad automount los montará en /home. Esto se
debe a la situación habitual en que el directorio de los usuarios puede estar en cualquier
lugar en una red corporativa, probablemente en un servidor NFS, en donde el directorio
de cada usuario se montará automáticamente cuando esté en uso.

Linux también tiene la utilidad automount, pero muchos usuarios no están conscientes
de ellos, y en sistemas personales probablemente el concepto de puntos de
montaje NFS no aplicará.
Un usuario siempre puede sustituir la variable de ambiente $HOME para su directorio raíz, o
la abreviación ~; es decir, los siguientes usos son equivalentes:

$ ls -l $HOME/public_html
$ ls -l ~/public_html

Hay una excepción: el directorio home del usuario root en los sistemas Linux siempre se
encuentra en /root. Algunos sistemas UNIX antiguos pueden usar / en cambio, lo que
puede causar algún desorden.

LFS201: Fundamentos de Administración de Sistemas Linux 84


5.12 /lib

Este directorio debe contener sólo las bibliotecas necesarias para ejecutar los binarios
en /bin y /sbin. Estas bibliotecas son particularmente importantes para iniciar el sistema
y ejecutar comandos en el sistema de archivos raíz.

Los módulos del kernel (a menudo controladores de dispositivo o sistemas de archivos) se


encuentran bajo/lib/modules/<kernel-versión-número>.
Los archivos de PAM (Pluggable Authentication Modules) se almacenan en el
directorio /lib/security.

Los sistemas que soportan tanto binarios de 32 bits y 64 bits deben mantener ambos tipos
de bibliotecas en el sistema. En los sistemas basados en Red Hat hay directorios
separados para las bibliotecas de 32 bits (/lib) y 64 bits (/lib64).

5.13 /media

Este directorio se usa normalmente para montar sistemas de archivos en medios


extraíbles. Estos incluyen CDs, DVDs, unidades USB y disquetes del paleolítico.

Los sistemas Linux modernos montan estos medios de forma dinámica durante la
inserción, momento en el cual udev crea directorios bajo /media y luego monta los
sistemas de archivos extraíbles allí, con los nombres que se establecen a través de las
reglas de udev especificadas en los archivos de configuración. Al desmontar y extraer los
medios, los directorios que fueron usados como puntos de montaje
en /media desaparecerán.

Si el medio extraíble tiene más de una partición y sistema de archivos, aparecerá más de
una entrada en /media. En muchas distribuciones de Linux el administrador de archivos
(como Nautilus) se abrirá cuando el medio es montado.

Nota: En algunas distribuciones más recientes (incluyendo SUSE y RHEL 7) los medios
extraíbles se montarán en/run/media/[nombre de usuario]/... Vamos a tratar /run al
final de este capítulo.

LFS201: Fundamentos de Administración de Sistemas Linux 85


5.14 /mnt

Se dispone de este directorio para que el administrador del sistema pueda montar
temporalmente un sistema de archivos en caso de necesitarlo. Se usa comúnmente para
sistemas de archivos en red, incluyendo:
 NFS
 Samba
 CIFS
 AFS

Históricamente, /mnt también fue usado para los tipos de archivos que se montan
actualmente en /media (o/run/media) en los sistemas modernos.
En términos generales, este directorio no debe ser utilizado por programas de instalación.
Una mejor alternativa es otro directorio temporal que no esté siendo usado.

5.15 /opt

Este directorio está diseñado para paquetes de software que desean mantener la totalidad
o gran parte de sus archivos en un lugar aislado en vez de dispersarse por todo el sistema
en los directorios compartidos con otros programas.

Por ejemplo, si dolphy_app fuera el nombre de un paquete en /opt, todos sus archivos
deben residir en directorios bajo /opt/dolphy_app, incluyendo
/opt/dolphy_app/bin para binarios y /opt/dolphy_app /man para las páginas man.
Esto puede hacer que tanto la instalación y desinstalación de software sean relativamente
fácil, ya que todo está aislado de forma conveniente en una ubicación predecible y
estructurada. También hace que sea más fácil para los administradores de sistemas el
determinar la naturaleza de cada archivo asociado a un paquete.

Note, sin embargo, que si uno utiliza sistemas de empaquetamiento como RPM y APT,
como veremos más adelante, también es fácil de instalar y desinstalar conservando un
claro sentido de las ubicaciones de archivos, sin exhibir tal conducta antisocial con la
distribución.
En Linux, el directorio /opt es utilizado a menudo por proveedores de aplicaciones, ya
sea con software propietario o aquellos que desean evitar las complicaciones asociadas a
los cambios entre distribuciones. Por ejemplo, en RHEL 7 los únicos paquetes se
encuentran en esta categoría están en /opt/skype y /opt/google, en donde este último
tiene subdirectorios para chrome, earth y talkplugin.

Los directorios /opt/bin, /opt/doc, /opt/include, /opt/info,/opt/lib


y /opt/man están reservados para uso del administrador del sistema local. Los paquetes
pueden proporcionar archivos que estén vinculados o copiados en estos directorios
reservados, pero también deben ser capaces de funcionar sin los programas que están en
estos directorios especiales.

LFS201: Fundamentos de Administración de Sistemas Linux 86


5.16 /proc

Este directorio es el punto de montaje para un seudosistema de archivos, donde toda la


información reside sólo en memoria, no en disco. Tal como /dev, el directorio /proc está
vacío en un sistema que no está corriendo.

El kernel muestra algunas estructuras de datos importantes a través de las entradas


disponibles en /proc. Además, cada proceso activo en el sistema tiene su propio
subdirectorio, el que ofrece información detallada sobre el estado del proceso, los
recursos que está utilizando y su historia.

Las entradas en /proc a menudo se denominan archivos virtuales y tienen cualidades


interesantes. Mientras que la mayoría tienen cero bytes de tamaño, cuando se visualiza
su contenido es posible comprobar que pueden tener una gran cantidad de información.
Adicionalmente, la mayoría de los ajustes de hora y fecha en los archivos reflejan la hora
y fecha actuales, indicativo del hecho de que están en constante cambio. De hecho, la
información de estos archivos se obtiene sólo cuando son visualuzados, no se están
actualizando constantemente o periódicamente.

Importantes pseudoarchivos, incluyendo


/proc/interrupts, /proc/meminfo, /proc/mounts y /proc/partitions, proporcionan
un vistazo del estado actual del hardware del sistema.

Otros archivos como /proc/filesystems y el directorio /proc/sys/, proveen


información de configuración del sistema y de las interfaces.

Para propósitos de organización, los archivos que contienen información sobre un tema
similar se agrupan en directorios virtuales y subdirectorios. Por
ejemplo, /proc/scsi/ contiene información de todos los dispositivos SCSI físicos. De la
misma forma, los directorios de procesos contienen información acerca de
cada proceso corriendo en el sistema.

A lo largo de este curso examinaremos ampliamente las entradas en /proc, y echaremos


un vistazo más detallado en los capítulos siguientes acerca de la configuración del kernel
y monitoreo del sistema.

LFS201: Fundamentos de Administración de Sistemas Linux 87


5.17 /root

Este directorio (pronunciado “slash-root”) es el directorio de inicio para el usuario root.


La cuenta de root que es dueña de este directorio se debe utilizar solamente para las
acciones que requieren privilegios de superusuario. Para aquellas acciones que pueden
realizarse como un usuario sin privilegios, utilice otra cuenta.

5.18 /sys

Este directorio es el punto de montaje para el seudosistema de archivos sysfs, donde


toda la información reside sólo en memoria, no en disco. Al igual que /dev y /proc, el
directorio /sys está vacío en un sistema detenido.

sysfs se utiliza tanto para recopilar información sobre el sistema, como también modificar
su comportamiento mientras se ejecuta. En ese sentido se parece a /proc, pero es más
nuevo y se ha adherido a normas estrictas acerca de qué tipo de entradas que puede
contener. Por ejemplo, casi todos los seudoarchivos en /sys contienen sólo una línea o
valor; no existe ninguna de las entradas largas que se pueden encontrar en /proc.

Al igual que con /proc, examinaremos entradas en /sys a lo largo de este curso, lo que
será relevante en los próximos capítulos acerca de la configuración del kernel y monitoreo
del sistema.

5.19 /sbin

Este directorio contiene los archivos binarios esenciales para arrancar, restaurar,
recuperar y/o reparar los binarios en el directorio /bin. También debe tener lo necesario
para montar otros sistemas de archivos en /usr, /home y otros lugares de ser necesario,
una vez que el sistema de archivos raíz esté en buenas condiciones en el arranque.

Los siguientes programas deberían estar incluidos en este directorio (siempre y cuando
sus subsistemas estén instalados):

fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff,
update.

Nota: como se mencionó anteriormente, algunas distribuciones nuevas están


abandonando la estrategia de separar/sbin y /usr/sbin (como
también /bin y /usr/bin), y sólo tienen un directorio con enlaces simbólicos,
preservando una vista de dos directorios.

LFS201: Fundamentos de Administración de Sistemas Linux 88


5.20 /tmp

Este directorio se utiliza para almacenar archivos temporales, y puede ser accedido por
cualquier usuario o aplicación. Sin embargo, no se puede esperar que los archivos
en /tmp estén ahí por largo tiempo:
 Algunas distribuciones corren trabajos de cron automatizados, los que
generalmente eliminan los archivos de más 10 días, a menos que los scripts de
purga hayan sido modificado para excluirlos. Esta es la política de RHEL 6.
 Algunas distribuciones eliminan el contenido de /tmp con cada reinicio del sistema.
Esta ha sido la política de Ubuntu.
 Algunas distribuciones modernas utilizan un sistema de archivos virtual, usando el
directorio /tmp sólo como un punto de montaje para un disco ram utilizando el
sistema de archivos tmpfs. Esta es la política por defecto de los
sistemas Fedora recientes. Cuando el sistema se reinicia, toda la información se
pierde; ¡/tmp es de hecho temporal!

En este último caso, hay que evitar la creación de archivos de gran tamaño en /tmp,
debido a que en realidad va a ocupar espacio en memoria en vez de disco, y es fácil
dañar o bloquear el sistema a través del agotamiento de la memoria. Si bien es cierto que
la guía para las aplicaciones es evitar poner archivos de gran tamaño en /tmp, hay un
gran número de aplicaciones que violan esta política. Incluso si fuera posible ponerlos en
otro lugar (tal vez mediante la especificación de una variable de entorno), muchos
usuarios no saben cómo configurarlo, y por otro lado, todos los usuarios tienen acceso
a /tmp.
Esta política puede ser cancelada en los sistemas utilizando systemd, como en Fedora, a
través del siguiente comando:

$ systemctl mask tmp.mount

Luego de lo cual es necesario reiniciar el sistema.

5.21 /usr

El directorio /usr puede ser visto como una jerarquía secundaria. Se utiliza para los
archivos que no son necesarios para el inicio del sistema. De hecho, /usr no necesita
estar localizado en la misma partición que el directorio raíz y se puede compartir entre los
hosts que utilizan la misma arquitectura de sistema a través de la red.

Los paquetes de software no deberían crear subdirectorios directamente bajo /usr.


Podrían existir algunos enlaces simbólicos a otros lugares por razones de compatibilidad.

Este directorio tiene usualmente datos de sólo lectura. Contiene binarios que no son
necesarios en modo monousuario. Contiene el directorio /usr/local, donde es posible
almacenar binarios locales. Las páginas man se encuentran en/usr/share/man.

LFS201: Fundamentos de Administración de Sistemas Linux 89


5.22 /var

Este directorio contiene archivos de datos variables (o volátiles) que cambian


frecuentemente durante el funcionamiento del sistema. Estos incluyen:
 Archivos de registro.
 Directorios y archivos de spool para imprimir, colas de correo, etc.
 Archivos de datos administrativos.
 Archivos transitorios y temporales, como contenido del caché.

Obviamente, /var no puede ser montado como un sistema de archivos de sólo lectura.
Por razones de seguridad, a menudo se considera una buena idea montar /var como un
sistema de archivos por separado. Además, si el directorio se llena, no debería producir
un bloqueo del sistema.
/var/log es donde se encuentran la mayoría de los archivos del registro del sistema. El
directorio /var/spool es donde se almacenan los archivos locales para procesos como
correo, impresión y trabajos de cron a la espera de ser liberados de la cola.

LFS201: Fundamentos de Administración de Sistemas Linux 90


5.23 /run

Un nuevo árbol de directorio montado en /run ha estado en uso desde hace varios años
por las principales distribuciones de Linux, y pese a que ha sido propuesto para el FHS,
no ha sido aceptado formalmente. Sin embargo es bueno saber acerca de su existencia,
ya que muy probablemente se encontrará con él.

El propósito de /run es almacenar archivos transitorios: aquellos que contienen


información del tiempo de ejecución (runtime), los cuales probablemente sean escritos
tempranamente en el inicio del sistema, y que no requieren ser preservados al reiniciar.
Generalmente /run se implementa como un punto de montaje vacío, con un disco
ram tmpfs (tal como /dev/shm) montado en tiempo de ejecución. Por lo tanto, este es un
seudosistema de archivos existente sólo en memoria.

Algunos directorios existentes, tal como /var/run y /var/lock, serán enlaces simbólicos
a los directorios bajo /run. Otros, dependiendo de cada distribución, pueden apuntar a
directorios bajo /run.

Comprobación de conocimientos 5.1

LFS201: Fundamentos de Administración de Sistemas Linux 91


Comprobación de conocimientos 5.2

5.24 Laboratorio 5.1


Laboratorio 5.1: Tamaños de los directorios de Linux por defecto

Use la herramienta du para calcular el tamaño total de cada uno de los directorios de primer nivel
de su sistema.

Ejecute el comando:
$ du—help

para tener una idea de cómo obtener y mostrar la información de forma e.ciente.
Solución lab 5.1
Para obtener una lista completa de los directorios principales bajo / y sus tamaños:
$ sudo du—max-depth=1 -hx /
4.3M /home
16K /lost+found
39M /etc
4.0K /srv
3.6M /root
178M /opt
138M /boot
6.1G /usr
1.1G /var
16K /mnt
4.0K /media
869M /tmp
8.4G /

LFS201: Fundamentos de Administración de Sistemas Linux 92


Donde hemos usado las siguientes opciones:
• --maxdepth=1: Baja un nivel solamente desde / y suma recursivamente todo lo que hay bajo ese
árbol.
• -h: Provee números legibles para humanos (KB, MB, GB).
• -x Permanezca en un sistema de archivos; no busque directorios que no están en la par/ción /.
En este caso
signi.ca ignorar:
/dev /proc /run /sys
debido a que son seudosistemas de archivos que existen en memoria solamente; de hecho cuando
el sistema no está corriendo son puntos de montaje vacíos. Debido a que este es un sistema RHEL
7, los siguientes puntos de montaje tampoco son tomados en cuenta:
/bin /sbin /lib /lib64

ya que son sólo enlaces simbólicos a sus contrapartes bajo /usr.

LFS201: Fundamentos de Administración de Sistemas Linux 93


5.24 Laboratorio 5.2
Laboratorio 5.2: Un recorrido del sistema de archivos /proc
Lo que usted verá exactamente en este ejercicio dependería de la versión del kernel que esté
usando, por lo cual la salida que obtenga en los comandos podría diferir un poco.
1. Como root, haga cd en /proc y liste lis archivos. Esto debería desplegar un número de archivos y
directorios:
$ cd /proc
$ ls –F

Tenga en cuenta que muchos de los nombres de los directorios son números; cada uno
corresponde a un proceso en ejecución y sus nombres son el process ID. Un subdirectorio
importante que veremos más adelante es /proc/sys, bajo el cual es posible ver o modi.car muchos
parámetros del sistema.

LFS201: Fundamentos de Administración de Sistemas Linux 94


2. Vea el contenido de los siguientes archivos:
 /proc/cpuinfo:
 /proc/meminfo:
 /proc/mounts:
 /proc/swaps:
 /proc/version:
 /proc/par//ons:
 /proc/interrupts:

Los nombres de cada uno dan una buena idea acerca de la información que con/enen.
Tenga en cuenta que esta información no se actualiza de forma constante, sino que es obtenida
sólo cuando uno quiere visualizarla.
3. Eche un vistazo a cualquier directorio de proceso. Si no es un proceso del cual usted es dueño, el
acceso a la información podría ser limitada, a menos que use sudo):
$ ls -F 5564

Eche un vistazo a algunos de los campos aquí, tales como cmdline, cwd, environ, mem, y status

LFS201: Fundamentos de Administración de Sistemas Linux 95


Objetivos de aprendizaje (revisión)

Usted debería ser capaz de:


 Explicar por qué Linux requiere que su árbol de sistemas de archivos esté
organizado, y cuáles son las consideraciones más importantes en relación a cómo
hacerlo.
 Saber cuál es el rol que juega el Estándar de jerarquía del sistema de archivos
(FHS).
 Describir qué debe estar disponible durante el inicio en el directorio raíz (/) , y qué
debe estar disponible una vez que el sistema ya se haya iniciado.
 Explicar cada uno de los principales subdirectorios del árbol en términos de
propósito y contenido.

LFS201: Fundamentos de Administración de Sistemas Linux 96


Capítulo 6. Servicios del Kernel y Configuración
El kernel del sistema operativo se encuentra en el corazón de todos los sistemas Linux,
desde el dispositivo embebido o móvil más pequeño, a la supercomputadora más
poderosa. Cabe destacar que el kernel tiene las mismas tareas esenciales en este amplio
espectro. Controla el acceso al hardware, la competencia por los recursos entre diferentes
aplicaciones y otras tareas, maneja la actividad de E/S, los archivos y almacenamiento de
datos, seguridad, redes, etc. Al seleccionar los parámetros de línea de comandos del
kernel en el inicio, el sistema puede comportarse de diferentes formas.

Objetivos de Aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Conocer las principales responsabilidades que el kernel debe cumplir y saber
cómo lo hace.
 Explicar qué parámetros pueden ser configurados en la línea de comandos del
kernel y cómo hacerlos efectivos, ya sea para un sólo inicio del sistema o de forma
persistente.
 Saber en dónde encontrar documentación detallada acerca de estos parámetros.

 Saber cómo usar sysctl para configurar parámetros del kernel ya sea una vez que
el sistema ha iniciado, o de forma persistente luego del reinicio del sistema.

LFS201: Fundamentos de Administración de Sistemas Linux 97


6.1 Información General del Kernel

En rigor, Linux es sólo el kernel del sistema operativo. Este último incluye muchos otros
componentes, como bibliotecas y aplicaciones que interactúan con el kernel.

El kernel es el componente central esencial que conecta el hardware al software y maneja


recursos del sistema, como memoria y asignación de tiempo de CPU a las aplicaciones y
servicios que compiten por ellos. Se ocupa de todos los dispositivos conectados utilizando
los controladores de dispositivos, y hace que estén disponibles para el uso del sistema
operativo.

Un sistema que ejecuta solamente el kernel tiene una funcionalidad bastante limitada.
Esto se encuentra sólo en dispositivos dedicados y enfocados a los sistemas
embebidos.

6.2 Tareas Principales del Kernel

Las principales responsabilidades del kernel incluyen:


 Inicialización del Sistema y booteo.
 Planificación de procesos.
 Gestión de Memoria.
 Controlar acceso al hardware.
 E/S (Entrada/Salida) entre aplicaciones y dispositivos de almacenamiento.
 Implementación de sistemas de archivos locales y de red.
 Control de seguridad, tanto a nivel local (como los permisos del sistema de
archivos) y en red.
 Control de la red.

6.3 Línea de comandos del Kernel

Varios parámetros son pasados al sistema durante el inicio a través de la línea de


comandos del kernel. Normalmente están en la línea del kernel (o linux16) en el archivo
de configuración de GRUB, pero pueden ser modificados en el inicio.

LFS201: Fundamentos de Administración de Sistemas Linux 98


Para la versión GRUB 1 (la antigua), una línea de comandos del kernel podría verse así:
kernel /boot/vmlinuz-3.19.1 ro root=LABEL=RHEL6-64 quiet crashkernel=auto
SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us

o
kernel /vmlinuz-2.6.32-279.14.1.el6.x86_64 ro
root=UUID=178d0092-4154-4688-af24-cda272265e08
rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD
SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc

KEYTABLE=us rd_NO_DM rhgb quiet

y se encontraría en /boot/grub/grub.conf. Todo lo que viene después del archivo que se


especifica en vmlinuz es una opción. Cualquier opción que no es comprendida por el
kernel se pasará a init (pid = 1), el primer proceso de usuario que se ejecuta en el
sistema.

Para la versión GRUB 2 (la nueva), una línea de comandos del kernel podría verse así:
linux16 /boot/vmlinuz-3.16.0 root=UUID=178d0092-4154-4688-af24-
cda272265e08 ro vconsole.keymap=us crashkernel=auto
vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8

y se encontraría en /boot/grub2/grub.cfg.
En la versión 2 no se debe editar este archivo directamente, sino que modificar los
archivos relevantes bajo /etc.

En los ejemplos anteriores las filas largas fueron divididas para su visualización, pero
cada una de ellas corresponden a una línea larga. Recuerde que discutimos cómo
configurar las dos versiones de GRUB, y que la versión 2 no debe editarse directamente,
sino modificar los archivos correspondientes en /etc.

Basta hacer lo siguiente para ver con qué línea de comandos inició un sistema:
$ cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-3.18.1 root=UUID=9d6b5801-9c7e-4c17-9068-
49923952338e ro rhgb quiet loop.max_loop=256 LANG=en_US.UTF-8

LFS201: Fundamentos de Administración de Sistemas Linux 99


6.4 Parámetros de Inicio del Kernel

Hay una lista sorprendentemente larga de los parámetros disponibles del kernel.
Documentación detallada al respecto se puede encontrar aquí:

 En las fuentes del kernel, en el archivo Documentation/kernel-parameters.txt.

 En línea, en http://kernel.org/doc/Documentation/kernel-parameters.txt.

 En el paquete de documentación del kernel proveído por la mayoría de las


distribuciones, con un nombre similar a kernel-doc o linux-doc.

 Ejecutando el comando man bootparam.

Los parámetros pueden ser especificados simplemente como un valor dado como
argumento, o de la forma param=valor, donde el valor dado puede ser un string, entero,
arreglo de enteros, etc, tal como se explica en el archivo de documentación.
Por convención, no debería haber parámetros intencionalmente escondidos o secretos,
todos ellos deberían estar explicados en la documentación. Los parches a las fuentes del
kernel con parámetros nuevos deben incluir modificaciones en el archivo de
documentación.

Aquí puede ver el significado de alguno de los parámetros de arranque mencionados:

 ro: monta el directorio raíz en modo sólo-lectura en el inicio.


 root: sistema de archivos raíz.
 rd_LVM_LV: activa el sistema de archivos root en el volumen lógico especificado.
 rd_NO_LUKS: deshabilita la detección de cifrado LUKS.
 rd_NO_DM: deshabilita la detección de DM RAID.
 LANG: es el lenguaje del sistema.
 SYSFONT: es la fuente de consola.
 KEYTABLE: es el nombre del archivo de configuración del teclado.
 rhgb: para soporte de booteo gráfico en sistemas Red Hat.
 quiet: deshabilita la mayoría de los mensajes del registro.

Tenga en cuenta que los parámetros que comienzan con rd se usan solamente en los
sistemas basados en Red Hat. Alguna documentación al respecto puede encontrarse
en https://fedoraproject.org/wiki/Dracut/Options.

LFS201: Fundamentos de Administración de Sistemas Linux 100


6.5 sysctl

La interfaz sysctl puede ser utilizada para leer y ajustar los parámetros del kernel en
tiempo de ejecución. Los valores actuales se pueden visualizar con el siguiente comando:
$ sysctl -a
....
kernel.pid_max = 32768
...
kernel.threads-max = 63707
....
net.ipv4.ip_default_ttl = 64
....
net.ipv4.ip_forward = 0
....
vm.nr_hugepages = 16
vm.swappiness = 10
....

Cada valor corresponde a un seudoarchivo en particular bajo /proc/sys, en donde las


diagonales son reemplazadas por puntos. Por ejemplo, las dos siguientes sentencias son
equivalentes:

$ sudo sh -c ‘echo 1 > /proc/sys/net/ipv4/ip_forward’


$ sudo sysctl net.ipv4.ip_forward=1

donde la segunda forma se usa para establecer un valor con la interfaz de línea de
comando sysctl. No se puede dejar espacios alrededor del signo = en este comando.
Note que en la primera forma, no es posible utilizar sudo con echo; el comando debe
hacerse en la forma en que se muestra, o ejecutándolo como root.

Si va a través de los seudoarchivos en /proc/sys va a obtener la misma información que


provee sysctl -a. Puede obtener todos los detalles sobre cómo utilizar sysctl con man 8
sysctl. Para obtener información acerca de cómo se usa la función sysctl() desde un
programa para realizar las mismas operaciones, ejecute man 2 sysctl.

Si la configuración está en /etc/sysctl.conf (ver man sysctl.conf para más detalles),


es posible realizar ajustes en el inicio del sistema.
Note que el comando:

$ sudo sysctl -p

lleva a cabo de forma inmediata lo que se encuentra en el archivo de configuración,


ajustando todos los parámetros según se haya especificado; esto también es parte del
proceso de inicio.
En algunas distribuciones recientes basadas en systemd (como en RHEL 7), el archivo
de configuración es ahora/usr/lib/sysctl.d/00-system, pero el archivo original está
soportado todavía, ya que está autodocumentado en ese archivo.

LFS201: Fundamentos de Administración de Sistemas Linux 101


Comprobación de Conocimientos 6.1

6.6 Laboratorio 6.1


Laboratorio 6.1: Ajustes del sistema con sysctl

1. Veri.que si puede hacer ping a su sistema. Tenga en cuenta que en RHEL 7 es necesario ser
root para hacer ping en la mayoría de redes externas.
2. Veri.que el valor actual de net.ipv4.icmp_echo_ignore_all, el cual se usa para habilitar y
deshabilitar que su sistema responda a ping. El valor 0 permite a su sistema responder a
pings.
3. Con.gure el valor en 1 usando la herramienta de línea de comandos sysctl y luego veri.que
si el sistema dejó de responder a pings.
4. Con.gure el valor de vuelta a 0 y con.rme si se restauró el comportamiento original.
5. Ahora modi.que el valor a través de la edición de /etc/sysctl.conf y fuerce al sistema a
ac/var esa con.guración en el archivo sin reiniciar el sistema.
6. Veri.que que la modi.cación esté funcionando correctamente. Una vez que haya terminado,
puede reiniciar su sistema para asegurarse que todo está de vuelta en el punto original.

LFS201: Fundamentos de Administración de Sistemas Linux 102


Solución 6.1
Usted puede usar ya sea localhost o 127.0.0.1 (loopback) o la dirección IP actual del sistema como
objeto de prueba para el ping de a con/nuación.
1. $ ping localhost
2. $ sysctl net.ipv4.icmp_echo_ignore_all
3. $ sudo sysctl net.ipv4.icmp_echo_ignore_all=1
$ ping localhost
4. $ sudo sysctl net.ipv4.icmp_echo_ignore_all=0
$ ping localhost
5. Agregue la línea siguiente a /etc/sysctl.conf:

net.ipv4.icmp_echo_ignore_all=1
y luego haga:
$ sysctl -p

6. $ sysctl net.ipv4.icmp_echo_ignore_all
$ ping localhost

Ya que los cambios en el archivo /etc/sysctl.conf son persistentes, sería buena idea restaurar los
valores originales.

6.6 Laboratortio 6.2


Laboratorio 6.2: Modicar el ID de proceso máximo - maximum process ID

El comportamiento normal de un sistema Linux es que los IDs de proceso comiencen en PID=1
para el proceso init, el primer proceso en el sistema, y luego en forma secuencial a medida en que
procesos nuevos van siendo creados y terminados (de forma constante).

Sin embargo, cuando el PID alcanza el valor especi.cado en /proc/sys/kernel/pid_max, el cual es


generalmente 32768 (32K), se intentará u/lizar números bajos. Si no hay más números disponibles
no hay nada que hacer, ya que no es posible tener más de 32K procesos en el sistema (ese es el
número máximo para los PIDs).
1. Obtenga el valor actual del PID máximo.
2. Averigue cuáles son los PIDs que está siendo creados actualmente.
3. Con.gure pid_max a un valor menor.
4. Inicie un proceso y vea qué valor de PID se le asigna.

LFS201: Fundamentos de Administración de Sistemas Linux 103


Solución 6.2
A con/nuación vamos a usar dos métodos; uno usando sysctl, el otro escribiendo valores
directamente con echo a /proc/sys/kernel/pid_max. Note que el método echo require ser root,
sudo no funcionará. Dejaremos que usted descubra porqué, en caso que no lo sepa todavía.
1. $ sysctl kernel.pid_max
$ cat /proc/sys/kernel/pid_max
2. Escriba:
$ cat &
[1] 29222
$ kill -9 29222

3. $ sudo sysctl kernel.pid_max=24000


$ echo 24000 > /proc/sys/kernel/pid_max # Esto debe ser realizado como root
$ cat /proc/sys/kernel/pid_max
4. $ cat &
[2] 311
$ kill -9 311

Tenga en cuenta que cuando se comienza de nuevo, el kernel comienza en PID=300, no en un


número menor. Es posible que se de cuenta que asignar PIDs a los procesos nuevos no es algo
trivial; debido a que el sistema puede haber comenzado de nuevo a asignar los números
correspondientes, el kernel siempre /ene que veri.car que al crear esos nuevos PIDs no están en
uso. . El kernel Linux /ene una manera muy e.ciente de hacer esto, la cual no depende del número
de procesos corriendo en el sistema.

Objetivos de aprendizaje (Revision)

Usted debería ser capaz de:


 Conocer las principales responsabilidades que el kernel debe realizar y cómo lo
hace.
 Explicar qué parámetros pueden ser configurados en la línea de comandos del
kernel, y cómo hacerlos efectivos para un sólo inicio del sistema o de forma
persistente.
 Saber en dónde encontrar documentación detallada acerca de estos parámetros.
 Saber cómo utilizar sysctl para configurar parámetros del kernel, ya sea después
de haber iniciado el sistema o de forma persistente con los reinicios del sistema.

LFS201: Fundamentos de Administración de Sistemas Linux 104


Capítulo 7. Módulos del Kernel

El kernel Linux hace un uso extensivo de módulos, los cuales contienen software
importante que puede ser cargado y descargado según se necesite después que el
sistema ha iniciado. Muchos módulos incorporan controladores de dispositivos para el
control de hardware, ya sea como parte del sistema o periféricos. Otros módulos pueden
controlar protocolos de red, proveer soporte a diferentes tipos de sistemas de archivos y
muchos otros propósitos. Los parámetros pueden ser especificados al cargar los módulos
con el fin de controlar su comportamiento. El resultado final es una gran flexibilidad y
agilidad en la respuesta a las condiciones y necesidades cambiantes.

Objetivos de Aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Enumerar las ventajas en la utilización de módulos del kernel.
 Utilizar insmod, rmmod y modprobe para cargar y descargar módulos del kernel.
 Saber cómo usar modinfo para encontrar información acerca de los módulos del
kernel.

LFS201: Fundamentos de Administración de Sistemas Linux 105


7.1 Ventajas de los módulos del Kernel

Muchas piezas de soporte en el kernel Linux están diseñadas como parte integral del
kernel cuando éste se carga inicialmente, o para ser agregadas (o removidas) más tarde
en forma de módulos según sea necesario. De hecho, la mayoría de los componentes
del kernel se integran como módulos, con excepción de los elementos centrales.

Tales módulos pueden o no ser controladores de dispositivos. Por ejemplo, pueden


implementar un cierto protocolo de red o sistema de archivos que maneja un dispositivo
de hardware o software. Incluso en los casos en que prácticamente siempre se necesitará
la funcionalidad, la incorporación de la capacidad de carga y descarga como módulo
facilita el desarrollo de software, ya que no hacen falta reinicios del kernel para probar los
cambios realizados.

Incluso con el uso generalizado de los módulos del kernel, Linux conserva una
arquitectura de kernel monolítico en vez de un microkernel. Esto es porque cuando se
carga un módulo se convierte en una parte completamente funcional del kernel, con pocas
restricciones. Estos se comunican con todos los subsistemas del kernel principalmente a
través de recursos compartidos, como memoria y archivos de bloqueo, más que a través
de pasar mensajes como puede ocurrir en un microkernel.
Linux no es el único sistema operativo que utiliza módulos; Solaris lo hace y también AIX,
quienes las llaman extensiones del kernel. Sin embargo, Linux las utiliza de manera
particularmente robusta.

7.2 Herramientas de trabajo con módulos

Hay una serie de herramientas que se utilizan con los módulos del kernel:
 lsmod: Lista los módulos cargados.
 insmod: Carga módulos directamente.
 rmmod: Remueve módulos directamente.
 modprobe: Carga o descarga módulos, utilizando una base de datos
preconstruida de los módulos con información de sus dependencias.
 depmod: Reconstruye la base de datos de dependencia de módulos; es requerida
por modprobe y modinfo.
 modinfo: Proporciona información acerca de un módulo.

LFS201: Fundamentos de Administración de Sistemas Linux 106


7.3 Carga y descarga de módulos

La carga y descarga del módulo se debe realizar como usuario root. Si se conoce la ruta
completa, el módulo se puede cargar directamente de la siguiente forma:

$ sudo /sbin/insmod <pathto>/module_name.ko

La ubicación normal de los módulos del kernel está bajo el árbol de


directorios /lib/modules/<kernel-version>. Un módulo del kernel siempre tiene una
extensión .ko, como e1000e.ko, ext4.ko, o usbserial.ko.
Los módulos del kernel están asociados a la versión específica del kernel y deben
coincidir con el kernel en ejecución o no pueden ser cargados. Deben ser compilados ya
sea cuando el propio kernel es compilado, o posteriormente en un sistema que contiene
las fuentes del kernel y la configuración de compilación para realizarlo de forma
apropiada.
Mientras el módulo es cargado es posible ver su estado con lsmod:

$ lsmod

Module Size Used by


...
usb_storage 50309 0
vmnet 38408 13
fuse 74097 5
....
snd_hda_codec_analog 9813 1
snd_hda_codec_generic 47551 1 snd_hda_codec_analog
snd_hda_intel 19279 4
snd_usb_audio 140055 3
....
soundcore 5891 2 snd,snd_hda_codec
nouveau 911957 4
ahci 23547 8
libahci 21534 1 ahci
skge 29924 0
.....

El módulo se puede remover directamente como sigue:

$ sudo /sbin/rmmod module_name

Note que al remover un módulo no es necesario proveer ya sea la ruta completa del
archivo o la extensión .ko.

LFS201: Fundamentos de Administración de Sistemas Linux 107


7.4 modprobe

En la mayoría de los casos los módulos no son cargados ni descargados


con insmod y rmmod. En vez de eso, se usa modprobe, de la forma que se muestra en
continuación:

$ sudo /sbin/modprobe module_name


$ sudo /sbin/modprobe -r module_name

en donde la segunda forma es usada para remover el módulo. Para


que modprobe funcione, los módulos tienen que estar instalados en el lugar correcto,
generalmente bajo /lib/modules/$(uname -r), donde $(uname -r) entrega la
versión actual del kernel, por ejemplo 3.18.3.

7.5 Algunas consideraciones en relación a los módulos

Hay algunas cosas importantes para mantener en mente al cargar y descargar módulos:
 No es posible descargar un módulo que está siendo usado por uno u otros
módulos, lo cual se puede determinar a partir de la lista que provee lsmod.

 No es posible descargar un módulo que está siendo usado por uno o


más procesos, lo cual también puede ser visto en la salida de lsmod. Sin
embargo, hay módulos que no llevan un registro de este tipo de referencias, como
los módulos de los controladores de dispositivos de red, ya que sería muy difícil
reemplazar temporalmente un módulo sin apagar y reiniciar gran parte de la pila
de red.

 Cuando un módulo es cargado con modprobe, el sistema automáticamente carga


todos los módulos de los cuales depende, los cuales necesitan ser cargados
primero.

 Cuando un módulo es descargado con modprobe -r, el sistema descargará


automáticamente cualquier otro módulo que esté siendo utilizado por éste, siempre
y cuando no estén siendo usados de forma simultánea por otros módulos
cargados.

LFS201: Fundamentos de Administración de Sistemas Linux 108


7.6 modinfo

modinfo puede ser usado para encontrar información acerca de los módulos del kernel
(tanto si están actualmente cargados o no), como se muestra a continuación:

$ /sbin/modinfo my_module
$ /sbin/modinfo <pathto>/my_module.ko

Por ejemplo:

$ modinfo e1000
filename: /lib/modules/3.1.0/kernel/drivers/net/e1000/e1000.ko
version: 7.3.21-k8-NAPI
license: GPL
description: Intel® PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: E005D763BC7910379BDD09A
alias: pci:v00008086d00002E6Esv*sd*bc*sc*i*
alias: pci:v00008086d000010B5sv*sd*bc*sc*i*
alias: pci:v00008086d00001099sv*sd*bc*sc*i*
....
alias: pci:v00008086d00001000sv*sd*bc*sc*i*
depends: vermagic: 3.1.0 SMP preempt mod_unload
parm: TxDescriptors:Number of transmit descriptors (array of int)
parm: RxDescriptors:Number of receive descriptors (array of int)
parm: Speed:Speed setting (array of int)
parm: Duplex:Duplex setting (array of int)
parm: AutoNeg:Advertised auto-negotiation setting (array of int)
parm: FlowControl:Flow Control setting (array of int)
parm: XsumRX:Disable or enable Receive Checksum offload (array of
int)
parm: TxIntDelay:Transmit Interrupt Delay (array of int)
parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of
int)
parm: RxIntDelay:Receive Interrupt Delay (array of int)
parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm: InterruptThrottleRate:Interrupt Throttling Rate (array of
int)
parm: SmartPowerDownEnable:Enable PHY smart power down (array of
int)
parm: copybreak:Maximum size of packet that is copied to a new
buffer on receive (uint)
parm: debug:Debug level (0=none,...,16=all) (int)

lo cual despliega información acerca de la versión, nombre de archivo, qué dispositivos de


hardware puede manejar el controlador y qué parámetros pueden ser suministrados
durante la carga.

Mucha de la información acerca de los módulos puede ser visualizada también en el árbol
de directorios del seudosistema de archivos /sys; en el ejemplo anterior se podría mirar
bajo /sys/module/e1000, y algunos - si es que no todos los parámetros - se pueden leer
y/o escribir bajo /sys/module/e1000/parameters. Le mostraremos cómo configurarlos
en el ítem siguiente.

LFS201: Fundamentos de Administración de Sistemas Linux 109


7.7 Parámetros en los Módulos

En muchos casos es posible especificar valores de los parámetros al cargar el módulo,


como se muestra aquí:

$ sudo /sbin/insmod <pathto>/e1000e.ko debug=2 copybreak=256

o de forma más fácil para un módulo que está presente en la ubicación adecuada del
sistema:

$ sudo /sbin/modprobe e1000e debug=2 copybreak=256

7.8 Configuración en los módulos del kernel

Los archivos en el directorio /etc/modprobe.d controlan algunos parámetros que entran


en juego cuando la carga se realiza con modprobe. Estos parámetros incluyen alias de
nombre de módulo y opciones proveídas automáticamente. También es posible poner
módulos específicos en una lista negra para evitar que sean cargados.

Los ajustes se aplican tanto a módulos que están cargados y descargados, y la


configuración puede ser modificada a medida en que las necesidades cambian.

El formato de los archivos en /etc/modprobe.d es simple: un comando por línea, con


líneas en blanco y otras con #, en las cuales se ignora el contenido (lo cual es útil para
agregar comentarios). Una diagonal inversa al final de una línea causa que ésta continúe
en la siguiente, lo cual le brinda un mayor orden al archivo.

Comprobación de Conocimientos 7.1

LFS201: Fundamentos de Administración de Sistemas Linux 110


7.9 Laboratorio 7.1
Laboratorio 7.1: Módulos del kernel

1. Liste todos los módulos del kernel que están cargados actualmente en su sistema.
2. Cargue un módulo que no esté en uso en su sistema. Si está ejecutando un kernel que
viene con la distribución es fácil encontrar los módulos; simplemente /ene que buscar en
el directorio /lib/modules/ /kernel/drivers/net y elegir uno (los kernels que vienen con las
distribuciones incluyen controladores para cada disposi/vo, sistema de archivos, protocolo
de red, etc., todo lo que un sistema puede necesitar). Sin embargo, si está corriendo un
kernel personalizado es posible que no tenga muchos módulos disponibles para cargar.
3. Liste los módulos del kernel nuevamente y vea si el módulo fue realmente cargado.
4. Remueva el módulo que cargó anteriormente.
5. Liste los módulos del kernel nuevamente y compruebe si el módulo fue descargado
correctamente.

Solución 7.1
1. $ lsmod

En la sección que viene a con/nuación, subs/tuya cualquier nombre de módulo que usó
en vez de 3c59x. Cualquiera de estos dos métodos va a funcionar, pero el segundo es más
fácil.
2. $ sudo insmod /lib/modules/$(uname -r)/kernel/drivers/net/3c59.x
$ sudo /sbin/modprobe 3c59x
3. $ lsmod | grep 3c59x
4. De nuevo, cualquiera de los siguientes métodos va a funcionar.

$ sudo rmmod 3c59x


$ sudo modprobe -r 3c59x

5. $ lsmod | grep 3c59x

Objetivos de aprendizaje (Revisión)

Usted debería ser capaz de:


 Enumerar las ventajas de utilizar módulos del kernel.
 Usar insmod, rmmod y modprobe para cargar y descargar módulos del kernel.
 Saber cómo usar modinfo para encontrar encontrar información acerca de
módulos del kernel.

LFS201: Fundamentos de Administración de Sistemas Linux 111


Capítulo 8. Dispositivos y UDEV
Linux usa udev, una pieza de software inteligente para descubrir hardware y dispositivos
periféricos tanto durante el inicio como después, una vez que son conectados al sistema.
Los nodos de dispositivo son creados automáticamente, para luego utilizados por las
aplicaciones y subsistemas del sistema operativo para comunicarse y transferir datos
desde y hacia los dispositivos. Los administradores del sistema pueden controlar cómo
opera udev a través de la creación de reglas especiales para asegurar que los resultados
corresponden al comportamiento deseado.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Explicar el rol de los nodos de dispositivo y cómo se usan los
números mayor y menor.
 Comprender la necesidad de usar udev y enumerar sus componentes principales.
 Describir cómo funciona el administrador de dispositivos udev.
 Identificar archivos de reglas de udev y aprender a crear reglas personalizadas.

LFS201: Fundamentos de Administración de Sistemas Linux 112


8.1 Nodos de dispositivo

Los dispositivos orientados a caracteres y bloques tienen entradas de sistemas de


archivos asociados a ellos; por otro lado, los dispositivos de red en Linux no los poseen.
Estos nodos de dispositivo pueden ser usados por programas para comunicarse con los
dispositivos, usando llamadas al sistema E/S normal como
open(), close(), read() y write(). Por otra parte, los dispositivos de red funcionan a
través de la transmisión y recepción de paquetes, los cuales deben construirse a partir de
la decodificación de flujos de datos, o ser reensamblados cuando son recibidos.

Un controlador de dispositivo puede administrar múltiples nodos de dispositivo, los cuales


están localizados normalmente en el directorio/dev:

$ ls -l /dev
total 0
crw------- 1 coop audio 14, 4 Jul 9 01:54 audio
crw------- 1 root root 10, 62 Jul 9 01:54 autofs
lrwxrwxrwx 1 root root 4 Jul 9 01:54 cdrom -> scd0
lrwxrwxrwx 1 root root 4 Jul 9 01:54 cdrw -> scd0
crw------- 1 coop root 5, 1 Jul 9 06:54 console
....
lrwxrwxrwx 1 root root 4 Jul 9 01:54 dvd -> scd0
lrwxrwxrwx 1 root root 4 Jul 9 01:54 dvdwriter -> scd0
crw------- 1 root root 10, 228 Jul 9 01:54 hpet
crw-r----- 1 root kmem 1, 2 Jul 9 01:54 kmem
crw------- 1 root root 1, 11 Jul 9 01:54 kmsg
crw-r----- 1 root kmem 1, 1 Jul 9 01:54 mem
crwxrwxrwx 1 root root 1, 3 Jul 9 01:54 null
crw-rw---- 1 root root 10, 144 Jul 9 01:54 nvram
brw------- 1 coop disk 11, 0 Jul 9 01:54 scd0
....
brw-r----- 1 root disk 8, 0 Jul 9 01:53 sda
brw-r----- 1 root disk 8, 1 Jul 9 01:53 sda1
brw-r----- 1 root disk 8, 2 Jul 9 06:54 sda2
....
brw-r----- 1 root disk 8, 16 Jul 9 01:53 sdb
brw-r----- 1 root disk 8, 17 Jul 9 01:53 sdb1
brw-r----- 1 root disk 8, 18 Jul 9 01:53 sdb2
....
crw------- 1 coop audio 14, 1 Jul 9 01:54 sequencer
crw------- 1 coop audio 14, 8 Jul 9 01:54 sequencer2
crw-rw-rw- 1 root tty 5, 0 Jul 9 01:54 tty
crw-rw---- 1 root root 4, 0 Jul 9 14:54 tty0
crw------- 1 root root 4, 1 Jul 9 06:54 tty1
cr—r—r-- 1 root root 1, 9 Jul 9 01:53 urandom
....
crw-rw-rw- 1 root root 1, 5 Jul 9 01:54 zero

Los nodos de dispositivo pueden ser creados de la siguiente forma:

$ sudo mknod [-m mode] /dev/name <type> <major> <minor>


e.g., mknod -m 666 /dev/mycdrv c 254 1

LFS201: Fundamentos de Administración de Sistemas Linux 113


8.2 Números mayor y menor

Los números mayor y menor identifican el controlador asociado al dispositivo. En este


esquema el controlador reserva de forma única un grupo de números. En la mayoría de
los casos (con excepciones) los nodos de dispositivo del mismo tipo (de bloque o
carácter) que tienen el mismo número mayor, usan el mismo controlador.

Al listar algunos nodos de dispositivo de la forma en que se muestra, se obtiene lo


siguiente:

$ ls -l /dev/sda*
brw-rw---- 1 root disk 8, 0 Dec 29 06:40 /dev/sda
brw-rw---- 1 root disk 8, 1 Dec 29 06:40 /dev/sda1
brw-rw---- 1 root disk 8, 2 Dec 29 06:40 /dev/sda2
.......

Los números mayor y menor se muestran en el mismo lugar que el tamaño de archivo al
visualizar archivos normales; en el ejemplo de arriba sería 8, 0, etc. Mientras que los
usuarios finales probablemente no necesitarán referirse explícitamente a los números
mayor y menor (ya que lo harán por nombre), los administradores de sistema podrían
requerir hacerlo de vez e cuando, en caso que el sistema se confunda acerca de los
dispositivos, o si se ha agregado hardware en tiempo de ejecución.

LFS201: Fundamentos de Administración de Sistemas Linux 114


El número menor es usado sólo por el controlador de dispositivo para diferenciar entre los
diferentes dispositivos que este puede controlar, o cómo son usados. Estos pueden
corresponder a instancias diferentes de un mismo tipo de dispositivo (como la primera y
segunda tarjeta de sonido o partición de disco duro), o diferentes modos de operación de
un determinado dispositivo (como diferentes densidades en una unidad de disquete).

Los números de dispositivo tienen sentido en el espacio de usuario también. Las llamadas
al sistema mknod() y stat() entregan información acerca de los
números mayor y menor.

8.3 udev

Los métodos de gestión de nodos de dispositivo se tornaron torpes y difíciles a medida en


que Linux evolucionó. El número de nodos de dispositivo en /dev y sus subdirectorios
alcanzó una cantidad entre 15.000 a 20.000 en la mayoría de las instalaciones durante la
serie del kernel 2.4. Nodos para todo tipo de dispositivos - los que nunca van a ser
utilizados en la mayoría de las instalaciones - todavía son creados de forma
predeterminada, ya que los distribuidores no tienen la certeza de qué hardware estará
presente en un sistema.

Por supuesto, muchos desarrolladores y administradores de sistema recortaron la lista a


lo que realmente se necesita, lo cual es especialmente útil en sistemas embebidos, pero
esto correspondió a una tarea esencialmente manual y propensa a generar errores.

Note que mientras los nodos de dispositivo no son archivos normales y no ocupan mucho
espacio en el sistema de archivos, el tener directorios muy grandes disminuye la
velocidad de acceso a los nodos de dispositivo, especialmente en el primer uso. Por otro
lado, el agotamiento de los números mayor y menor disponibles requiere un enfoque más
moderno y dinámico en cuanto a la creación y el mantenimiento de los nodos de
dispositivo.

Lo ideal sería registrar dispositivos por nombre. Sin embargo, no es posible librarse de los
números mayor y menor del todo, debido a que el estándar POSIX los exige (POSIX es
un acrónimo de Interfaz de sistema operativo portable, una familia de estándares
diseñados para asegurar la compatibilidad entre diferentes sistemas operativos).

El método udev crea nodos de dispositivo al vuelo, a medida en que son requeridos. No
hay necesidad de mantener un gran cantidad de nodos de dispositivo que no van a ser
usados nunca. La u en udev viene de usuario e indica que la mayoría del trabajo de
creación, eliminación y modificación de nodos de dispositivo se realiza en el espacio de
usuario.

udev maneja la generación dinámica de nodos de dispositivo y evolucionó de tal forma


que reemplazó mecanismos como devfs y hotplug. Una característica interesante es el
soporte de nombres persistentes para los dispositivos; los nombres no necesitan
depender del orden en el cual los dispositivos son conectados. Tal comportamiento es
controlado en las especificaciones de las reglas de udev.

LFS201: Fundamentos de Administración de Sistemas Linux 115


8.4 Componentes de udev

udev se ejecuta como demonio (ya sea udevd o systemd-udevd) y monitorea un netlink
socket. Cuando dispositivos nuevos son inicializados o removidos, el utilitario uevent del
kernel envía un mensaje a través del socket, el que es recibido por udev, el cual realiza la
acción apropiada para crear o remover entradas de los nodos de dispositivo de acuerdo a
las reglas.

Los tres componentes de udev son:


1. La biblioteca libudev, la cual permite el acceso a la información de los
dispositivos.

2. El demonio udevd, el cual gestiona el directorio /dev .

3. La utilidad udevadm para el control y diagnóstico.

La manera más apropiada de utilizar udev es tener un sistema original; el


directorio /dev está vacío en el arranque del kernel y luego se puebla con nodos de
dispositivo a medida en que se necesitan. Cuando se usa de esta forma, es necesario
iniciar usando una imagen initramfs, la cual puede contener un conjunto de nodos de
dispositivos preliminares, como también la infraestructura de udev.

8.5 udev y hotplug

A medida en que se agregan o remueven dispositivos desde el sistema - en este caso al


trabajar con el subsistema hotplug - udev actúa ante la notificación de eventos para crear
y remover nodos de dispositivo. La información necesaria para crearlos con los nombres
adecuados, números mayor y menor, permisos, etc., es obtenida a través del registro
existente en el seudosistema de archivos sysfs (montado en /sys) y un conjunto de
archivos de configuración.

El archivo principal de configuración es /etc/udev/udev.conf. Este contiene información


de dónde poner los nodos de dispositivo, permisos por defecto, dueños, etc. Por defecto,
las reglas para los nombres de los dispositivos están ubicadas en el
directorio /etc/udev/rules.d. A través de la lectura de la página man de udev es
posible obtener una gran cantidad de información específica acerca de cómo configurar
reglas para situaciones comunes.

LFS201: Fundamentos de Administración de Sistemas Linux 116


8.6 El gestor de dispositivos udev

Cuando udev recibe un mensaje desde el kernel acerca de dispositivos que están siendo
añadidos o removidos, analiza los archivos de configuración en /etc/udev/rules.d/*.rules
para determinar si hay reglas que apliquen al dispositivo en cuestión.

Entonces udev toma las acciones apropiadas, incluyendo:


 Asignación de nombre a los nodos de dispositivo.

 Creación de nodos de dispositivo y links simbólicos.

 Ajuste de permisos de archivo y dueño para los nodos de dispositivo.



 Realizar otras acciones para inicializar el dispositivo y ponerlo disponible.

Estas reglas son completamente personalizables.

8.7 Archivos de reglas udev

Los archivos de las reglas de udev están


localizados bajo
/etc/udev/rules.d/<rulename>.rules,
con nombres como los siguientes:
 30-usb.rules
 90-mycustom.rules

Por defecto, cuando udev lee los archivos de


reglas busca archivos con el sufijo .rules. Si
encuentra más de un archivo, los lee uno por uno,
de manera lexicográfica, es decir, en orden
alfabético ascendente. El nombre estándar de un
archivo de reglas corresponde generalmente a un
número de dos dígitos seguido por un nombre
descriptivo de la regla en cuestión, para finalizar
con el sufijo .rules.

LFS201: Fundamentos de Administración de Sistemas Linux 117


8.8 Creando reglas udev

El formato para una regla udev es simple:

<match><op>value [, ...] <assignment><op>value [, ... ]

Hay dos partes separadas que están definidas en una misma línea:
 La primera parte consiste en uno o más pares indicados por == . Estos tratan de
coincidir con los atributos y/o características de un dispositivo a algún valor.

 La segunda parte consiste en una o más asignaciones clave-valor, las que asignan
un valor a un nombre, tal como un nombre de archivo, pertenencia a un grupo,
incluso permisos de archivo, etc.

Si no se encuentra una regla que coincida, se usa el nombre de nodo de dispositivo y


otros atributos por defecto.

8.9 Algunos ejemplos de archivos y reglas


Aquí hay un ejemplo de un archivo de reglas para un dispositivo Fitbit:

$ cat /etc/udev/conf.d/rules.d/99-fitbit.rules
SUBSYSTEM==”usb”, ATTR{idVendor}==”2687”, ATTR{idProduct}==”fb01”,
SYMLINK+=”fitbit”, MODE=”0666”
$ cat /etc/udev/conf.d/rules.d/98-kexec.rules
SUBSYSTEM==”cpu”, ACTION==”online”, PROGRAM=”/bin/systemctl try-
restart kdump.service”
SUBSYSTEM==”cpu”, ACTION==”offline”, PROGRAM=”/bin/systemctl try-
restart kdump.service”
SUBSYSTEM==”memory”, ACTION==”add”, PROGRAM=”/bin/systemctl try-
restart kdump.service”
SUBSYSTEM==”memory”, ACTION==”remove”, PROGRAM=”/bin/systemctl try-
restart kdump.service”
$ cat 80-kvm.rules
KERNEL==”kvm”, GROUP=”kvm”, MODE=”0666”
$ cat 99-fuse.rules
KERNEL==”fuse”, MODE=”0666”,OWNER=”root”,GROUP=”root”

LFS201: Fundamentos de Administración de Sistemas Linux 118


Comprobacion de Conocimientos 8.1

Objetivos de aprendizaje (revisión)

Usted debería ser capaz de:


 Explicar el rol de los nodos de dispositivo y cómo se usan los
números mayor y menor.
 Comprender la necesidad del método udev y enumerar sus componentes
principales.
 Describir cómo funciona el administrador de dispositivos udev.
 Identificar archivos de reglas de udev y saber crear archivos de reglas
personalizadas.

LFS201: Fundamentos de Administración de Sistemas Linux 119


Capítulo 9. Particionamiento y Formateo de Discos

El particionado y formateo de los discos duros disponibles es una parte crítica en la


instalación del sistema. Es posible escoger diferentes esquemas en función del tamaño
del sistema, el número de usuarios y sus necesidades. Otros ítems a tomar en cuenta es
el tipo de hardware del que se dispone, particularmente el tipo de bus de datos al cual el
sistema de almacenamiento está conectado.
Se debe tener mucho cuidado al configurar o modificar las tablas de particiones, ya que
los errores de este tipo pueden ser muy destructivos

Objetivos de aprendizaje

Al final del capítulo usted debería ser capaz de:


 Describir y contrastar los tipos de discos duros y buses de datos más
comunes.
 Explicar cómo es la geometría de un disco y otros conceptos de
particionamiento.
 Comprender cómo los dispositivos de disco son nombrados y cómo
identificar sus nodos de dispositivo asociados.
 Distinguir las distintas estrategias de particionamiento y saber seleccionarlas
correctamente.
 Usar las utilidades blkid y fdisk.
 Respaldar y restaurar tablas de partición.

LFS201: Fundamentos de Administración de Sistemas Linux 120


9.1 Tipos comunes de discos

Existe una gran variedad de tipos de discos duros; cada uno está caracterizado por el tipo
de bus de datos a través del cual se conecta, como también otros factores como
velocidad, capacidad y cuán bien operan múltiples unidades de forma simultánea.
 IDE y EIDE
(Entorno de desarrollo integrado e IDE mejorado)
Estos fueron el estándar en notebooks y PCs de escritorio por años. Sin embargo,
son pequeños y lentos en comparación a hardware más moderno, por lo cual
actualmente están obsoletos; de hecho, los controladores no están disponibles en
máquinas actualizadas.

 SATA (Serial ATA)


Este tipo fue diseñado para reemplazar a Parallel ATA (PATA) (el cual fue
conocido originalmente como IDE). Tenían una mayor transferencia de datos,
cables más pequeños y eran detectados como dispositivos SCSI por el sistema
operativo, lo cual simplificó el tema de escribir controladores de software (entre
otras cosas), aun siendo que el hardware no es realmente SCSI.

En comparación a PATA, SATA ofrece un cable de tamaño menor (7 pines),


sustitución en caliente (hot swapping) y una transferencia de datos más rápida y
eficiente. Los controladores más nuevos pueden manejar 16 GB/s, pero 3 GB/s y 6
GB/s son los valores más comunes en dispositivos del segmento usuario normal.

 SCSI (Interfaz de Sistema para Pequeñas Computadoras)


Estos han sido el pilar de los servidores empresariales por décadas. Mientras que
pueden tener una capacidad menor que los discos SATA, tienen a ser mucho más
rápidos y a trabajar en paralelo mucho mejor, de la forma en la que se requiere
para algunas configuraciones en RAID.
Hay varias versiones de SCSI: Fast, Wide, Ultra y UltraWide, lo cual torna un
poco confusas las cosas. Además, hay muchos controladores de dispositivo
diferentes, dependiendo del hardware específico. Eso no sucede en SATA, ya que
en ese caso existen controladores estandarizados que pueden adaptarse a una
gran variedad de hardware.

Los discos SCSI van desde un rango pequeño (bus de 8 bits) a uno amplio (bus de
16 bits), con una tasa de transferencia desde 5MB por segundo (un valor bajo,
correspondiente a dispositivos SCSI estándar) a cerca de 160MB por segundos
(Ultra-Wide SCSI-3).

La mayoría de los PCs usan unidades SCSI de un solo extremo o diferenciales.


Desafortunadamente, los dos tipos no son compatibles entre sí. De todas formas,
ambos tipos pueden coexistir en el mismo controlador.

Los controladores de una sola terminación soportan hasta 7 dispositivos, con una
longitud de cable de cerca de 6 metros. Los controladores diferenciales soportan
hasta 15 dispositivos, con una longitud máxima del cable de unos 12 metros.

LFS201: Fundamentos de Administración de Sistemas Linux 121


 SAS
El Serial Attached SCSI es un protocolo serial punto a punto nuevo, que viene a
reemplazar a la interfaz SCSI. Las tasas de transferencia son similar a SATA, pero
el rendimiento general es mejor.

 USB
Los dispositivos de Bus Universal en Serie incluyen memorias y discos duros
externos USB. El sistema operativo los ve como dispositivos SCSI.

En la misma categoría están las unidades SSD modernas (dispositivos de estado sólido),
las cuales han bajado de precio, no tienen partes movibles, usan menos energía que las
unidades de disco giratorio y tienen velocidades de transferencia más rápidas.
Los SSD internos son instalados de forma similar y en los mismos encapsulados que los
discos convencionales.

9.2 Geometría del disco

La geometría del disco es un concepto con una historia larga para dispositivos giratorios;
se habla de cabezales,cilindros, pistas y sectores.
Para examinar la geometría del disco con fdisk:

$ sudo fdisk -l /dev/sda

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes


255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000001
Device Boot Start End Blocks Id System
/dev/sda1 * 1 3800 30522368 83 Linux
/dev/sda2 3800 3851 409518 83 Linux
.....

Tenga en cuenta que el uso de la opción -l sólo lista la tabla de particiones sin entrar en
modo interactivo.

Los discos giratorios se componen de uno o más platos, cada uno de los cuales es leído
por uno o más cabezales. Los cabezales leen una pista del plato a medida en que el
disco gira.

Estas pistas circulares están divididas en bloques de datos llamados sectores,


generalmente de 512 bytes de tamaño. Un cilindro es un grupo que está formado por una
misma pista en todos los platos.

LFS201: Fundamentos de Administración de Sistemas Linux 122


A medida en que el tiempo pasa la figura de la estructura física ha sido cada vez menos
relevante, debido a que se conoce poco de la electrónica interna de la unidad. Además,
los SSD no tienen partes móviles ni ninguna de las partes descritas anteriormente.

Actualmente los discos están siendo fabricados con sectores más grandes que 512 bytes;
están disponibles en 4 KB. Mientras que sectores de tamaño más grandes pueden
conducir a velocidades de transferencia mayores, el soporte del sistema operativo no está
listo todavía para lidiar con tamaños grandes.

9.3 Particionamiento

Los discos se dividen en particiones. En términos geométricos, estos consisten en


grupos físicamente contiguos de sectores o cilindros.
Una de las particiones primarias puede ser designada como una partición extendida, la
cual puede ser subdividida en particiones lógicas.
SCSI y estándares relacionados como SATA, suportan hasta 15 particiones en el disco.
Las particiones 1-4 son primarias o extendidas; las particiones 5-15 son lógicas. Sólo
puede haber una partición extendida, pero esta puede ser dividida en cuántas particiones
lógicas se necesiten, hasta que se alcance el número máximo de particiones permitidas.
Por ejemplo, la primera unidad SCSI o SATA se denomina sda, la segunda sdb y así
sucesivamente. En la primera unidad, /dev/sda1 es la primera partición
primaria, /dev/sda2 es la segunda, etc.
Si creamos una partición extendida como /dev/sda3, esta podría ser dividida en
particiones lógicas, con designaciones numéricas como /dev/sda5, /dev/sda6, etc.
Nota: Linux no requiere que las particiones comiencen o terminen en los límites de los
cilindros, pero otros sistemas operativos podrían presentar problemas ante la misma
situación. Por esta razón, las herramientas de particionamiento deLinux tratan de
terminar en los límites, con el fin de integrarse bien con otros sistemas. Obviamente, las
particiones tampoco deberían traslaparse.

LFS201: Fundamentos de Administración de Sistemas Linux 123


9.4 Por qué particionar?

Hay diversas razones que justifican dividir los datos del sistema en múltiples particiones,
incluyendo:
 Separación
Es deseable aislar los datos de usuario y aplicaciones de los archivos del sistema
operativo, la mayoría de los cuales son de lectura solamente, excepto durante la
instalación y actualizaciones del sistema. Por ejemplo,/home, que contiene
archivos específicos de los usuarios se suele poner en una partición por separado.
 Datos compartidos
Múltiples sistemas operativos o máquinas pueden usar los mismos sistemas de
archivos. Por ejemplo, /home podría estar montado como un directorio compartido
en una red, a través de NFS. O alguien podría tener un sistema de inicio múltiple,
incluso varias versiones de Linux, entre las cuales usted podría desear
compartir/usr/local o /home, por dar un par de ejemplos.
 Seguridad
Puede ser deseable imponer diferentes cuotas (espacio en disco), permisos y
ajustes para diferentes partes del sistema.
 Tamaño
Algunos datos son más bien constantes y otros variables o volátiles, y a menudo
pueden incrementar su tamaño un poco. Por ejemplo, tales datos variables son
almacenados generalmente en una partición montada en /var. Si la partición se
queda sin espacio disponible, en el caso de estar en una partición por separado
de /, será menos probable que el sistema se bloquee.
 Rendimiento
Los datos que tienen que ser leídos con mayor frecuencia, en grandes trozos de
información, serán accedidos más rápidamente si están en un disco rápido (como
los SSD), o en términos anticuados, cercanos al centro del disco, en donde los
tiempos de búsqueda son más cortos.
 Intercambio (swap)

En los sistemas Linux es preferible tener un espacio de intercambio (conocido como


swap) en una partición por separado, en lugar de un archivo en alguna partición que esté
siendo utilizada con otro propósito. Esto tiene una ventaja secundaria, ya que los
esquemas de hibernación utilizan el espacio en la partición de intercambio.
Un esquema común de particionamiento contiene una partición /boot, una para el sistema
raíz /, una partición de intercambio y otra para el directorio /home.
Tenga en cuenta que es más difícil redimensionar una partición después de su creación e
instalación del sistema. Recomendamos que haga un plan inteligente al respecto.
Discutiremos acerca de diseños de sistemas de archivos y el impacto de las particiones
en ellos más adelante.

LFS201: Fundamentos de Administración de Sistemas Linux 124


9.5 Tabla de particiones

La tabla de partición del disco está contenida


en el Registro de arranque principal (MBR), la
cual es de 512 bytes de longitud y cuya
estructura está definida por una convención
que es independiente del sistema operativo.
La tabla de partición tiene 64 bytes de largo y
está ubicada después del byte 446 del
registro de arranque. Nota para los curiosos:
hay 2 bytes más al final del MBR, lo cual se
conoce como el número mágico, firma del
MBR, o marca de final de sector, que tiene
siempre el valor 0x55AA.
Los primeros 446 bytes están reservados
para código máquina. Por lo general, forman
parte de un programa de cargador de
arranque como GRUB.
Sólo una partición en un disco específico
puede ser marcada como activa. Cuando el
sistema inicia, el cargador de booteo maestro
busca ítems para cargar en esa partición.

Cada entrada en la tabla de partición tiene 16 bytes de largo y describe una de las cuatro
posibles particiones primarias. La información que tiene cada una es la siguiente:
 Bit activo
 Dirección de inicio en formato cilindro/cabezal/sectores (CHS), lo cual es ignorado
por Linux de todas formas
 Código del tipo de partición, indicando: xfs, LVM, ntfs, ext4, swap, etc
 Dirección final en CHS (también ignorado por Linux)
 Sector de inicio, contando linealmente desde 0
 Número de sectores en la partición

Linux usa sólo los últimos dos campos para direccionamiento, utilizando el método de
direccionamiento de bloque lógico (LBA).

LFS201: Fundamentos de Administración de Sistemas Linux 125


9.6 Nombres de dispositivos de disco y nodos

El kernel Linux interactúa a bajo nivel con los discos a través de nodos de dispositivos
que normalmente se encuentran en el directorio /dev. Generalmente los nodos de
dispositivos son accedidos sólo a través de la infraestructura del sistema de archivos
virtual del kernel; si se accede de cualquier otra forma a los nodos de dispositivo, es
posible destruir un sistema de archivos completo. Eso es justamente lo que se hace al
formatear una partición, como en el siguiente comando:

$ sudo mkfs.ext4 /dev/sda9

Los nodos de dispositivo para discos SCSI y SATA siguen una convención de nombres
simple:
 El primer disco duro es /dev/sda.
 El segundo disco duro es /dev/sdb.
 etc.

Las particiones son enumeradas como sigue:


 /dev/sdb1 es la primera partición del segundo disco.
 /dev/sdc4 es la cuarta partición del tercer disco.

En las sentencias de arriba, sd puede ser un disco SCSI o SATA. Cuando aún se
encontraban discos IDE, eran llamados /dev/hda3, /dev/hdb , etc.
El comando ls -l /dev mostrará los nodos de dispositivo disponibles.

9.7 Más cerca de nombres de dispositivos SCSI

Para dispositivos SCSI necesitamos elaborar un poco más en lo que se entiende por
primer disco duro, segundo, etc. Estos están determinados por la combinación del número
ID/número del controlador.
La designación de la unidad (a, b, c, etc.) está basada principalmente en el número de ID
del dispositivo SCSI en vez de su posición en el bus mismo.
Por ejemplo, si tuviéramos dos controladoras SCSI, uno con ID 1 y otro con ID 3 en la
controladora 0; uno con ID 2 y otro con ID 5 en la controladora 1 (note que el ID 2 está en
la última unidad):
 ID 1 sería /dev/sda
 ID 3 sería /dev/sdb
 ID 2 (en la controladora 1) sería /dev/sdc
 ID 5 sería /dev/sdd

LFS201: Fundamentos de Administración de Sistemas Linux 126


9.8 blkid y lsblk

blkid es una utilidad para localizar dispositivos de bloque y entregar información acerca
de sus atributos. Funciona con la biblioteca libblkid. Puede tomar como argumento un
dispositivo en particular o una lista.

$ sudo blkid /dev/sda*

dev/sda: PTTYPE=”dos”

/dev/sda1: LABEL=”boot” UUID=”b0fa22fc-8882-4f1c-bc16-6cf7fc4e9454”


TYPE=”ext4” PTTYPE=”dos”

/dev/sda10: UUID=”JQshRp-Jxa5-0oiC-X1Oe-si8d-lRQD-48aYNt”
TYPE=”LVM2_member”

/dev/sda11: LABEL=”RHEL7” UUID=”b8beaf53-af11-4b14-9e7d-b17069f336ae”


TYPE=”ext4” PTTYPE=”dos”

/dev/sda12: LABEL=”SWAP” UUID=”2b2603f9-a701-4f91-b284-426769f50e51”


TYPE=”swap”

/dev/sda3: PTTYPE=”dos”

/dev/sda5: LABEL=”RHEL6-64” UUID=”89ª3c451-847f-40ª1-97af-


64ª56fe27474” TYPE=”ext4” PTTYPE=”dos”

/dev/sda6: UUID=”YJ2PA3-GSsm-m9rH-XNUM-Ca2X-fkju-OYtiO8”
TYPE=”LVM2_member”

/dev/sda7: LABEL=”RHEL7XFS” UUID=”178d0092-4154-4688-af24-


cda272265e08” TYPE=”xfs”

/dev/sda8: UUID=”NdnbYk-ACCB-9UTX-i3kc-rK0m-Fbht-KjJZwP”
TYPE=”LVM2_member”

/dev/sda9: UUID=”CMc2EP-ijCM-jA8V-ZH5M-B6AA-z0TD-ILMFFE”
TYPE=”LVM2_member”

blkid funcionará solamente en dispositivos que contienen datos, es decir, una partición
vacía no generará un identificador de bloque UUID. blkid tiene dos formas principales de
operación: ya sea buscando un dispositivo con un par específico NOMBRE=valor, o
desplegando pares de NOMBRE=valor para uno o más dispositivos.

Si no se especifican argumentos, se listarán todos los dispositivos. Existe un buen número


de opciones que indican cómo especificar qué atributos se desean listar.
Una herramienta relacionada es lsblk, la cual presenta los resultados en un formato de
árbol, como se muestra abajo:

LFS201: Fundamentos de Administración de Sistemas Linux 127


$ lsblk -i

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT


sda 8:0 0 465.8G 0 disk
|-sda1 8:1 0 100M 0 part /boot_master
|-sda3 8:3 0 1K 0 part
|-sda5 8:5 0 11.7G 0 part /RHEL6-64
|-sda6 8:6 0 36.2G 0 part
| ‘-VG-dead 254:5 0 60G 0 lvm /DEAD
|-sda7 8:7 0 12G 0 part
|-sda8 8:8 0 353.2G 0 part
| |-VG-tmp 254:0 0 2G 0 lvm
| |-VG-local 254:1 0 24G 0 lvm /usr/local
| |-VG-src 254:2 0 16G 0 lvm /usr/src
| |-VG-virtual 254:3 0 225G 0 lvm /VIRTUAL
| |-VG-iso_images 254:4 0 60G 0 lvm /ISO_IMAGES
| |-VG-dead 254:5 0 60G 0 lvm /DEAD
| |-VG-audio 254:6 0 12G 0 lvm
| ‘-VG-pictures 254:7 0 12G 0 lvm /PICTURES
|-sda9 8:9 0 23.2G 0 part
| |-VG-virtual 254:3 0 225G 0 lvm /VIRTUAL
| ‘-VG-dead 254:5 0 60G 0 lvm /DEAD

9.9 Dimensionando particiones

Los sistemas Linux deberían tener un mínimo de dos particiones:

 /(root): utilizado para todo el sistema de archivos lógico


o En la práctica la mayoría de las instalaciones tendrán más de un sistema de
archivos y más de una partición, las cuales trabajan unidas a través de
los puntos de montaje.
o Con la mayoría de los tipos de sistemas de archivos es difícil redimensionar la
partición raíz; usando LVM, lo cual discutiremos más adelante, podemos
facilitar esta tarea.

Aunque si bien es cierto es posible correr Linux con sólo la partición raíz, la
mayoría de los sistemas usan más particiones para realizar respaldos de forma
más fácil, usar de forma más eficiente las unidades de disco e implementar una
mejor seguridad.

 Intercambio: se usa como una extensión de la memoria física; páginas de


memoria que no tienen un respaldo en archivo físico, pueden ser movidas al disco
hasta que se necesiten nuevamente.
o La recomendación usual es que el tamaño del área de intercambio debería ser
igual al de la memoria física, aunque a veces se recomienda usar el doble. Sin
embargo, la opción adecuada depende de los escenarios de sus del sistema,
como también de las capacidades de hardware. Ejemplos de este tema

LFS201: Fundamentos de Administración de Sistemas Linux 128


pueden ser encontrados en https://help.ubuntu.com/community/SwapFaq y en
http://www.novell.com/support/kb/doc.php?id=7010157.
o El sistema puede tener múltiples particiones o archivos de intercambio.

o En un sistema de un sólo disco, trate de ubicar la partición de intercambio al


centro del mismo; en sistemas de discos múltiples, trate de repartir áreas de
intercambio en los discos.

o Agregar más y más áreas de intercambio no ayudará necesariamente, ya que


a partir de cierto punto se vuelve inútil. En los casos en que aparentemente
falte memoria, es necesario agregar más memoria física o reevaluar la
configuración del sistema.

El área de intercambio es usado como memoria virtual; cuando las páginas de procesos
son movidas fuera de la memoria física, generalmente son almacenadas en el área de
intercambio.

9.10 Respaldar y restaurar tablas de particiones

Particionar y reparticionar discos son operaciones peligrosas. Para tener la posibilidad de


volver a la situación original si algo sale mal, es necesario saber cómo realizar respaldos y
restaurar tablas de particiones.
Es bastante simple realizar una copia de seguridad con dd, como sigue:

$ sudo dd if=/dev/sda of=mbrbackup bs=512 count=1

lo cual respaldará el MBR en el primer disco, incluyendo la tabla de particiones de 64 bits,


la cual es parte de ella.
El MBR puede ser restaurado de ser necesario, de la siguiente forma:

$ sudo dd if=mbrbackup of=/dev/sda bs=512 count=1

Note que los comandos mencionados copiarán solamente la tabla de partición primaria;
no se harán cargo de cualquier tabla de partición que esté almacenada en otras
partitiones (como particiones extendidas, por ejemplo).

Nota: usted debería asumir que modificar la tabla de partición del disco podría eliminar
toda la información de todos los sistemas de archivos en el disco (no debería, pero es
mejor ser precavido). Por lo tanto, siempre es prudente realizar una copia de seguridad de
toda la información antes de realizar cualquier trabajo de este tipo.

En particular, es necesario ser cuidadoso al usar dd: un error simple de tipeo o una opción
usada erróneamente podría destruir la información completa del disco, ¡en cualquier caso
lo mejor es hacer respaldos!

LFS201: Fundamentos de Administración de Sistemas Linux 129


9.11 Editores de la tabla de particiones

Hay una serie de utilidades que pueden ser usadas para modificar las tablas de partición:
 fdisk Es un editor de tabla de particiones que tiene un menú. Es el más estándar y
uno de los editores más flexibles. Esta es la única herramienta de este tipo que
discutiremos.

 sfdisk es un programa de edición de particiones no interactivo, el cual es útil para


hacer scripts. ¡Use esta herramienta con mucho cuidado!

 parted es el programa de manipulación de particiones del proyecto GNU. Puede


crear, eliminar, redimensionar y mover particiones (incluyendo ciertos sistemas de
archivos).

 gparted es una interfaz gráfica de parted, la cual es utilizada ampliamente.

Muchas distribuciones Linux tienen una versión Live CD que se puede ejecutar ya sea
desde un CDROM o un dispositivo USB. Esos medios suelen incluir una copia de gparted,
por lo cual puede ser usado fácilmente como una herramienta gráfica de particionamiento
en discos que no están siendo utilizados.
Note que gparted puede realizar muchas operaciones más que sólo agregar y eliminar
particiones (y las demás operaciones que realiza fdisk), como asignar el tipo de partición.
Es posible mover, redimensionar y formatear particiones, lo cual implica entender los
detalles de diversos tipos de sistemas de archivos. Lo anterior va mucho más lejos de las
funciones esenciales de un editor de particiones.
Si bien es cierto que esto es muy útil, es difícil hacerlo bien y los errores pueden tener
consecuencias serias. Por lo anterior, se recomienda ir a la línea de comandos y realizar
cada una de estas operaciones por separado, con herramientas de bajo nivel (como
fdisk). De hecho Red Hat Enterprise Linux ya no soporta gparted.

9.12 Uso de fdisk

fdisk estará incluido siempre en toda instalación de Linux, por lo cual es buena idea
aprender a usarlo. Usted debe ser root para ejecutar fdisk. Puede ser algo complejo de
usar y se recomienda hacerlo con precaución.

La interfaz de fdisk es simple y posee un menú de texto. Se inicia en un disco en


particular de la siguiente forma:

$ sudo fdisk /dev/sdb

LFS201: Fundamentos de Administración de Sistemas Linux 130


los principales comandos (de una letra) son:
 m: Despliega el menú.
 p: Lista la tabla de particiones.
 n: Crea una partición nueva.
 d: Elimina una partición.
 t: Cambia el tipo de partición.
 w: Escribe la información nueva de la tabla de particiones y sale.
 q: Sale sin realizar cambios.

Afortunadamente no se realizan cambios hasta que la tabla de particiones es escrita en el


disco, presionando w. Por lo tanto, es importante revisar que la tabla de particiones es
correcta (con la tecla p), antes de escribir a disco con w. Si algo está mal, usted puede
salir de forma segura con la tecla q (a menos que ya haya guardado los cambios).
El sistema no utilizará la nueva tabla de partición hasta el próximo reinicio. Sin embargo,
es posible usar el siguiente comando:

$ sudo partprobe -s

para tratar de leer la tabla de partición modificada. Sin embargo, esto no siempre funciona
de manera confiable y lo mejor es reiniciar antes de formatear particiones nuevas y
realizar otras operaciones, ya que mezclar particiones o sobreponer una en otra puede
ser catastrófico.
En cualquier momento es posible ejecutar el siguiente comando:

$ cat /proc/partitions

con el fin de visualizar qué particiones reconoce el sistema operativo.

Comprobación de conocimientos 9.1

LFS201: Fundamentos de Administración de Sistemas Linux 131


Comprobación de conocimientos 9.2

9.13 Laboratorio 9.1


Laboratorio 9.1: Usar un archivo como imagen de par/ción de disco

Para los propósitos de los ejercicios en este curso usted necesitará espacio en disco sin par/cionar.
No es necesario que sea de gran tamaño, uno o dos GB es su.ciente.
Si está usando su máquina na/va y no /ene espacio disponible, va a tener que encoger una
par/ción y el sistema de archivos en ella (esto úl/mo se debe realizar primero), y luego disponer
de ella usando gparted y/o los pasos que tratamos en la sección de manejo de par/ciones.
También puede usar el mecanismo loop device con o sin el programa parted program, como lo
haremos en los primeros dos ejercicios en esta sección.
Si /ene espacio Osico sin par/cionar usted no necesita realizar el procedimiento que se describe a
con/nuación, sin embargo, aún es un ejercicio de aprendizaje muy ú/l.
Vamos a crear un archivo que será usado como contenedor de una imagen de par/ción del disco
duro, y para todos los propósitos puede u/lizarse como una par/ción real. En el siguiente ejercicio
mostraremos cómo poner más de una par/ción en ella y cómo usarlo como si fuera un disco
completo.
1. Crear un archivo lleno de ceros de 1 GB de tamaño:

$ dd if=/dev/zero of=image.le bs=1M count=1024

Puede crear un archivo más pequeño si lo desea o si no /ene su.ciente espacio en la


par/ción en la cual está creándolo.
2. Cree un sistema de archivos en ella:

$ mkfs.ext4 image.le
mke2fs 1.42.9 (28-Dec-2013)
image.le is not a block special device.
Proceed anyway? (y,n) y
Discarding device blocks: done
.....

LFS201: Fundamentos de Administración de Sistemas Linux 132


Obviamente puede darle formato con un sistema de archivos diferente, haciendo mkfs.ext3,
mkfs.vfat, mkfs.xfs, etc.

3. Móntela en algún lugar:

$ mkdir mntpoint
$ sudo mount -o loop image.le mntpoint

Ahora puede usar la par/ción a su antojo, poniendo archivos, etc.

4. Una vez que haya terminado, desmóntela con:

$ sudo umount mntpoint


Un método alterna/vo es usar la opción loop para montarla:
$ sudo losetup /dev/loop2 image.le
$ sudo mount /dev/loop2 mntpoint ....
$ sudo umount mntpoint
$ sudo losetup -d /dev/loop2

Revisaremos losetup en un ejercicio más adelante. Puede usar /dev/loop[0-7] pero tenga cuidado
de que no estén en uso actualmente.

Si bien es cierto que usar un disposi/vo de /po loop en vez de una par/ción real puede ser ú/l,
debe saber que es es bastante inú/l para propósitos de realizar cualquier /po de benchmarking.
Esto se debe a que está poniendo una capa de sistema de archivos sobre otra, lo cual tendrá un
efecto nega/vo en el rendimiento. Por lo anterior, cualquier juicio al respecto va a estar basado en
cómo se comporta un sistema de archivos arriba de otro.

LFS201: Fundamentos de Administración de Sistemas Linux 133


9.13 Laboratorio 9.2
Laboratorio 9.2: Par/cionar un archivo de imagen de disco

El siguiente paso consiste en dividir el archivo de contenedor en múl/ples par/ciones, cada uno de
los cuales puede ser usado para almacenar un sistema de archivos o un área de intercambio.
Usted puede reu/lizar el archivo de imagen creado en el ejercicio previo o puede crear uno nuevo.
1. Ejecute fdisk en su archivo de imagen:

$ sudo fdisk -C 130 image.le


Device does not contain a recognized par//on table
Building a new DOS disklabel with disk iden/.er 0x6280ced3.
Welcome to fdisk (u/l-linux 2.23.2).

Changes will remain in memory only, un/l you decide to write them.

Be careful before using the write command.

Command (m for help):


2. Type m to get a list of commands:

Command (m for help): m


Command ac/on
a toggle a bootable jag
b edit bsd disklabel
c toggle the dos compa/bility jag
d delete a par//on
g create a new empty GPT par//on table
G create an IRIX (SGI) par//on table
l list known par//on types
m print this menu
n add a new par//on
o create a new empty DOS par//on table
p print the par//on table
q quit without saving changes
s create a new empty Sun disklabel
t change a par//on’s system id
u change display/entry units
v verify the par//on table
w write table to disk and exit
x extra func/onality (experts only)

Command (m for help):

LFS201: Fundamentos de Administración de Sistemas Linux 134


3. The -C 130 which sets the number of phony cylinders in the drive is only necessary in old
versions of fdisk, which unfortunately you will .nd on RHEL 6. However, it will do no harm on
other distribu/ons.
Create a new primary par//on and make it 256 MB (or whatever size you would like:
Command (m for help): n
Par//on type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p

Par//on number (1-4, default 1): 1 First sector (2048-2097151, default 2048):
Using default value 2048

Last sector, +sectors or +size{K,M,G} (2048-2097151, default 2097151): +256M

Par//on 1 of type Linux and of size 256 MiB is set

4. Add a second primary par//on also of 256 MB in size:

Command (m for help): n

Par//on type:

p primary (1 primary, 0 extended, 3 free)


e extended

Select (default p): p

Par//on number (2-4, default 2): 2

First sector (526336-2097151, default 526336):


Using default value 526336

Last sector, +sectors or +size{K,M,G} (526336-2097151, default 2097151): +256M

Par//on 2 of type Linux and of size 256 MiB is set

Command (m for help): p

Disk image.le: 1073 MB, 1073741824 bytes, 2097152 sectors

Units = sectors of 1 * 512 = 512 bytes


Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/op/mal): 512 bytes / 512 bytes
Disk label type: dos
Disk iden/.er: 0x6280ced3

Device Boot Start End Blocks Id System


image.le1 2048 526335 2 62144 83 Linux
image.le2 526336 1050623 262144 83 Linux

LFS201: Fundamentos de Administración de Sistemas Linux 135


5. Write the par//on table to disk and exit:

Command (m for help): w


The par//on table has been altered!

Syncing disks.

Si bien esta ha sido una buena prác/ca, aún no hemos visto una forma de u/lizar las
par/ciones que creamos recién. En el próximo ejercicio vamos a ver una forma que nos
permi/rá hacerlo.

LFS201: Fundamentos de Administración de Sistemas Linux 136


9.13 Laboratorio 9.3
Laboratorio 9.3: Uso de losetup y parted

Vamos a experimentar con:


 Disposi/vos Loop y losetup
 parted para trabajar con par/ciones desde la línea de comandos de forma no interac/va.

Es de nuestro interés que usted lea las páginas man de losetup y parted antes de realizar los
procedimientos que vienen a con/nuación.
Una vez más, usted puede reu/lizar el archivo de imagen, o mejor a´un, recrearlo para comenzar
con un archivo nuevo.
1. Asocie el archivo de imagen con un disposi/vo loop:

$ losetup -f
/dev/loop1
$ sudo losetup /dev/loop1 image.le

Donde el primer comando encuentra el primer disposi/vo loop libre. La razón para hacer esto es
que su sistema podría estar usando uno o más disposi/vos loop. Lo siguiente es ejecutado como
ejemplo en un sistema de pruebas, antes de crear el disposi/vo loop:

$ losetup -a
/dev/loop0: []: (/usr/src/KERNELS.sqfs)

un sistema de archivos comprimido de sólo lectura squashfs está montado y usando


/dev/loop0.

Nota: la salida del comando anterior puede variar en función de la distribución. Si ignoráramos lo
anterior y ejecutamos losetup en /dev/loop0 probablemente corromperiaamos el archivo.

2. Crear una e/queta de par/ción de disco en el disposi/vo loop (archivo de imagen):

$ sudo parted -s /dev/loop1 mklabel msdos

3. Crear tres par/ciones primarias en el disposi/vo loop:

$ sudo parted -s /dev/loop1 unit MB mkpart primary ext4 0 256


$ sudo parted -s /dev/loop1 unit MB mkpart primary ext4 256 512
$ sudo parted -s /dev/loop1 unit MB mkpart primary ext4 512 1024

LFS201: Fundamentos de Administración de Sistemas Linux 137


4. Veri.car la tabla de par/ciones:

$ fdisk -l /dev/loop1
Disk /dev/loop1: 1073 MB, 1073741824 bytes, 2097152 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/op/mal): 512 bytes / 512 bytes
Disk label type: dos
Disk iden/.er: 0x00050c11

Device Boot Start End Blocks Id System


/dev/loop1p1 1 500000 250000 83 Linux
/dev/loop1p2 500001 1000000 250000 83 Linux
/dev/loop1p3 1000001 2000000 500000 83 Linux

5. Lo que sucede a con/nuación dependerá en la distribución en la cual está trabajando. Por


ejemplo, en RHEL 7 y Ubuntu 14.04 notará que los nodos de disposi/vo nuevos han sido
creados:

$ ls -l /dev/loop1*
brw-rw---- 1 root disk 7, 1 Oct 7 14:54 /dev/loop1
brw-rw---- 1 root disk 259, 0 Oct 7 14:54 /dev/loop1p1
brw-rw---- 1 root disk 259, 3 Oct 7 14:54 /dev/loop1p2
brw-rw---- 1 root disk 259, 4 Oct 7 14:54 /dev/loop1p3

los que u/lizaremos a con/nuación. Sin embargo, en RHEL 6 los nodos no aparecerán. En
cambio, es necesario hacer lo siguiente:
$ sudo kpartx -lv /dev/loop1
$ sudo kpartx -av /dev/loop1
$ ls -l /dev/mapper/loop1*
lrwxrwxrwx 1 root root 7 Oct 9 07:12 /dev/mapper/loop1p1 -> ../dm-8
lrwxrwxrwx 1 root root 7 Oct 9 07:12 /dev/mapper/loop1p2 -> ../dm-9
lrwxrwxrwx 1 root root 8 Oct 9 07:12 /dev/mapper/loop1p3 -> ../dm-10

para asociar los nodos de disposi/vo con las par/ciones. En lo que sigue puede reemplazar
/dev/loop1p[1-3] con los nombres reales bajo /dev/mapper, o incluso más fácil, puede hacer
esto:
$ sudo ln -s /dev/mapper/loop1p1 /dev/loop1p1
$ sudo ln -s /dev/mapper/loop1p2 /dev/loop1p2
$ sudo ln -s /dev/mapper/loop1p3 /dev/loop1p3

LFS201: Fundamentos de Administración de Sistemas Linux 138


6. Darle formato a las par/ciones:

$ sudo mkfs.ext3 /dev/loop1p1


$ sudo mkfs.ext4 /dev/loop1p2
$ sudo mkfs.vfat /dev/loop1p3

7. Monte los tres sistemas de archivos y muestre que están disponibles:

$ mkdir mnt1 mnt2 mnt3


$ sudo mount /dev/loop1p1 mnt1
$ sudo mount /dev/loop1p2 mnt2
$ sudo mount /dev/loop1p3 mnt3

$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext4 29G 8.5G 19G 32% /
....
/dev/loop1p1 ext3 233M 2.1M 219M 1% mnt1
/dev/loop1p2 ext4 233M 2.1M 215M 1% mnt2
/dev/loop1p3 vfat 489M 0 489M 0% mnt3

8. Una vez que ha terminado de u/lizar los sistemas de archivos puede deshacer lo realizado con:

$ sudo umount mnt1 mnt2 mnt3


$ rmdir mnt1 mnt2 mnt3
$ sudo losetup -d /dev/loop0

LFS201: Fundamentos de Administración de Sistemas Linux 139


9.13 Laboratorio 9.4
Laboratorio 9.4: Par/cionado de un disco duro real

Si usted /ene un disco duro real con espacio disponible y que no está par/cionado, experimente
con fdisk para crear par/ciones nuevas, ya sean primarias o lógicas con una par/ción extendida.
Escriba la tabla de par/ciones nueva al disco y luego formatee y monte las par/ciones recién
creadas.

Objetivos de aprendizaje (Revisión)

Usted debería ser capaz de:


 Describir y contrastar los tipos más comunes de discos duros y buses de datos.
 Explicar cómo es la geometría de un disco y otros conceptos de particionamiento.
 Comprender cómo se les asigna el nombre a los dispositivos de disco y cómo
identificar los nodos de dispositivo asociados.
 Distinguir y seleccionar entre diferentes estrategias de particionamiento.
 Use utilities such as blkid and fdisk.
 Respaldar y restaurar tablas de partición.

LFS201: Fundamentos de Administración de Sistemas Linux 140


Capítulo 10. Cifrado de Discos

Los sistemas de archivos pueden ser cifrados para proteger la información de accesos
no autorizados y de intentos de corromper los datos que contienen. El cifrado puede ser
elegida en la instalación o ser incorporada más tarde. Las distribuciones de Linux usan a
menudo el método LUKS y llevan a cabo tareas de cifrado usando la herramienta
cryptsetup.

Objetivos de aprendizaje
Al final del capítulo usted debería ser capaz de:
 Proveer buenas razones para el uso de cifrado y saber cuándo se requiere.
 Entender cómo opera LUKS a través del uso de cryptsetup.
 Ser capaz de configurar y usar particiones y sistemas de archivos cifrados.
 Saber cómo configurar el sistema para montar particiones cifradas en el arranque.

LFS201: Fundamentos de Administración de Sistemas Linux 141


10.1 Por qué utilizar cifrado?

El cifrado de datos debería ser usado en cualquier lugar en donde hay información
sensible que está siendo almacenada y transmitida. La configuración y el uso de cifrado a
nivel de dispositivo de bloque es una de las protecciones más robustas contra los daños
producidos por pérdida o compromiso de información contenida en discos duros y otros
medios.

Las distribuciones de Linux modernas ofrecen la alternativa de cifrar todas o algunas de


las particiones durante la instalación. También es fácil crear y formatear particiones
cifradas posteriormente, pero no es posible cifrar una partición existente sin tener que
copiar los datos a ella.

10.2 Luks

Las distribuciones de Linux modernas proveen un cifrado a nivel de dispositivo de bloque


principalmente a través de LUKS (Linux Unified Key Setup). Usar este tipo de cifrado es
altamente recomendable para sistemas portátiles como laptops, tabletas y teléfonos
inteligentes.

LUKS está basado en cryptsetup, una herramienta potente que también puede usar
otros métodos como volúmenes dm-crypt (planos), loop-AES y formato compatible
con TrueCrypt. No vamos a discutir esas alternativas, ya que LUKS es el método
estándar y usado más a menudo en Linux (fue diseñado originalmente para Linux, pero
también ha sido exportado a otros sistemas operativos).

El módulo del kernel dm-crypt usa la infraestructura de device mapper del kernel, la cual
es usada también de forma importante en LVM, lo cual veremos más adelante.

Debido a que LUKS almacena toda la información necesaria en la cabecera de la


partición, es simple migrar particiones a otros discos o sistemas.

LUKS también puede ser usado para cifrar particiones de intercambio de forma
transparente.

10.3 crypsetup

Básicamente, todo se realiza con el programa cryptsetup. Una vez que los volúmenes han
sido cifrados, pueden ser montados y desmontados con las utilidades normales.
La sintaxis común de un comando es la siguiente:
cryptsetup [OPTION...] <action> <action-specific>

y una lista con todas las opciones puede ser generada con:
$ cryptsetup –help

LFS201: Fundamentos de Administración de Sistemas Linux 142


10.4 uso de una partición cifrada

Asumiendo que la partición LVM /dev/VG/MYSECRET ya existe, los siguientes comandos


configurarán el cifrado, la pondrán a disposición de LUKS, le darán formato, la usarán y
desmontarán.

Lo primero que se debe realizar es darle formato LUKS a la partición:

$ sudo cryptsetup luksFormat /dev/VG/MYSECRET

Se le pedirá ingresar una contraseña, la cual tendrá que usar para abrir el volumen cifrado
más tarde. Note que tendrá que hacer esto una vez solamente, durante la configuración
del cifrado.

Usted podría enfrentar ciertas dificultades si el kernel del sistema no soporta el método de
cifrado que usa cryptsetup por defecto. En ese caso usted puede
examinar /proc/crypto para ver los métodos que soporta el sistema, y luego especificar
uno, como se muestra a continuación:

$ sudo cryptsetup luksFormat—cipher aes /dev/VG/MYSECRET

Usted puede abrir el volumen en cualquier momento, con el siguiente comando:

$ sudo cryptsetup—verbose luksOpen /dev/VG/MYSECRET SECRET

tras lo cual se le pedirá ingresar la contraseña. Luego de eso es posible formatear el


sistema de archivos:

$ sudo mkfs.ext4 /dev/mapper/SECRET

Y montarlo:

$ sudo mount /dev/mapper/SECRET /mnt

A partir de este momento usted dispone de una partición sin cifrar montada en /mnt, con
la cual puede trabajar a su gusto. Cuando haya terminado de realizar las tareas en
cuestión, la puede desmontar de la siguiente forma:

$ sudo umount /mnt

luego remueva la asociación mapper por el momento (siempre podrá usar la partición
nuevamente):

$ sudo cryptsetup—verbose luksClose SECRET

LFS201: Fundamentos de Administración de Sistemas Linux 143


10.5 Montado en el arranque

Para montar una partición cifrada en el arranque hay que satisfacer dos condiciones:
1. Agregar una línea apropiada en /etc/fstab. No hay nada de especial en esta línea
y no se refiere al cifrado en ningún sentido.
2. Agregar una entrada a /etc/crypttab. Puede ser tan simple como esto:

SECRET /dev/mapper/MYSECRET

Usted puede hacer otras cosas en este archivo, como especificar la contraseña si no
desea ingresarla en el arranque (lo cual sería contraproducente para la seguridad del
sistema). Haga man crypttab para ver todo lo que puede hacer con este archivo.

Comprobación de conocimientos 10.1

LFS201: Fundamentos de Administración de Sistemas Linux 144


10.6 Laboratorio 6.1
Laboratorio 10.1: Cifrado de discos

En este ejercicio usted cifrará una par/ción en el disco para proveer de seguridad en caso de que
su disco duro o portá/l es robado. Revisar la documentación de cryptsetup antes de comenzar es
una buena idea (man cryptsetup y cryptsetup—help).
1. Cree una par/ción nueva para el disposi/vo de bloque cifrado con fdisk. Asegúrese que el
kernel está al tanto de la nueva tabla de par/ción. Un reinicio lo logrará, pero hay otros
métodos también.
2. Formatee la par/ción con cryptsetup usando LUKS para la capa de cifrado.
3. Cree la clave para abrir el disposi/vo de bloque cifrado.
4. Agregue una entrada a /etc/cryp@ab para que el sistema pregunte la clave en el reinicio.
5. Formatee el sistema de archivos con ext4.
6. Cree un punto de montaje para el sistema de archivos nuevo, por ejemplo /secret.
7. Agregue una entrada a /etc/fstab para que el sistema sea montado en el arranque.
8. Intente montar el sistema cifrado.
9. Reinicie y valide la con.guración completa.

LFS201: Fundamentos de Administración de Sistemas Linux 145


Solución 10.1

1. $ sudo fdisk /dev/sda

Cree una par/ción nueva (en el ejemplo trabajaremos con /dev/sda4) y luego ejecute:

$ sudo partprobe -s

para que el sistema relea la tabla de par/ción modi.cada, o reinicie (lo cual es lejos lo más
seguro).

Nota: Si no puede usar una par/ción real, use el método descrito en el capítulo anterior
para trabajar con un disposi/vo loop o un archivo de imagen.

2. $ sudo cryptsetup luksFormat /dev/sda4

3. $ sudo cryptsetup luksOpen /dev/sda4 secret-disk

4. Agregue lo siguiente a /etc/cryp@ab:

secret-disk /dev/sda4

5. $ sudo mkfs -t ext4 /dev/mapper/secret-disk

6. $ sudo mkdir -p /secret

7. Agregue lo siguiente a /etc/fstab:

/dev/mapper/secret-disk /secret ext4 defaults 1 2

8. Monte el sistema de archivos:

$ sudo mount /secret

o monte todos los sistemas de archivos mencionados en /etc/fstab:

$ sudo mount –a

9. Reinicie.

LFS201: Fundamentos de Administración de Sistemas Linux 146


10.6 Laboratorio 6.1
Laboratorio 10.2: Area de intercambio cifrada

En este ejercicio vamos a cifrar la par/ción de intercambio. La información escrita al disposi/vo de


intercambio puede contener información sensible. Debido a que el área de intercambio está sobre
una par/ción, es importante considerar las implicancias de seguridad que /ene una par/ción de
intercambio sin cifrar.

El proceso de cifrado es similar al del ejercicio previo, con la excepción de que no crearemos un
sistema de archivos en este disposi/vo de bloques cifrado.

En este caso vamos a usar el área de intercambio existente; primero la desac/varemos y luego
formateada para el uso como área de intercambio cifrada. Podrá ser un poco más seguro usar una
par/ción nueva, o también usar la par/ción que creó en el ejercicio previo. Al .nal explicaremos
qué hacer en caso de que tenga problemas para restablecer el sistema al punto original.

Vamos a discu/r la administración del área de intercambio en un capítulo posterior, pero de todas
formas mostraremos algunos comandos para trabajar con esta componente.

Una vez que haya terminado, puede volver a la par/ción original sin cifrar ejecutando el comando
mkswap en el disposi/vo.
1. Determine cuál es la par/ción que está usando actualmente para el área de intercambio y
desacmvela:

$ cat /proc/swaps

Filename Type Size Used Priority


/dev/sda11 par//on 4193776 0 -1
$ sudo swapod /dev/sda11

2. Realice los mismos pasos del ejercicio anterior para con.gurar el cifrado:

$ sudo cryptsetup luksFormat /dev/sda11 # may use—ciper aes op/on


$ sudo cryptsetup luksOpen /dev/sda11 swapcrypt
3. Formatee el disposi/vo cifrado para usarlo como área de intercambio:

$ sudo mkswap /dev/mapper/swapcrypt


4. Ahora ac/ve la par/ción y veri.que si está funcionando:

$ sudo swapon /dev/mapper/swapcrypt


$ cat /proc/swaps

LFS201: Fundamentos de Administración de Sistemas Linux 147


5. Para asegurarse que la par/ción de intercambio cifrada se ac/ve en el arranque, es necesario
hacer dos cosas:
1. Agregue una línea a /etc/cryp@ab para que el sistema pregunte por la clave en el
reinicio:
swapcrypt /dev/sda11 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256
(Note que /dev/urandom es preferido sobre /dev/random ya que podría estar
relacionado a entropy shortages, o problemas de rendimiento como se lee en la
página man de cryp@ab.)
No es necesario que siga las opciones detalladas que siguen a con/nuación, pero las
damos como ejemplo de lo que usted puede hacer.
2. Agregue una entrada al archivo /etc/fstab para que el disposi/vo de área de
intercambio sea ac/vado en el inicio.
/dev/mapper/swapcrypt none swap defaults 0 0
6. Reinicie y valide la con.guración completa.

Para restaurar el sistema al punto original:


$ sudo swapod /dev/mapper/swapcrypt
$ sudo cyyptsetup luksClose swapcrypt
$ sudo mkswap /dev/sda11
$ sudo swapon -a

Si el comando swapon falla, probablemente se debe a que el archivo /etc/fstab no describe


adecuadamente la par/ción de intercambio. No hay ningún problema si la par/ción está
descrita aquí por el disposi/vo actual (/dev/sda11). Puede resolverlo al cambiar la línea a:
/dev/sda11 swap swap defaults 0 0
otra alterna/va es asignarle una e/queta al instante del formateo, como se muestra aquí:
$ sudo mkswap -L SWAP /dev/sda11
y luego agréguelo al archivo:
LABEL=SWAP swap swap defaults 0 0

Objetivos de aprendizaje (Revisión)

Usted debería ser capaz de:


 Proveer buenas razones para el uso de cifrado y saber cuándo se requiere.
 Entender cómo opera LUKS a través del uso de cryptsetup.
 Ser capaz de configurar y usar particiones y sistemas de archivos cifrados.
 Saber cómo configurar el sistema para montar particiones cifradas en el arranque.

LFS201: Fundamentos de Administración de Sistemas Linux 148


Capítulo 11. Sistemas de archivos Linux y el VFS

Los sistemas Linux son capaces de usar una amplia variedad de sistemas de archivos.
Esta versatilidad se consigue a través de la capa de abstracción del Sistema de Archivos
Virtual (VFS), la cual se sitúa entre el software y el sistema de archivos en el disco. Los
sistemas de archivos transaccionales avanzados se han convertido en el estándar en las
distribuciones empresariales.

Objetivos de aprendizaje

Al final del capítulo usted debería ser capaz de:


 Explicar la organización básica de un sistema de archivos.
 Comprender el rol del VFS.
 Conocer qué sistemas de archivos están disponibles en Linux y cuáles son los
que pueden ser usados en su sistema actual.
 Comprender por qué los sistemas de archivos con journaling representan avances
importantes.
 Discutir el uso de sistemas de archivos especiales en Linux.

LFS201: Fundamentos de Administración de Sistemas Linux 149


11.1 Conceptos básicos de un sistema de archivos

Los programas necesitan leer y escribir archivos, en vez de tener que lidiar con los
lugares físicos en el hardware en el cual los archivos están almacenados.
Los archivos y sus nombres son una abstracción de la capa física de E/S. Escribir en el
disco de forma directa(ignorando la capa del sistema de archivos) es muy peligroso y se
realiza sólo por programas de bajo nivel del sistema operativo, nunca por una aplicación
de usuario.
Los sistemas de archivos locales generalmente residen en una partición de disco, la cual
puede ser una partición física en un disco o una partición lógica controlada por un Logical
Volume Manager (LVM). Los sistemas de archivos también pueden estar en la red, de tal
forma que el encapsulado físico queda totalmente oculto al sistema local.

11.2 Configuración del árbol del sistema de archivos

Todos los sistemas Linux usan una jerarquía de árbol invertido del directorio raíz (/).
Mientras que todo el árbol puede estar contenido en un sistema de archivos local en una
partición, usualmente hay varias particiones (o sistemas de archivos de red) trabajando de
forma unida en los puntos de montaje. Estos también pueden incluir medios extraíbles
como dispositivos USB, discos ópticos, etc.

Adicionalmente, algunos sistemas de archivos seudovirtuales (abstracciones útiles que


existen en memoria solamente) serán montadas en el árbol; estos
incluyen /proc, /sys, /dev y tal vez /tmp, como también /run.

Cada uno de los elementos montados en el árbol puede tener su propio tipo de sistema
de archivos. Pero ante las aplicaciones y el sistema operativo se muestra como una una
sola estructura de árbol unificado.

11.3 Virtual File System (VFS)

Linux implementa un Virtual File Sistem (VFS), sistema de archivos virtual), como lo
hacen todos los sistemas operativos modernos. Cuando una aplicación necesita acceder
a un archivo, ésta interactúa con la capa de abstracción del VFS, el cual traduce todas las
llamadas E/S (operaciones de lectura/escritura, etc) en código específico relacionado con
el sistema de archivos real en particular.

De esta forma, tanto el sistema de archivos real como el medio físico y hardware sobre el
cual reside, no necesitan ser considerados por las aplicaciones. Por otro lado, los
sistemas de archivos de red (como NFS) pueden ser manejados de forma transparente.

Esto permite a Linux trabajar con una variedad de sistemas de archivos mayor que
cualquier otro sistema operativo. Este atributo ha sido un factor importante en su éxito.

LFS201: Fundamentos de Administración de Sistemas Linux 150


La mayoría de los sistemas de archivos tienen acceso de lectura y escritura completo,
mientras que otros sólo tienen acceso a lectura y tal vez de escritura de tipo experimental.
Algunos tipos de sistemas de archivos - especialmente aquellos que no están basados
en UNIX - pueden requerir mayor manipulación para ser representados en el VFS.

Variantes como vfat no diferencias permisos de lectura/escritura/ejecución para los


campos dueño/grupo/todos; el VFS tiene que suponer cómo especificar diferentes
permisos para los tres tipos de usuarios, y tal asunto puede tener influencia en las
operaciones de montaje. Existen implementaciones que no basan su soporte en el
sistema de archivos del kernel, como el de lectura/escritura ntfs-
3g (http://www.tuxera.com/community/ntfs-3g-download), el cual si bien es cierto es
confiable, tiene un rendimiento menor que aquellos sistemas de archivos con soporte en
el kernel.

LFS201: Fundamentos de Administración de Sistemas Linux 151


11.4 Sistemas de archivos disponibles

LFS201: Fundamentos de Administración de Sistemas Linux 152


11.5 Sistemas de archivos transaccionales

Una serie de nuevos sistemas de archivos de alto rendimiento incluyen la capacidad


de journaling completo.
Los sistemas de archivos con journaling se recuperan muy rápidamente de
crashes/congeladas o caídas con poco o nada de corrupción. Si bien esto tiene el costo
de tener que realizar más operaciones, las mejoras adicionales pueden compensar el
costo con creces.
En un sistema de archivos con journaling las operaciones se agrupan en transacciones.
Una transacción debe ser llevada a cabo sin errores, de forma completa, ya que de otra
manera el sistema de archivos no es modificado. Se mantiene un archivo de registro para
las transacciones. Cuando ocurre un error, por lo general sólo la última transacción
necesita ser examinada.
Los siguientes sistemas de archivos con journaling están disponibles de forma libre
en Linux:
 ext3 fue una extensión del sistema de archivos anterior ext2, el cual no tenía
journaling.

 ext4 es un avance significativo derivado de ext3. Las características incluyen


extents, bloques de 48 bits y de hasta 16 TB de tamaño. La mayoría de las
distribuciones de Linux han usado ext4 como el sistema de archivos por defecto
por varios años a la fecha.

 reiserfs fue la primera implementación de journaling usada en Linux, pero perdió


su liderazgo y su desarrollo fue abandonado.

 JFS fue originalmente un producto de IBM y fue portado desde el sistema


operativo AIX.

 XFS originalmente fue un producto de SGI y se portó desde el sistema


operativo IRIX. RHEL 7 adoptó a XFS como su sistema de archivos por defecto.

 btrfs es el sistema de archivos con journaling más nuevo y todavía está bajo un
desarrollo fuerte y rápido.

LFS201: Fundamentos de Administración de Sistemas Linux 153


11.6 Sistemas de archivos soportados en el sistema local

Usted puede ver una lista de los tipos de sistemas de archivos soportados por el
kernel Linux en ejecución con el siguiente comando:
$ cat /proc/filesystems

nodev sysfs
nodev rootfs
nodev ramfs
nodev bdev
nodev proc
nodev cgroup
nodev cpuset
nodev tmpfs
nodev devtmpfs
nodev binfmt_misc
nodev debugfs
nodev sockfs
nodev pipefs
nodev devpts
squashfs
nodev hugetlbfs
iso9660
nodev mqueue
ext3
ext2
ext4
fuseblk
nodev fuse
nodev fusectl
nodev autofs
nodev rpc_pipefs
nodev nfsd

Note que para algunos tipos de sistemas de archivos adicionales, el código de soporte
puede ser cargado sólo cuando el sistema trata de acceder la partición que los contiene.

11.7 Sistemas de archivos especiales

Linux hace un uso amplio de sistemas de archivos especiales para ciertas tareas.
Estos son particularmente útiles para acceder varias estructuras de datos y ajustes de
rendimiento del kernel, o para implementar funciones específicas.

LFS201: Fundamentos de Administración de Sistemas Linux 154


Note que algunos de esos sistemas de archivos especiales no tienen punto de montaje;
esto significa que las aplicaciones de usuario no interactúan con ellos, pero el kernel lo
hace, tomando ventaja de las capas y el código del VFS.

Comprobación de conocimientos 11.1

LFS201: Fundamentos de Administración de Sistemas Linux 155


Comprobación de conocimientos 11.2

LFS201: Fundamentos de Administración de Sistemas Linux 156


11.8 Laboratorio 11.1
Laboratorio 11.1: El sistema de archivos especial tmpfs

tmpfs es uno de muchos sistemas de archivos especiales usados en Linux. Algunos de estos no son
usados realmente como sistemas de archivos, pero toman ventaja de la capa de abstracción que
poseen. Sin embargo, tmpfs es un sistema de archivos real sobre el cual las aplicaciones pueden
realizar operaciones de E/S.

Esencialmente, tmpfs opera como ramdisk; reside completamente en memoria. Pero /ene algunas
caracterís/cas interesantes que las implementaciones convencionales y an/guas de ramdisk no
tenían:
1. El sistema de archivos ajusta su tamaño ( The .lesystem adjusts its size (y por lo tanto la
memoria que se usa) dinámicamente; parte en cero y se expande tanto como sea
necesario hasta el tamaño máximo de la par/ción en la que está montada.

2. Si la RAM se agota, tmpfs puede u/lizar espacio del área de intercambio. De todas formas
no es posible poner más en el sistema de archivos de la capacidad máxima que soporta.

3. tmpfs no requiere tener un sistema de archivos normal, tales como ext3 o vfat; posee sus
métodos propios para lidiar con archivos y operaciones de E/S, los cuales están conscientes
de que es sólo espacio en memoria (y que en realidad no es un disposi/vo de bloque), y
como tal está op/mizado para velocidad. Por lo tanto no hay necesidad de preformatear el
sistema de archivos con el comando mkfs ; simplemente hay que montarlo y usarlo.

Monte una instancia nueva de tmpfs en cualquier lugar en su estructura de directorios, con un
comando como el siguiente:
$ sudo mkdir /mnt/tmpfs
$ sudo mount -t tmpfs none /mnt/tmpfs

Vea cuánto espacio se le ha asignado al sistema de archivos y cuánto está usando:


$ df -h /mnt/tmpfs
Debería notar que se le ha asignado un valor por defecto de la mitad de la RAM del sistema; sin
embargo, el uso es cero, y sólo comenzará a crecer en espacio u/lizado en la medida de que se
ponen archivos en /mnt/tmpfs. Es posible cambiar el tamaño asignado como una opción a la hora
de montarlo:
$ sudo mount -t tmpfs -o size=1G none /mnt/tmpfs

LFS201: Fundamentos de Administración de Sistemas Linux 157


Podría intentar llenarlo hasta que se alcance la capacidad máxima y luego vea qué sucede. No
olvide desmontarlo una vez que haya terminado las pruebas, con el comando:

$ sudo umount /mnt/tmpfs

Prác/camente todas las distribuciones modernas de Linux montan una instancia de tmpfs en
/dev/shm:

$ df -h /dev/shm
Filesystem Type Size Used Avail Use% Mounted on
Tmpfs tmpfs 3.9G 24M 3.9G 1% /dev/shm

Muchas aplicaciones hacen esto en casos como cuando se usa memoria compar/da POSIX como
un mecanismo de comunicación interprocesos. Cualquier usuario puede crear, leer y escribir
archivos en /dev/shm, por lo que es un buen lugar para crear archivos temporales en memoria.
Cree algunos archivos en /dev/shm y observe con df cómo el sistema de archivos se va llenando.
Adicionalmente, muchas distribuciones montan instancias múl/ples de tmpfs; por ejemplo, se
observa lo siguiente en un sistema RHEL 7:
$ df -h | grep tmpfs
devtmpfs devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs tmpfs 3.9G 24M 3.9G 1% /dev/shm
tmpfs tmpfs 3.9G 9.2M 3.9G 1% /run
tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/tmp/vmware-coop/564d9ea7-8e8e-29c0-2682-e5d3de3a51d8 tmpfs 3.3G 0 3.3G 0%
/tmp/vmware-coop/564d9ea7-8e8e-29c0-2682-e5d3de3a51d8 /tmp/vmware-
coop/564d7668-ec55-ee45-f33e-c8e97e956190 tmpfs 2.3G 2.0G 256M 89%
/tmp/vmware-coop/ 564d7668-ec55-ee45-f33e-c8e97e956190

none tmpfs 1.0G 1.0G 0 100% /tmp/ohno

Note que el comando anterior fue ejecutado en un sistema con 8GB de RAM, por lo cual usted
probablemente no tendrá todos esos sistemas de archivos tmpfs usando los 4 GB con los cuales
han sido asignados.
Algunas distribuciones como Fedora podrían montar por defecto /tmp como un sistema tmpfs; en
estos casos uno podría evitar poner archivos grandes en /tmp para que el sistema no se quede sin
memoria. Otra posibilidad es deshabilitar ese comportamiento, como se mencionó anteriormente
al describir /tmp.

LFS201: Fundamentos de Administración de Sistemas Linux 158


Objetivos de aprendizaje (Revisión)

Actualmente usted debería ser capaz de:


 Explicar la organización básica de un sistema de archivos.
 Comprender el rol del VFS.
 Conocer qué sistemas de archivos están disponibles en Linux y cuáles son los
que pueden ser usados en su sistema actual.
 Comprender por qué los sistemas de archivos con journaling representan avances
importantes.
 Discutir el uso de sistemas de archivos especiales en Linux.

LFS201: Fundamentos de Administración de Sistemas Linux 159


Capítulo 12. Características de los sistemas de
archivos: atributos, creación, verificación,
montado

Las características importantes de los sistemas de archivos incluyen inodos, archivos de


directorio y tanto enlaces simbólicos (soft) como duros (hard). Los atributos extendidos
amplían los permisos de archivos tradicionales de UNIX. Existen utilidades específicas
asociadas a los sistemas de archivos que realizan tareas como crearlos y darles formato,
comprobar si hay errores y repararlos. También montar y desmontar los sistemas de
archivos durante el arranque o en un momento posterior.

Objetivos de aprendizaje

Al final del capítulo usted debería ser capaz de:


 Estar familiarizado con conceptos tales como inodos, archivos de directorios y
atributos extendidos.
 Crear y formatear sistemas de archivos.
 Verificar y reparar errores en sistemas de archivos.
 Montar y desmontar sistemas de archivos.

LFS201: Fundamentos de Administración de Sistemas Linux 160


12.1 Inodos

Figura 12.1: Almacenamiento de datos en un inodo vs almacenamiento de datos en


un archivo de directorio
Un inodo es una estructura de datos en el disco que describe y almacena los atributos del
archivo, incluyendo su localización. Cada archivo está asociado con su propio inodo. La
información almacenada en el inodo incluye lo siguiente:
 Permisos
 Usuario y grupo propietario
 Tamaño
 Registros de tiempo (al nanosegundo)
 Momento en el cual se realizó el último acceso
 Momento en el cual se realizó la última modificación del contenido
 Momento en el cual se realizó la última modificación del inodo

Nota: los nombres de los archivos no se almacenan en el inodo asociado al archivo, sino
que lo hacen en el archivo de directorio.
Toda la actividad E/S concerniente a un archivo usualmente involucra el inodo del archivo
como información que debe ser actualizada.

LFS201: Fundamentos de Administración de Sistemas Linux 161


12.2 Archivos de directorio
Un archivo de directorio es un tipo de archivo en particular, el cual es usado para
asociar nombres de archivo a inodos. Hay dos formar de asociar (o enlazar) un nombre de
archivo con un inodo:
 Con enlaces duros, que apuntan a un inodo.
 Con enlaces simbólicos, los cuales apuntan a un nombre de archivo el cual
tiene un inodo asociado.

Cada asociación de un contenido de los archivos de directorio y un inodo es conocido


como un enlace. Enlaces adicionales pueden ser creados usando el comando ln.
Debido a que es posible (y muy común) que dos o más entradas de directorio apunten al
mismo inodo (enlaces duros), un archivo puede ser conocido por múltiples nombres, en
los que cada uno de ellos tiene su propio lugar en la estructura de directorios. Sin
embargo, puede tener un inodo solamente, sin importar qué nombre está siendo usado.
Cuando un proceso se refiere a un nombre de ruta, el kernel busca directorios para
encontrar el número de inodo correspondiente. Luego de que el nombre ha sido
convertido a un número de inodo, el inodo se carga en memoria y es usado en solicitudes
posteriores.

12.3 Atributos extendidos y lsattr/chattr

Los atributos extendidos asociados a los metadatos no son interpretados directamente


por el sistema de archivos. Existen cuatro espacios de nombres (namespaces): usuario,
de confianza, seguridad y sistema. Más adelante veremos que el espacio de nombres
sistema es usado por las listas de control de acceso (ACLs) y el espacio de nombres
seguridad es usado por SELinux.
Los valores de los atributos son almacenados en el inodo de archivo y pueden ser
modificados y configurados sólo por el usuario root. Se visualizan con lsattr y configuran
con chattr.
En el espacio de nombres de usuario, las siguientes banderas pueden ser configuradas
en los archivos:
 i: inmutable
Un archivo con el atributo de inmutabilidad (i) no puede ser modificado (ni siquiera
por root). No puede ser borrado o renombrado. No se puede crear un link duro a él
y no es posible escribir datos al archivo. Sólo el superusuario puede configurar o
eliminar este atributo.
 a: agregar solamente
Un archivo con el atributo de agregar solamente (a) puede ser abierto en modo
agregar para escritura solamente. Sólo el superusuario puede configurar o eliminar
este atributo.
 d: no respaldar

LFS201: Fundamentos de Administración de Sistemas Linux 162


Un archivo con el atributo no respaldar (d) es ignorado cuando el
programa dump se
ejecuta. Esto es útil para el área de intercambio y archivos de caché que no se
desean respaldar.
 A: No actualizar atime
Un archivo con el atributo no-atime-update (A) no modificará su registro atime
(tiempo de acceso) cuando el archivo es accesado pero no modificado. Esto puede
incrementar el rendimiento en algunos sistemas debido a que reduce la cantidad
de actividad de E/S del disco.

Note que hay otros atributos que se pueden configurar: al ejecutar man chattr se
mostrará la lista completa. El formato para chattr es el siguiente:

$ chattr [+|-|=mode] filename

lsattr se usa para desplegar los atributos de un archivo:

$ lsattr filename

12.4 Crear y formatear sistemas de archivos

Cada tipo de sistema de archivos tiene una herramienta para formatear un sistema de
archivos en una partición. El nombre genérico para esas utilidades es mkfs. Sin embargo
es sólo una interfaz para los programas del sistema de archivos específico:

$ ls -lh /sbin/mkfs*
rwxr-xr-x 1 root root 11K Apr 10 03:50 /sbin/mkfs
-rwxr-xr-x 1 root root 181K Oct 15 2012 /sbin/mkfs.btrfs
-rwxr-xr-x 1 root root 26K Apr 10 03:50 /sbin/mkfs.cramfs
-rwxr-xr-x 5 root root 68K Jul 16 15:31 /sbin/mkfs.ext2
-rwxr-xr-x 5 root root 68K Jul 16 15:31 /sbin/mkfs.ext3
-rwxr-xr-x 5 root root 68K Jul 16 15:31 /sbin/mkfs.ext4
-rwxr-xr-x 5 root root 68K Jul 16 15:31 /sbin/mkfs.ext4dev
lrwxrwxrwx 1 root root 7 Dec 6 2011 /sbin/mkfs.msdos -> mkdosfs
lrwxrwxrwx 1 root root 12 Sep 28 2011 /sbin/mkfs.nSs -> /sbin/mknSs
lrwxrwxrwx 1 root root 7 Dec 6 2011 /sbin/mkfs.vfat -> mkdosfs

Por tanto, los dos comandos de a continuación son completamente equivalentes:


$ sudo mkfs -t ext4 /dev/sda10
$ sudo mkfs.ext4 /dev/sda10

El formato general para mkfs es el siguiente:


mkfs [-t fstype] [options] [device-file]
donde [device-file] es generalmente un nombre de dispositivo
como /dev/sda3 o /dev/vg/lvm1.
LFS201: Fundamentos de Administración de Sistemas Linux 163
LFS201: Fundamentos de Administración de Sistemas Linux 164
Cada tipo de sistema de archivos tiene sus propias opciones que pueden ser configuradas
en el proceso de formateo. Por ejemplo, cuando se crea un sistema de archivos ext4, un
asunto para considerar es la configuración del journaling. Estos incluyen el tamaño de
archivo del journal y si se utilizará o no un archivo de journal externo.
Es necesario revisar la página man de cada uno de los programas mkfs.* para ver los
detalles.

12.5 Verificar y reparar sistemas de archivos

Cada tipo de sistema de archivos tiene una utilidad diseñada para verificar errores (y en lo
posible repararlos, en caso que se encuentren). El nombre genérico para esas
herramientas es fsck. Sin embargo esto es sólo una interfaz para los programas
específicos de cada sistema de archivos:

$ ls -l /sbin/fsck*
-rwxr-xr-x 1 root root 34680 Apr 10 03:50 /sbin/fsck
-rwxr-xr-x 1 root root 15976 Apr 10 03:50 /sbin/fsck.cramfs
rwxr-xr-x 5 root root 197352 Jul 16 15:31 /sbin/fsck.ext2
-rwxr-xr-x 5 root root 197352 Jul 16 15:31 /sbin/fsck.ext3
-rwxr-xr-x 5 root root 197352 Jul 16 15:31 /sbin/fsck.ext4
-rwxr-xr-x 5 root root 197352 Jul 16 15:31 /sbin/fsck.ext4dev
lrwxrwxrwx 1 root root 7 Dec 6 2011 /sbin/fsck.msdos -> dosfsck
lrwxrwxrwx 1 root root 13 Sep 28 2011 /sbin/fsck.ntfs ->
../bin/ntfsck
lrwxrwxrwx 1 root root 7 Dec 6 2011 /sbin/fsck.vfat -> dosfsck

Por tanto, los dos comandos de a continuación son completamente equivalentes:

$ sudo fsck -t ext4 /dev/sda10


$ sudo fsck.ext4 /dev/sda10

fsck se ejecuta automáticamente luego de un número de montajes o un intervalo desde la


última vez que fue ejecutado, o luego de un apagado anormal. Debería ser ejecutado en
sistemas de archivos sin montar.
Usted puede forzar una verificación de todos los sistemas montados en el próximo
arranque con los siguientes comandos:
$ sudo touch /forcefsck
$ sudo reboot

El archivo /forcefsck desaparecerá luego de que la verificación sea exitosa. Esta forma
de verificación es muy útil, ya que permite ejecutar fsck en el sistema de archivos root, lo
cual es muy difícil de realizar en un sistema que está corriendo.

El formato general de fsck es el siguiente:

LFS201: Fundamentos de Administración de Sistemas Linux 165


fsck [-t fstype] [options] [device-file]

donde [device-file] es generalmente un nombre de dispositivo


como /dev/sda3 o /dev/vg/lvm1. Usualmente no es necesario especificar el tipo de
sistema de archivo, ya que fsck puede detectarlo a través de examinar los superbloques
al comienzo de la partición.

Es posible controlar si los errores encontrados deben repararse uno a uno manualmente
con la opción -r, o automáticamente de la mejor forma posible usando la opción -a.
Adicionalmente, cada tipo de sistema de archivo puede tener sus propias opciones
particulares que pueden ser configuradas al momento de la verificación.

Note que los sistemas de archivos con journaling son mucho más rápidos para verificar
que los sistemas de archivos de generaciones anteriores por dos razones:

 Raramente es necesario escanear la partición completa para buscar errores, ya


que todo - con excepción de la última transacción - ha sido registrado y
confirmado, por lo cual se requiere muy poco tiempo para verificar.

 Incluso si uno verifica el estado del sistema de archivos completo, los sistemas de
archivos nuevos han sido diseñados con fsck rápido; de hecho los sistemas de
archivos antiguos no consideraron este tema cuando fueron diseñados, debido a
que los tamaños eran mucho más pequeños.

Para ver los detalles de los programas fsck.* vea la página man de cada uno.

12.6 Montar y desmontar sistemas de archivos

Todos los archivos accesibles en Linux están organizados en una gran estructura de
árbol jerárquica con la parte superior del mismo en el directorio root ( / ). Sin embargo, es
común tener más de una partición (cada una de las cuales puede tener su propio tipo de
sistema de archivos), las que trabajan juntas en el mismo árbol de sistema de archivos.
Estas particiones pueden estar en diferentes dispositivos físicos, o incluso localizadas en
una red.

El programa mount permite montar un sistema de archivos en cualquier punto de la


estructura de árbol; por el contrario,umount permite desmontarlo.

El punto de montaje corresponde al directorio donde el sistema de archivos está


montado. Este debe existir con anterioridad a que mount pueda usarlo; el
comando mkdir puede ser usado para crear un directorio vacío. Si un directorio
preexistente es usado para tal efecto y contiene archivos previamente al ser usado como
punto de montaje, los archivos se ocultarán al momento del montaje. Estos archivos no
son borrados y estarán visibles nuevamente cuando el sistema de archivos es
desmontado.

LFS201: Fundamentos de Administración de Sistemas Linux 166


Sólo el superusuario puede montar y desmontar sistemas de archivos.
12.7 mount

Cada sistema de archivos es montado bajo un directorio específico, como en el caso que
se muestra a continuación:

$ sudo mount -t ext4 /dev/sdb4 /home

 Monta un sistema de archivos ext4.

 El sistema de archivos está localizado en una partición específica del disco duro
(/dev/sdb4).

 El sistema de archivos está montado en la posición /home en el árbol de


directorios actual.

 Cualquier archivo que esté en el directorio original /home estará oculto hasta que
la partición se desmonte.

Note que en este ejemplo el sistema de archivos es montado utilizando el nodo de


dispositivo sobre el que reside. Sin embargo, también es posible montarlo usando
una etiqueta o un UUID. Por lo tanto, los siguientes comandos son todos equivalentes:

$ sudo mount /dev/sda2 /home


$ sudo mount LABEL=home /home
$ sudo mount -L home /home
$ sudo mount UUID=26d58ee2-9d20-4dc7-b6ab-aa87c3cfb69a /home
$ sudo mount -U 26d58ee2-9d20-4dc7-b6ab-aa87c3cfb69a /home

Las etiquetas son asignadas por utilidades específicas de cada tipo de sistema de
archivos, tal como e2label. Los UUIDs se asignan cuando las particiones son creadas
como contenedores para el sistema de archivos.
Mientras cualquiera de estos tres métodos para especificar el dispositivo puede ser
usado, los sistemas modernos desestiman el uso del nodo de dispositivo debido a que los
nombres pueden cambiar de acuerdo a cómo el sistema arranca, qué discos duros son
encontrados primero, etc. Las etiquetas son una mejora, pero en raras ocasiones se
podría tener dos particiones que se muestran con la misma etiqueta. Los UUIDs, sin
embargo, siempre deberían ser únicos y son creados cuando las particiones se crean.

LFS201: Fundamentos de Administración de Sistemas Linux 167


12.8 Opciones de mount

mount tiene muchas opciones, algunas genéricas como -a (lo cual monta todos los
sistemas de archivos mencionados en /etc/fstab) y muchas que son específicas al sistema
de archivos; de hecho, mount tiene una página man muy larga. Un ejemplo común sería
el siguiente:

$ sudo mount -o remount,ro /myfs

lo cual montaría nuevamente un sistema de archivos con un atributo de sólo lectura.


A continuación se muestra cómo obtener un resumen rápido de las opciones de mount:

$ mount—help
Usage:
mount [-lhV]
mount -a [options]
mount [options] [--source] <source> | [--target] <directory>
mount [options] <source> <directory>
mount <operation> <mountpoint> [<target>]

Options:
-a, --all mount all filesystems mentioned in fstab
-c, --no-canonicalize don’t canonicalize paths
-f, --fake dry run; skip the mount(2) syscall
-F, --fork fork off for each device (use with -a)
-T, --fstab <path> alternative file to /etc/fstab
-h, --help display this help text and exit
-i, --internal-only don’t call the mount.<type> helpers
-l, --show-labels lists all mounts with LABELs
-n, --no-mtab don’t write to /etc/mtab
-o, --options <list> comma-separated list of mount options
-O, --test-opts <list> limit the set of filesystems (use with -a)
-r, --read-only mount the filesystem read-only (same as -o ro)
-t, --types <list> limit the set of filesystem types—source <src>
explicitly specifies source (path, label, uuid)
--target <target> explicitly specifies mountpoint
-v, --verbose say what is being done
-V, --version display version information and exit
-w, --rw, --read-write mount the filesystem read-write (default)
-h, --help display this help and exit
-V, --version output version information and exit
.....

LFS201: Fundamentos de Administración de Sistemas Linux 168


12.9 umount

Los sistemas de archivos pueden ser desmontados de la siguiente forma:

$ umount [device-file | mount-point]

A continuación hay un par de ejemplos de cómo desmontar un sistema de archivos:

 Desmontar el sistema de archivos /home :

$ sudo umount /home

 Desmontar el dispositivo /dev/sda3 :

$ sudo umount /dev/sda3

Tenga en cuenta que el comando para desmontar un sistema de archivos es


umount (¡no unmount!).
Tal como mount, umount tiene muchas opciones, muchas de las cuales son específicas
al tipo de sistema de archivos. Nuevamente, las páginas man son la mejor fuente para
obtener las opciones específicas.
El error más común que se encuentra al desmontar un sistema de archivos es tratar de
hacerlo en un sistema de archivos que está en uso actualmente; es decir, hay
aplicaciones usando archivos u otras entradas en el sistema de archivos.
Esto puede ser tan simple como tener una terminal abierta en un directorio en el sistema
de archivos montado. Tan solo haciendo cd en esa ventana o cerrándola, solucionará el
error del dispositivo que está en uso y se permitirá desmontarlo.
Sin embargo, si hay otros procesos induciendo ese error, deberá cerrarlos antes de poder
desmontar el sistema de archivos. Usted puede usar fuser para encontrar qué usuarios
están usando el sistema de archivos y detener sus procesos (sea cuidadoso con esto, tal
vez sea buena idea informar a los usuarios antes de hacerlo). También se puede
usar lsof (“lista de archivos abiertos”) para ver qué archivos están siendo utilizados y que
están bloqueando el desmontado.

LFS201: Fundamentos de Administración de Sistemas Linux 169


12.10 Montar sistemas de archivos en el arranque

Durante el arranque del sistema se ejecuta el comando mount -a. Esto monta todos los
sistemas de archivos listados en el archivo de configuración /etc/fstab. Las entradas
pueden referirse a sistemas de archivos locales o remotos, montados a través de la red.

A continuación hay un ejemplo mostrando cómo montar todos los sistemas de archivos
listados en el archivo de configuración /etc/fstab durante el arranque del sistema:

$ cat /etc/fstab
LABEL=RHEL6-64 / ext4 defaults 1 1
LABEL=RHEL6-32 /RHEL6-32 ext4 defaults 1 2
LABEL=boot /boot ext3 defaults 1 2
....
LABEL=local /usr/local ext4 defaults 1 2
LABEL=tmp /tmp ext4 defaults 1 2
LABEL=src /usr/src ext4 defaults 1 2
LABEL=VIRTUAL /VIRTUAL ext4 defaults 1 2
LABEL=BEAGLE /BEAGLE ext4 defaults 1 2
/dev/sda1 /c ntfs-3g uid=500,gid=500 0 0
/teaching/FTP/LFT /var/ftp/pub2 none bind 0 0
laptop:/share /share nfs defaults 0 0
LABEL=SWAP swap swap defaults 0 0
Tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=6200 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
debugfs /sys/kernel/debug debugfs defaults 0 0

Este archivo muestra qué sistemas de archivos serán montados en el arranque y dónde
pueden encontrarse en el sistema local o en la red. Puede especificar quién podría
montarlos y con qué permisos, y otras opciones relevantes. Algunas de esas líneas se
refieren a seudosistemas de archivos especiales como proc, sys y devpts.

Cada registro en el archivo contiene campos separados por espacios en blanco, listando
lo siguiente:

 Dispositivo de nodo, etiqueta o UUID. Para sistemas de archivos que no tienen un


nodo de dispositivo, como tmpfs, proc y sysfs, este campo es un marcador de
posición solamente; a veces verá la palabra none en la columna.
 Punto de montaje. Esto también puede ser un marcador de posición solamente,
como en el caso de swap, el cual no está montado en ninguna parte.
 Tipo de sistema de archivos.
 Una lista de opciones separadas por coma.
 Frecuencia de dump (o un cero), usado por el comando dump -w.
 fsck pass, número de verificación (o 0, lo cual significa que no se comprueba el
estado en el arranque).

LFS201: Fundamentos de Administración de Sistemas Linux 170


Las herramientas mount y umount pueden usar la información que se encuentra
en /etc/fstab; en este caso podríamos hacer lo siguiente (usando la información del
ejemplo anterior)
$ sudo mount /usr/src

en vez de
$ sudo mount LABEL=src /usr/src

12.11 Lista de los sistemas de archivos montados actualmente

La lista de sistemas de archivos montados actualmente puede ser vista ejecutando el


siguiente comando:
$ mount

/dev/sda5 on / type ext4 (rw)


proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/sda6 on /RHEL6-32 type ext4 (rw)
/dev/sda2 on /boot_master type ext4 (rw)
/dev/mapper/VG-tmp on /tmp type ext4 (rw)
/dev/mapper/VG-local on /usr/local type ext4 (rw)
/dev/mapper/VG-src on /usr/src type ext4 (rw)
/dev/mapper/VG-audio on /AUDIO type ext4 (rw)
/dev/mapper/VG-pictures on /PICTURES type ext4 (rw)
/dev/mapper/VG-dead on /DEAD type ext4 (rw)
/dev/mapper/VG-virtual on /VIRTUAL type ext4 (rw)
/dev/mapper/VG-virtual2 on /VIRTUAL2 type ext4 (rw)
/dev/mapper/VG-virtual3 on /VIRTUAL3 type ext4 (rw)
/dev/mapper/VG-iso_images on /ISO_IMAGES type ext4 (rw)
/usr/local/FTP on /var/ftp/pub type none (rw,bind)

/usr/src/KERNELS.sqfs on /usr/src/KERNELS type squashfs


(rw,loop=/dev/loop0)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

vmware-vmblock on /var/run/vmblock-fuse type fuse.vmware-vmblock


(rw, nosuid, nodev, default_permissions, allow_other)

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

nfsd on /proc/fs/nfsd type nfsd (rw)

LFS201: Fundamentos de Administración de Sistemas Linux 171


Comprobación de conocimientos 12.1

Comprobación de conocimientos 12.2

LFS201: Fundamentos de Administración de Sistemas Linux 172


12.12 Laboratorio 12.1
Laboratorio 12.1: Trabajo con atributos de archivo
1. Con su cuenta de usuario normal use touch para crear un archivo vacío llamado
/tmp/appendit.
2. Use cat para agregar el contenido de /etc/hosts a /tmp/appendit.
3. Compare los contenidos de /tmp/appendit con /etc/hosts; no debería exis/r ninguna
diferencia.
4. Intente agregar el atributo agregar solamente a /tmp/appendit usando chaTr. Debería
obtener un error. ¿A qué se debe esto?
5. Como root, intente agregar el atributo agregar solamente; esta vez debería funcionar. Eche
un vistazo a los atributos extendidos del archivo usando lsaTr.
6. Como usuario normal intente copiar con cat el contenido de /etc/passwd a /tmp/appendit.
Debería obtener un error, ¿a qué se debe?
7. Intente lo mismo esta vez como root. También debería obtener un error. ¿Por qué?
8. Como usuario normal, use el operador de redirección para agregar (>>) e intente agregar el
contenido del archivo /etc/passwd a /tmp/appendit. Esta vez debería funcionar. Examine el
archivo para con.rmar.
9. Como root, con.gure el atributo de inmutabilidad sobre /tmp/appendit, y liste los
atributos extendidos nuevamente.
10. Intente agregar contenido a /tmp/appendit. Intente renombrar el archivo, crear un enlace
duro al mismo e incluso borrarlo como usuario normal y como root.
11. Es posible eliminar el archivo si se remueven los atributos extendidos. Hágalo por favor.

Solución 12.1
1. $ cd /tmp
$ touch appendit
$ ls -l appendit

 rw-rw-r-- 1 coop coop 0 Oct 23 19:04 appendit

2. $ cat /etc/hosts > appendit


3. $ did /etc/hosts appendit
4. $ cha@r +a appendit
cha@r: Opera/on not permi@ed while senng jags on appendit
5. $ sudo cha@r +a appendit
$ lsa@r appendit
-----a-------e—appendit

6. $ cat /etc/passwd > appendit


bash: appendit: Opera/on not permi@ed
7. $ sudo su
$ cat /etc/passwd > appendit
bash: appendit: Opera/on not permi@ed $ exit

8. $ cat /etc/passwd >> /tmp/appendit

LFS201: Fundamentos de Administración de Sistemas Linux 173


$ cat appendit
9. $ sudo cha@r +i appendit
$ lsa@r appendit
----ia-------e- appendit

10. $ echo hello >> appendit


• bash: appendit: Permission denied
$ mv appendit appendit.rename
mv: cannot move ‘appendit’ to ‘appendit.rename’: Opera/on not permi@ed
$ ln appendit appendit.hardlink
ln: crea/ng hard link ‘appendit.hardlink’ => ‘appendit’: Opera/on not permi@ed
$ rm -f appendit
rm: cannot remove ‘appendit’: Opera/on not permi@ed
$ sudo su
$ echo hello >> appendit
• bash: appendit: Permission denied
$ mv appendit appendit.rename
mv: cannot move ‘appendit’ to ‘appendit.rename’: Opera/on not permi@ed
$ ln appendit appendit.hardlink ln: crea/ng hard link ‘appendit.hardlink’ => ‘appendit’:
Opera/on not permi@ed
$ rm -f appendit rm: cannot remove ‘appendit’: Opera/on not permi@ed
$ exit
11. $ sudo su
$ lsa@r appendit
----ia-------e- appendit
$ cha@r -ia /appendit
$ rm appendit
rm: remove regular .le ‘appendit’? y
$ ls appendit
ls: cannot access appendit: No such .le or directory

LFS201: Fundamentos de Administración de Sistemas Linux 174


12.12 Laboratorio 12.2
Laboratorio 12.2: Opciones de montaje
En este ejercicio tendrá que crear una par/ción nueva o usar un archivo loopback. La solución va a
variar un poco y proveeremos los detalles de ambos métodos.
1. Use fdisk para crear una par/ción nueva de 250 MB en el sistema, probablemente en
/dev/sda. O cree un archivo lleno de ceros para usar como archivo loopback para simular una
par/ción nueva.
2. Use mkfs para formatear un sistema de archivos nuevo en la par/ción o archivo loopback que
creó recién. Hágalo tres veces, cambiando el tamaño de bloque cada vez. Fíjese en las
ubicaciones de los súperbloques, el número de los grupos de bloques y cualquier otra
información per/nente, para cada caso.
3. Cree un subdirectorio nuevo (digamos /mnt/tempdir) y monte el sistema de archivos nuevo en
esa ubicación. Con.rme que haya sido montado.
4. Desmonte el sistema de archivos nuevo y luego móntelo nuevamente con permisos de sólo
lectura.
5. Intente crear un archivo en el directorio recién montado. Debería obtener un error, ¿por qué?
6. Desmonte el sistema de archivos nuevamente.
7. Agregue una línea a su archivo /etc/fstab para que ese sistema de archivos sea montado en el
arranque.
8. Monte el sistema de archivos.
9. Modi.que la con.guración para el sistema de archivos nuevo, de tal manera que los archivos
binarios no puedan ser ejecutados (cambie la con.guración por defecto a noexec en la entrada
/mnt/tempdir). Luego monte nuevamente el sistema de archivos y copie un archivo ejecutable
(algo /bin/ls) a /mnt/tempdir e intente ejecutarlo. Debería obtener un error, ¿a qué se debe?

Una vez que esté listo puede volver a la situación original removiendo la entrada desde /etc/fstab.

LFS201: Fundamentos de Administración de Sistemas Linux 175


Solución 12.2
Solución con una par/ción Usica
1. No mostraremos los pasos detalles de fdisk, ya que lo hemos visto anteriormente. Para efectos
del ejercicio asumiremos que la par/ción creada es /dev/sda11.

$ sudo fdisk /dev/sda


.....
w
$ partprobe –s

A veces partprobe no funciona y para asegurarse de que el sistema esté al tanto de la par/ción
nueva es necesario reiniciar.
2. $ sudo mkfs -t ext4 -v /dev/sda11
$ sudo mkfs -t ext4 -b 2048 -v /dev/sda11
$ sudo mkfs -t ext4 -b 4096 -v /dev/sda11

Note que el parámetro -v (reporte detallado) le proveerá la información requerida; verá que
para una par/ción pequeña como está el valor por defecto es de 1024 bloques de byte.

3. $ sudo mkdir /mnt/tempdir


$ sudo mount /dev/sda11 /mnt/tempdir
$ mount | grep tempdir

4. $ sudo umount /mnt/tempdir


$ sudo mount -o ro /dev/sda11 /mnt/tempdir

Si ob/ene un error mientras desmonta el disposi/vo, asegúrese que no está actualmente en


ese directorio.

5. $ sudo touch /mnt/tempdir/a.le

6. $ sudo umount /mnt/tempdir

7. Agregue esta línea a /etc/fstab:


/dev/sda11 /mnt/tempdir ext4 defaults 1 3

8. $ sudo mount /mnt/tempdir


$ sudo mount | grep tempdir

LFS201: Fundamentos de Administración de Sistemas Linux 176


9. Cambie la línea en /etc/fstab a:

/dev/sda11 /mnt/tempdir ext4 noexec 1 3


Luego haga:
$ sudo mount -o remount /mnt/tempdir
$ sudo cp /bin/ls /mnt/tempdir
$ /mnt/tempdir/ls

Debería obtener un error, ¿a qué se debe?

Solución de archivo loopback


1. $ dd if=/dev/zero of=/tmp/image.le bs=1M count=250
2. $ sudo mkfs -t ext4 -v
$ sudo mkfs -t ext4 -b 2048 -v /tmp/image.le
$ sudo mkfs -t ext4 -b 4096 -v /tmp/image.le

Será adver/do en relación a que este es un archivo y no una par/ción, sólo siga adelante.
Note que el parámetro -v (reporte detallado) le proveerá la información requerida; verá que
para una par/ción pequeña como esta el valor por defecto es de 1024 bloques de byte.
3. $ sudo mkdir /mnt/tempdir
$ sudo mount -o loop /tmp/image.le /mnt/tempdir
$ mount | grep tempdir

4. $ sudo umount /mnt/tempdir


$ sudo mount -o ro,loop /tmp/image.le /mnt/tempdir
Si ob/ene un error mientras desmonta el disposi/vo, asegúrese que no está actualmente en
ese directorio.
5. $ sudo touch /mnt/tempdir/a.le
6. $ sudo umount /mnt/tempdir
7. Agregue esta línea a /etc/fstab:

/tmp/image.le /mnt/tempdir ext4 loop 1 3


8. $ sudo mount /mnt/tempdir
$ sudo mount | grep tempdir
9. Cambie la l´ınea en /etc/fstab a:

/tmp/image.le /mnt/tempdir ext4 loop,noexec 1 3


Luego haga:
$ sudo mount -o remount /mnt/tempdir
$ sudo cp /bin/ls /mnt/tempdir
$ /mnt/tempdir/ls

Debería obtener un error, ¿a qué se debe?

LFS201: Fundamentos de Administración de Sistemas Linux 177


Objetivos de aprendizaje (Revisión)

Actualmente usted debería ser capaz de:


 Estar familiarizado con conceptos tales como inodos, archivos de directorios y
atributos extendidos.
 Crear y formatear sistemas de archivos.
 Verificar y reparar errores en sistemas de archivos.
 Montar y desmontar sistemas de archivos.

LFS201: Fundamentos de Administración de Sistemas Linux 178


Capítulo 13. Características del sistema de
archivos: intercambio, cuotas, uso

Linux usa una implementación de espacio de intercambio robusto, a través de la cual el


sistema de memoria virtual permite el uso aparente de más memoria que la disponible en
forma física. Las cuotas del sistema de archivos pueden ser usadas para administrar el
uso del espacio en disco de las cuentas de usuario. Las herramientas df y du son útiles
para monitorear de forma simple el uso y capacidad del sistema de archivos.

Objetivo de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Explicar los conceptos de área de intercambio y cuotas.
 Usar las herramientas que ayudan a administrar las cuotas: quotacheck,
quotaon, quotaoff, edquota y quota.
 Usar las herramientas df y du.

LFS201: Fundamentos de Administración de Sistemas Linux 179


13.1 Intercambio (swap)

Linux emplea un sistema de memoria virtual en el cual el sistema operativo funciona


como si tuviera más memoria de la que realmente tiene. Este tipo de memoria funciona de
dos maneras:
 Muchos programas no usan toda la memoria que tienen permitido usar. A veces
esto se debe a que los procesos hijos heredan una copia de las regiones de
memoria de los padres, que utilizan la técnica COW (Copy On Write), en la cual el
hijo obtiene solamente una copia única (de a una página) cuando hay un cambio.

 Cuando la presión de memoria se vuelve importante, regiones de memoria menos


activa pueden ser escritas al área de intercambio, para ser llamadas sólo cuando
se requieren nuevamente.

Tal movimiento en el área de intercambio sea realiza usualmente a una o más particiones
o archivos; Linux permite múltiples áreas de intercambio, por lo cual las necesidades
pueden ser ajustadas dinámicamente. Cada área tiene una prioridad asociada; las de
prioridad baja no son utilizadas hasta que otras de prioridad mayor están llenas.
En la mayoría de los casos el tamaño recomendado de intercambio es el total de RAM en
el sistema. Es posible ver lo que el sistema está usando actualmente en las áreas de
intercambio de la siguiente forma:
$ cat /proc/swaps
Filename Type Size Used
Priority
/dev/sda9 partition 4193776 0
-1
/dev/sdb6 partition 4642052 0
-2

y el uso actual de memoria con:

$ free -o

total used free shared buffers cached


Mem: 4047236 3195080 852156 0 818480 1430940
Swap: 8835828 0 8835828

Los únicos comandos que implican el área de intercambio son los siguientes:

 mkswap: formatea una partición o archivo de intercambio


 swapon: activa una partición o archivo de intercambio
 swapoff: desactiva una partición o archivo de intercambio

LFS201: Fundamentos de Administración de Sistemas Linux 180


En algún momento la mayoría de la memoria está en uso para almacenar en caché
contenidos de archivo para prevenir ir a leer al disco más de lo necesario, o en un orden o
tiempo que podría estar debajo de lo óptimo. Este tipo de página en memoria no se
escribe en el área de intercambio, ya que están respaldadas en los archivos en sí, por lo
cual hacerlo no tendría sentido; en cambio, las páginas que han sido modificadas y
que no tienen respaldo físico- conocidas como dirty pages en inglés - son movidas al
disco.

Vale la pena señalar que en Linux la memoria que usa el kernel, de forma opuesta a la
memoria de aplicaciones y a diferencias de otros sistemas operativos, nunca se traslada
al área de intercambio.

13.2 Cuotas

Linux puede usar y aplicar cuotas en sistemas de archivos. Las cuotas de disco les
permite a los administradores controlar el espacio máximo que usuarios o grupos en
particular tienen habilitados para su uso. Se permite una flexibilidad considerable y las
cuotas pueden ser asignadas en base a cada sistema de archivos. Se provee de
protección para que los usuarios no agoten los recursos colectivos.
Las siguientes herramientas permiten controlar las cuotas:

 quotacheck: genera y actualiza los archivos que llevan la cuenta de las cuotas

 quotaon: habilita el sistema de cuotas

 quotaoff: deshabilita el sistema de cuotas

 edquota: se usa para editar cuotas de usuarios o grupos

 quota: informa acerca del uso y límites de las cuotas

Las operaciones de cuota requieren la existencia de los archivos aquota.user y


aquota.group en el directorio raíz del sistema de archivos que está usando cuotas.
Las cuotas pueden estar habilitadas o deshabilitadas en función de cada sistema de
archivos. Adicionalmente, Linux soporta el uso de cuotas basadas en el id de usuario y
grupo.
Los diferentes sistemas de archivos pueden tener utilidades adicionales relacionadas a
las cuotas, tales como xfs_quota.

LFS201: Fundamentos de Administración de Sistemas Linux 181


13.3 Configuración del sistema de cuotas

Para crear una cuota de sistema de archivos hay que asegurarse de haber montado el
sistema de archivos con las opciones de cuotas de usuario y/o grupo. Sin eso nada
funcionará. Los pasos básicos son los siguientes:
 Montar el sistema de archivos con las opciones de cuota de usuario y/o grupo:
- Agregar las opciones usrquota y/o grpquota a la entrada del sistema de
archivos en /etc/fstab

 Remontar el sistema de archivos (o montarlo si es nuevo)

 Ejecutar quotacheck en el sistema de archivos para configurar las cuotas.

 Habilitar las cuotas en el sistema de archivos.

 Configurar las cuotas con el programa edquota.

Por lo tanto, para crear una cuota de sistema de archivos primero hay que asegurarse de
haber montado el sistema de archivos con las opciones de cuota para usuarios y/o
grupos. Recuerde que sin ellos no va a funcionar.
Primero es necesario agregar las opciones correctas en el archivo /etc/fstab, como se
muestra a continuación:
/dev/sda5 /home ext4 defaults,usrquota 1 1
donde hemos asumido que /home está en una partición dedicada.
Luego realice un test con los siguientes comandos:

$ sudo mount -o remount /home


$ sudo quotacheck -vu /home
$ sudo quotaon -vu /home
$ sudo edquota someusername

Usted también podría querer configurar períodos de gracia con edquota. Las opciones
de montaje que deberían ser usadas en el archivo /etc/fstab son usrquota para cuotas
de usuario y grpquota para cuotas de grupo.

LFS201: Fundamentos de Administración de Sistemas Linux 182


13.4 quotacheck

La herramienta quotacheck crea y actualiza los archivos que llevan la cuenta de las
cuotas (aquota.user y aquota.group) en el sistema de archivos.

Para actualizar los archivos de usuarios para todos los sistemas de archivos
en /etc/fstab con opciones de cuota de usuario, haga lo siguiente:

$ sudo quotacheck –ua

Para actualizar los archivos de grupo para todos los sistemas de archivos
en /etc/fstab con opciones de cuota de grupo, haga lo siguiente:

$ sudo quotacheck -ga

Para actualizar el archivo de usuario de un sistema de archivos en particular, haga lo


siguiente:

$ sudo quotacheck -u [somefilesystem]

Para actualizar el archivo de grupo de un sistema de archivos en particular, haga lo


siguiente:

$ sudo quotacheck -g [somefilesystem]

Use la opción -v para obtener una salida más detallada.


quotacheck es ejecutado generalmente sólo cuando las cuotas son habilitadas
inicialmente (o cuando necesitan ser actualizadas). El programa también podría ser
ejecutado cuando fsck reporta errores en el sistema de archivos durante el arranque del
sistema.

13.5 Habilitar y deshabilitar cuotas

quotaon se usa para habilitar las cuotas en el sistema de archivos; quotaoff se usa para
deshabilitarlas. Los comandos anteriores se usan de la siguiente forma:

$ sudo quotaon [flags] [filesystem]


$ sudo quotaoff [flags] [filesystem]

LFS201: Fundamentos de Administración de Sistemas Linux 183


en donde los parámetros (jags) pueden ser:
a, --all turn quotas off for all filesystems
-f, --off turn quotas off
-u, --user operate on user quotas
-g, --group operate on group quotas
-p, --print-state print whether quotas are on or off
-x, --xfs-command=cmd perform XFS quota command
-F, --format=formatname operate on specific quota format
-v, --verbose print more messages
-h, --help display this help text and exit
-V, --version display version information and exit

Note que estos dos programas son realmente uno y funcionan de acuerdo al nombre con
el cual son invocados.

Por ejemplo:

$ sudo quotaon -av


/dev/sda6 [/]: group quotas turned on
/dev/sda5 [/home]: user quotas turned on

$ sudo quotaoff -av


/dev/sda6 [/]: group quotas turned off
/dev/sda5 [/home]: user quotas turned off

$ sudo quotaon -avu


/dev/sda5 [/home]: user quotas turned on

$ sudo quotaoff -avu


/dev/sda5 [/home]: user quotas turned off

$ sudo quotaon -avg


/dev/sda6 [/]: group quotas turned on

$ sudo quotaoff -avg


/dev/sda6 [/]: group quotas turned off

Tenga en cuenta que las operaciones de cuota fallarán si los archivos


aquota.user o aquota.group no existen.

LFS201: Fundamentos de Administración de Sistemas Linux 184


13.6 Examinar cuotas

La herramienta quota se usa para generar reportes de cuotas:


 quota (o quota -u) informa su cuota actual de usuario.
 quota -g informa su cuota actual de grupo.
 El superusuario puede ver las cuotas de cualquier usuario u grupo al especificar
un nombre de usuario o grupo.

Por ejemplo:

$ sudo quota
Disk quotas for user user1 (uid 500):
Filesystem blocks quota limit grace files quota limit grace
/dev/sda5 837572 500 1000 5804 0 0

$ sudo quota bob


Disk quotas for user bob (uid 500):
Filesystem blocks quota limit grace files quota limit grace
/dev/sda5 83757 5000 10000 5804 0 0

13.7 Configuración de cuotas especificas

El comando edquota ejecuta el editor de cuotas. Para el usuario o grupo especificado se


crea un archivo temporal con una representación de texto de las cuotas de disco actuales
para ese usuario o grupo.
Entonces un editor es invocado con el fin de modificar las cuotas en el archivo
mencionado. Una vez que el editor se cierra, el archivo temporal se lee y los archivos
binarios de cuota llevan a cabo los cambios.
Los únicos campos que pueden ser editados en la cuota son los límites soft y hard. Los
otros campos son informativos solamente.
A continuación algunos ejemplos de uso de edquota:
 edquota -u [username] edita los límites de username
 edquota -g [groupname] edita los límites de groupname
 edquota -u -p [userproto] [username] copia los valores de cuota del
usuario userproto a username
 edquota -g -p [groupproto] [username] copia los valores de cuota del
grupo groupproto a groupname
 edquota -t configura períodos de gracia

El tercer y cuarto comandos son útiles para ser incluidos en scripts, con el fin de crear
cuentas nuevas y configurar cuotas para ellas.

LFS201: Fundamentos de Administración de Sistemas Linux 185


Las cuotas para usuarios y grupos pueden estar configuradas para bloques de discos y/o
inodos. Adicionalmente, los límites soft y hard pueden ser configurados como períodos
de gracia: el límite soft puede ser excedido por un período de gracia, sin embargo, el
límite hard no puede ser excedido en ningún caso.
El período de gracia se configura en función de cada sistema de archivos.

$ sudo edquota bob


$ sudo edquota –t

13.8 Uso del sistema de archivos


La herramienta df (disk free) muestra el uso y la capacidad disponible del sistema de
archivos. Por ejemplo:

$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda5 ext4 9.8G 8.1G 1.3G 87% /
tmpfs tmpfs 3.9G 2.3M 3.9G 1% /dev/shm
/dev/sda6 ext4 9.8G 5.0G 4.3G 54% /RHEL6-32
/dev/sda2 ext4 380M 3.2M 353M 1% /boot_master
/dev/mapper/VG-local ext4 24G 16G 7.2G 68% /usr/local
/dev/mapper/VG-src ext4 16G 6.4G 8.6G 43% /usr/src
/dev/mapper/VG-pictures
ext4 12G 8.9G 2.3G 80% /PICTURES
/dev/mapper/VG-dead ext4 59G 35G 22G 62% /DEAD
/dev/mapper/VG-virtual
ext4 222G 162G 49G 77% /VIRTUAL
/dev/mapper/VG-iso_images
ext4 59G 35G 21G 63% /ISO_IMAGES
/usr/src/KERNELS.sqfs
squashfs 3.8G 3.8G 0 100% /usr/src/KERNELS

en donde la opción -h significa “legible para humanos”, es decir en KB, MB, GB y no en


bytes. La opción -T muestra el tipo de sistema de archivos. La opción -i muestra la
información del inodo en vez de bytes.

LFS201: Fundamentos de Administración de Sistemas Linux 186


13.9 Uso del espacio en disco

du (disk usage, o uso del disco) se usa para evaluar cuánto espacio está usando un
directorio (y sus subdirectorios) en un sistema de archivos.
Para desplegar el uso del disco del directorio actual: $ du
Para desplegar todos los archivos, no sólo los directorios: $ du -a
Para listar en formato “legible por humanos”: $ du -h
Para desplegar el uso del disco para un directorio específico: $ du -h somedir
Para desplegar los totales solamente, suprimiendo la salida de los subdirectorios: $ du -s
Por ejemplo:

$ du -ch /teaching/CRASH
16K /teaching/CRASH/crash-7.0.3/memory_driver
136K /teaching/CRASH/crash-7.0.3/extensions
35M /teaching/CRASH/crash-7.0.3
101M /teaching/CRASH
101M total

Comprobación de conocimientos 13.1

Comprobación de conocimientos 13.2

LFS201: Fundamentos de Administración de Sistemas Linux 187


Comprobación de conocimientos 13.3

13.10 Laboratorio 13.1


Laboratorio 13.1: Ges/ón del área de intercambio

Examine el área de intercambio actual haciendo:

$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda11 par//on 4193776 0 -1

Agregaremos más espacio de área de intercambio ya sea usando una par/ción o un archivo. Para
usar un archivo realizaremos lo siguiente:
$ dd if=/dev/zero of=swp.le bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 1.30576 s, 822 MB/s
$ mkswap swp.le
Senng up swapspace version 1, size = 1048572 KiB
no label, UUID=85bb62e5-84b0-4fdd-848b-4f8a289f0c4c

En el caso de una par/ción real sólo ejecute mkswap con el disposi/vo de la par/ción, pero tenga
en cuenta que toda la información sobre ésta será eliminada.
Ac/ve el espacio de intercambio nuevo:

$ sudo swapon swp.le


swapon: /tmp/swp.le: insecure permissions 0664, 0600 suggested.
swapon: /tmp/swp.le: insecure .le owner 500, 0 (root) suggested.

RHEL 7 advierte que hay un problema de seguridad en los permisos, lo cual solucionaremos de la
siguiente:
LFS201: Fundamentos de Administración de Sistemas Linux 188
$ sudo chown root:root swp.le
$ sudo chmod 600 swp.le

y asegúrese que está siendo usada:

$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda11 par//on 4193776 0 -1
/tmp/swp.le .le 1048572 0 -2

Fíjese en el campo Priority; las par/ciones o archivos de intercambio de menor prioridad no serán
u/lizadas hasta que las de mayor prioridad están llenas. Desac/ve el archivo de área de
intercambio y bórrelo para ahorrar ese espacio:
$ sudo swapod swp.le
$ sudo rm swp.le

13.10 Laboratorio 13.2


Laboratorio 13.2: Cuotas del sistema de archivos
1. Modi.que la entrada en /etc/fstab para que su sistema de archivos nuevo use cuotas. Cambie
noexec a usrquota en la entrada para /mnt/tempdir. Luego desmonte y monte nuevamente el
sistema de archivos.
2. Inicialice las cuotas en el sistema de archivos nuevo y luego habilite el sistema de cuotas.
3. Con.gure algunos límites de cuotas para el usuario normal: un límite soN de 500 bloques y un
límite hard de 1000 bloques.
4. Como usuario normal, use dd para crear algunos archivos e intentar superar los límites de
cuota. Cree big.le1 (200 bloques) y big.le2 (400 bloques).
Debería recibir una advertencia. ¿A qué se debe?
5. Cree big.le3, de 600 bloques.
Ahora debería recibir un mensaje de error. ¿Por qué? Revise me/culosamente los tamaños de
los archivos.
6. Elimine la línea de montado persistente que había insertado en /etc/fstab.

Solución 13.2

LFS201: Fundamentos de Administración de Sistemas Linux 189


1. Modi.que /etc/fstab para tener una de las dos líneas que se muestran, de acuerdo a si /ene
una par/ción real o un archivo loopback:

/dev/sda11 /mnt/tempdir ext4 usrquota 1 3


/tmp/image.le /mnt/tempdir ext4 loop,usrquota 1 3

Luego móntelo nuevamente:


$ sudo mount -o remount /mnt/tempdir
2. $ sudo quotacheck -u /mnt/tempdir
$ sudo quotaon -u /mnt/tempdir
$ sudo chown student.student /mnt/tmpdir

Usualmente no es necesario realizar lo que se muestra en la línea, pero lo estamos haciendo


para que la próxima parte sea más fácil.
3. Reemplace la cuenta student por su nombre de usuario.
4. $ sudo edquota -u student
5. $ cd /mnt/tempdir
$ dd if=/dev/zero of=big.le1 bs=1024 count=200
200+0 records in
200+0 records out
204800 bytes (205 kB) copied, 0.000349604 s, 586 MB/s
$ quota
Disk quotas for user student (uid 500):
Filesystem blocks quota lim grace .les qu lim gr
/dev/sda11 200 500 1000 1 0 0

$ dd if=/dev/zero of=big.le2 bs=1024 count=400


sda11: warning, user block quota exceeded.
400+0 records in
400+0 records out
4096600 bytes (410 kB) copied, 0.000654847 s, 625 MB/s Create big.le3 (600 blocks).

LFS201: Fundamentos de Administración de Sistemas Linux 190


6. $ quota
Disk quotas for user student (uid 500):
Filesystem blocks quota limit grace .les qu lim gr
/dev/sda11 600* 500 1000 6days 2 0 0

$ dd if=/dev/zero of=big.le3 bs=1024 count=600


sda11: write failed, user block limit reached.
dd: wri/ng ‘big.le3’: Disk quota exceeded
401+0 records in
400+0 records out
409600 bytes (410 kB) copied, 0.00177744 s, 230 MB/s

$ quota
Disk quotas for user student (uid 500):
Filesystem blocks quota limit grace .les quota limit grace
/dev/sda11 1000* 500 1000 6days 3 0 0

$ ls –l
total 1068 -rw------- 1 root root 7168 Dec 10 18:56 aquota.user
• rw-rw-r-- 1 student student 204800 Dec 10 18:58 big.le1
• rw-rw-r-- 1 student student 409600 Dec 10 18:58 big.le2
• rw-rw-r-- 1 student student 409600 Dec 10 19:01 big.le3
drwx------ 2 root root 16384 Dec 10 18:47 lost+found
• rwxr-xr-x 1 root root 41216 Dec 10 18:52 more

Examine de cerca los tamaños de los archivos.

7. Restablezca /etc/fstab a su contenido original.

Objetivos de aprendizaje (Revisión)

Actualmente usted debería ser capaz de:


 Explicar los conceptos de área de intercambio y cuotas.
 Usar las herramientas que ayudan a administrar las cuotas:
quotacheck, quotaon, quotaoff, edquota y quota.
 Usar las herramientas df y du.

LFS201: Fundamentos de Administración de Sistemas Linux 191


Capítulo 14. Los sistemas de archivos
Ext2/Ext3/Ext4
La familia de sistemas de archivos ext han sido nativos de Linux desde sus primeros
días, y los más ampliamente usados de todas las alternativas disponibles. Hasta muy
recientemente, ext4 ha sido la alternativa por defecto más frecuente de
distribuciones Linux, debido a su excelente combinación de rendimiento, integridad y
estabilidad.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Describir las características principales del sistema de archivos ext4y la forma en
la que ocupa el disco.
 Explicar los conceptos de grupos de bloques, superbloque, bloques de
datos e inodos.
 Usar las herramientas dumpe2fs y tune2fs.
 Enumerar las mejoras del sistema de archivos ext4.

LFS201: Fundamentos de Administración de Sistemas Linux 192


14.1 Historia de ext4 y datos básicos

El sistema de archivos ext2 fue una variedad nativa de Linux y está disponible en todos
los sistemas Linux, pero rara vez se utiliza hoy en día.

El sistema de archivos ext3 fue la primera extensión de ext2 que incluyó journaling.
Tenía el mismo diseño en disco queext2, excepto por la existencia de un archivo de
journal.

El sistema de archivos ext4 se incluyó por primera vez en la versión 2.6.19 del kernel, y
su designación como experimental fue quitada en la versión 2.6.28. Incluyó mejoras
significativas como el uso de extents para archivos largos, en vez de listas de bloques de
archivos.

Un extent es simplemente un grupo de bloques continuos. Su uso puede mejorar el


rendimiento de archivos de gran tamaño y reducir la fragmentación.

ext4 es el sistema de archivos por defecto en la mayoría de las distribuciones


empresariales de Linux, aunque RHEL 7adoptó recientemente XFS de forma
predeterminada.

14.2 Característica de ext4

Existe una correspondencia cercana de características entre el VFS y los sistemas de


archivos ext2/3/4, debido a que cada uno ha sido diseñado sobre la base del otro.

El tamaño del bloque se selecciona cuando el sistema de archivos se construye; puede


ser de 512, 1024, 2048, o 4096 bytes. Por defecto, 4096 es usado con frecuencia para
discos duros, a menos que la partición sea muy pequeña. A menos de que haya muchos
archivos pequeños, los tamaños grandes de bloque pueden ser más eficientes en
términos de minimizar accesos al disco duro.

El sistema de gestión de memoria del kernel Linux requiere que solamente un número
entero de bloques quepa en una página de memoria; por lo tanto no es posible tener
bloques de 8 KB en una plataforma x86 en donde las páginas de memoria son de 4KB de
tamaño.

El número de inodos en el sistema de archivos también puede ser ajustado, lo cual podría
ahorrar espacio en disco.

Una característica llamada reservación de inodos consiste en reservar un número


considerable de inodos cuando un directorio se crea, con la idea de ser usados en el
futuro. Esto mejora el rendimiento debido a que cuando se crean nuevos archivos en el
directorio, éste tiene ya inodos asignados.

Si la ruta de un enlace simbólico es menor que 60 caracteres, se crea un enlace simbólico


rápido, el cual se almacena directamente en el inodo, obviando la necesidad de leer un
bloque de datos.

LFS201: Fundamentos de Administración de Sistemas Linux 193


14.3 Diseño de ext4

Todos los campos son escritos a disco en orden little-endian, con excepción del journal.

Los bloques de disco se dividen en grupos de bloques, cada uno de los cuales contiene
inodos y bloques de dato almacenados de forma adyacente, con lo que se reduce el
tiempo de acceso.

El diseño de un grupo de bloques estándar es simple. Para el grupo de bloques 0, los


primeros 1024 bytes no se usan (le ceden el espacio a sectores de booteo, etc). El
superbloque comenzará en el primer bloque, con excepción del grupo de bloque 0. Luego
siguen los descriptores de grupo y un número de bloques GDT (Global Descriptor Table).
Estos son seguidos por el mapa de bits de bloques de datos, el mapa de bits de inodos, la
tabla de inodos y los bloques de datos.

Los bloques de datos son preasignados a archivos antes de que sean usados. Así
cuando el tamaño de un archivo se incrementa, se hace uso de espacio adyacente que ha
sido previamente reservado, por lo cual la fragmentación se reduce.

El superbloque del sistema de archivos contiene campos de bit, los cuales son usados
para determinar si el sistema de archivos requiere o no verificación cuando se monta por
primera vez durante la inicialización del sistema. El estado puede ser:

 clean: el sistema de archivos se desmontó de forma limpia previamente

 dirty: generalmente significa que está montado

 unknown: no se desmontó de forma limpia, como cuando hay un bloqueo o caída del
sistema

En los últimos dos casos fsck será ejecutado para verificar el sistema de archivos y
resolver cualquier problema antes de que sea montado.

Otros campos en el superbloque contienen información acerca de la última verificación del


sistema de archivos, tanto la fecha como el número de montajes. Una verificación
automática es lanzada cuando los límites ajustables exceden esos valores.

El primer bloque en el sistema de archivos es llamado bloque de arranque y está


reservado para el sector de arranque de la partición.

LFS201: Fundamentos de Administración de Sistemas Linux 194


14.4 Grupos de bloques

Después del bloque de arranque hay una serie de grupos de bloques, en donde cada
uno de ellos tiene el mismo tamaño. El diseño de cada grupo de bloques se muestra en la
figura siguiente:
Figura 14.1: Diseño de los sistemas de archivos ext2/3/4

Mapa de Data
Mapa de Tabla de
Descriptores Bits de Bloques de
Superbloque Bits de Inodos
de Grupo Bloques de Datos
Inodos (n bloques)
Datos (n bloques)

El primer y segundo bloque son los mismos para cada grupo de bloques y comprenden
el Superbloque y los Descriptores de Grupo. Bajo circunstancias normales, sólo los
bloques que están en el primer grupo son utilizados por el kernel; las copias duplicadas
son referenciadas solamente cuando el sistema de archivo está siendo verificado. Si todo
está bien, el kernel los copia desde el primer grupo de bloques. Si hay algún problema
con las copias maestras, va al siguiente y así sucesivamente hasta que se encuentra uno
en buen estado y la estructura del sistema de archivos se reconstruye. Esta redundancia
hace que sea muy difícil que un sistema de archivos ext2/3/4 se estropee, siempre y
cuando las verificaciones del sistema de archivos se ejecuten de forma periódica.
En las versiones tempranas de la familia ext, cada grupo de bloques contenía los
descriptores de grupos de cada uno de ellos, como también una copia del superbloque.
Debido a las optimizaciones actuales, no todos los grupos de bloques tienen una copia del
superbloque y de los descriptores de grupos. Para ver la situación en el sistema usted
podría hacer lo siguiente:

$ sudo dumpe2fs /dev/sda1 | grep superblock


dumpe2fs 1.42.9 (28-Dec-2013)
Primary superblock at 0, Group descriptors at 1-4
Backup superblock at 32768, Group descriptors at 32769-32772
Backup superblock at 98304, Group descriptors at 98305-98308
Backup superblock at 163840, Group descriptors at 163841-163844
Backup superblock at 229376, Group descriptors at 229377-229380
Backup superblock at 294912, Group descriptors at 294913-294916
Backup superblock at 819200, Group descriptors at 819201-819204
Backup superblock at 884736, Group descriptors at 884737-884740
Backup superblock at 1605632, Group descriptors at 1605633-1605636
Backup superblock at 2654208, Group descriptors at 2654209-2654212
Backup superblock at 4096000, Group descriptors at 4096001-4096004

LFS201: Fundamentos de Administración de Sistemas Linux 195


provea un nodo de dispositivo apropiado para que pueda ver las ubicaciones precisas.
Esto sucede cuando el sistema de archivos se crea con la opción sparse_super, que es
el valor por defecto.
El número de grupos de bloques está limitado debido al hecho que el mapa de bits de
bloque - el cual identifica bloques usados y disponibles en el grupo - tiene que caber en
un bloque único. Por lo tanto, si un bloque tiene un tamaño de 4096 bytes, un grupo de
bloques no puede contener más de 32 K bloques, o 128 MB. Si tomamos el mayor
tamaño posible de un grupo de bloques, una partición de 10 GB tendría que tener al
menos 80 grupos de bloques.
El asignador de bloques trata de mantener los bloques de cada archivo en el mismo grupo
de bloques para disminuir los tiempos de búsqueda.

14.5 dumpe2fs

Como se ha demostrado, es posible usar la herramienta dumpe2fs para obtener


información del sistema de archivos; poniendo esto en práctica sobre una partición
obtenemos lo siguiente:

$ sudo dumpe2fs /dev/sda1

Filesystem volume name: RHEL7


Last mounted on: /
Filesystem UUID: 9d6b5801-9c7e-4c17-9068-49923952338e
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent 64bit flex_bg sparse_super
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1908736
Block count: 7630592
Reserved block count: 381529
Free blocks: 5353383
Free inodes: 1682479
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Sep 3 03:52:55 2014
Last mount time: Fri Oct 24 09:18:58 2014
Last write time: Fri Oct 24 09:18:58 2014
Mount count: 89

LFS201: Fundamentos de Administración de Sistemas Linux 196


Maximum mount count: -1
Last checked: Wed Sep 3 03:52:55 2014
Check interval: 0 (<none>)
Lifetime writes: 103 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 396118
Default directory hash: half_md4
Directory Hash Seed: e488c43e-241c-4014-91d8-6ª9d3d6c7784
Journal backup: inode blocks
Journal features: journal_incompat_revoke journal_64bit
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00023592
Journal start: 16394

Group 0: (Blocks 0-32767) [ITABLE_ZEROED]


Checksum 0x2921, unused inodes 7738
Primary superblock at 0, Group descriptors at 1-4
Reserved GDT blocks at 5-1028
Block bitmap at 1029 (+1029), Inode bitmap at 1045 (+1045)
Inode table at 1061-1572 (+1061)
22880 free blocks, 8174 free inodes, 2 directories, 7738 unused
inodes
Free blocks: 9381-9672, 10180-32767
Free inodes: 19-8192
Group 1: (Blocks 32768-65535) [INODE_UNINIT, ITABLE_ZEROED]
Checksum 0x473e, unused inodes 8192
Backup superblock at 32768, Group descriptors at 32769-32772
Reserved GDT blocks at 32773-33796
Block bitmap at 1030 (bg #0 + 1030), Inode bitmap at 1046 (bg #0 +
1046)
Inode table at 1573-2084 (bg #0 + 1573)
14918 free blocks, 8192 free inodes, 0 directories, 8192 unused
inodes
Free blocks: 33797, 33800-33919, 34108-34511, 34521-34559, 34784-
34815, 37053-38015, 38039- 38040, 38080-38527, 38529-38911, Free inodes:
8193-16384
.....
Group 196: (Blocks 6422528-6455295) [INODE_UNINIT, ITABLE_ZEROED]
Checksum 0x946d, unused inodes 8192
Block bitmap at 6291460 (bg #192 + 4), Inode bitmap at 6291476 (bg
#192 + 20)
Inode table at 6293536-6294047 (bg #192 + 2080)
32768 free blocks, 8192 free inodes, 0 directories, 8192 unused
inodes
Free blocks: 6422528-6455295
Free inodes: 1605633-1613824
....
Group 232: (Blocks 7602176-7630591) [INODE_UNINIT, ITABLE_ZEROED]
Checksum 0xa174, unused inodes 8192
Block bitmap at 7340040 (bg #224 + 8), Inode bitmap at 7340056 (bg

LFS201: Fundamentos de Administración de Sistemas Linux 197


#224 + 24)
Inode table at 7344160-7344671 (bg #224 + 4128)
28416 free blocks, 8192 free inodes, 0 directories, 8192 unused
inodes
Free blocks: 7602176-7630591
Free inodes: 1900545-1908736

14.6 tune2fs

tune2fs puede ser usado para cambiar parámetros del sistema de archivos.
Para cambiar el número máximo de montajes entre verificaciones del sistema de archivos
(max-mount-count):

$ sudo tune2fs -c 25 /dev/sda1

Para cambiar el intervalo de tiempo entre verificaciones (interval-between-checks):

$ sudo tune2fs -i 10 /dev/sda1

Para listar el contenido del superbloque incluyendo los valores actuales de los parámetros
que pueden ser modificados:

$ sudo tune2fs -l /dev/sda1

14.7 Información del superbloque

El superbloque contiene información global acerca del sistema de archivos, incluyendo:


 Mount count (cuenta de montaje) y maximum mount count (cuenta máxima de
montaje). El parámetro mount count se incrementa cada vez que el disco es
montado satisfactoriamente y el valor corresponde al número de veces que esa
operación se ha realizado desde el último fsck. También es posible forzar la
verificación del sistema de archivos luego de 180 días (por defecto), u otro período
de tiempo que puede ser configurado con la herramienta tune2fs.
 Tamaño del bloque, el cual no puede ser mayor a una página de memoria. Se
configura a través de mkfs.
 Bloques por grupo.
 Cuenta de bloques disponibles.
 Cuenta de inodos disponibles.
 ID del sistema operativo.

Como se comentó anteriormente, el superbloque se almacena de forma redundante en


varios grupos de bloques.

LFS201: Fundamentos de Administración de Sistemas Linux 198


14.8 Bloques de datos e inodos

El bloque de datos y el mapa de bits de inodos son bloques cuyos bits contienen 0 para
cada bloque o inodo libre y 1 para cada uno que está usado. Hay uno de cada uno de
estos mapas de bits por grupo de bloques.

La tabla de inodos contiene tantos bloques consecutivos como sea necesario para cubrir
el número de inodos en el grupo de bloques. Cada inodo requiere 128 bytes; por lo tanto,
un bloque de 4 KB puede contener 32 inodos.

Note que hay espacio reservado para cierta cantidad de información dependiente del
sistema operativo; diferentes SOs podrían montar un sistema de archivos ext2/3/4, tal
como Linux puede montar muchos sistemas de archivos no nativos.

Tenga en cuenta que el número de inodo no se almacena en esta estructura en el disco;


su valor puede ser calculado rápidamente desde el número de grupo de bloque y el offset
de la tabla de inodo.

Los sistemas de archivos ext2 y ext3 no han incorporado aún el uso de extents para
organizar archivos grandes. En vez de eso, el arreglo de punteros a bloques de
datos i_block[], de largo EXT2_N_BLOCKS=15, es descrito por el inodo. La forma en
que esto se maneja es algo compleja:
 Los primeros 12 elementos en este arreglo apuntan a los primeros 12 bloques de
datos en el archivo.
 El elemento 13avo apunta a un bloque que representa un arreglo de segundo orden
de números de bloque; el 14avo a un arreglo de tercer orden y el 15avo a un arreglo
de cuarto orden.

Este algoritmo hace que el abordar archivos pequeños sea más rápido, como es de
esperar. Por ejemplo, con un tamaño de bloque de 4 KB, un archivo de 48 KB puede ser
abordado directamente. Un archivo de 2 MB requiere un proceso de segundo orden, uno
de 1 GB uno de tercer orden, uno de 4 GB uno de cuarto orden.

LFS201: Fundamentos de Administración de Sistemas Linux 199


14.9 Mejoras del sistema de archivos ext4

 El sistema de archivos ext4:


 Es compatible con ext3 y ext2.
 Incrementa el tamaño máximo del sistema de archivos a 1 EB (desde 16 TB) y el
tamaño máximo de un archivo a 16 TB (desde 2 TB). Estos límites aparecen
cuando se usa un direccionamiento de 48 bit; direccionamiento completo de 64 bit
podría usarse en el futuro, pero hasta la fecha no hay una necesidad real de ello.
 Incrementa de forma ilimitada el número máximo de subdirectorios, el cual estuvo
limitado a 32 K en ext3.
 Divide archivos grandes en extents de la máxima longitud en vez de usar mapeo
de bloques indirecto. Esto puede mejorar el rendimiento de archivos grandes y
reducir la fragmentación.
 Utiliza asignación multibloque, la cual puede asignar todo el espacio de una vez,
en vez de hacerlo de a un bloque. Adicionalmente, la asignación demorada puede
incrementar el rendimiento también.
 Puede preasignar espacio de disco para un archivo. El espacio asignado está
generalmente garantizado y es contiguo.
 Usa allocate-on-flush, una técnica de rendimiento la cual retrasa la asignación de
bloques hasta que los datos son escritos en el disco.
 Usa fsck rápido, el cual puede aumentar la velocidad de verificación de un sistema
de archivos en un orden de magnitud o más.
 Usa checksums para el journal, lo cual mejora la confiabilidad. Esto también
puede evitar esperas de E/S durante el journaling, resultando en una ligera mejora
del rendimiento.
 Usa timestamps mejoradas, medidas en nanosegundos.
 Incluye soporte de snapshots.

Comprobación de conocimientos 14.1

LFS201: Fundamentos de Administración de Sistemas Linux 200


14.10 Laboratorio 14.1
Laboratorio 14.1: Desfragmentación

Quienes recién conocen Linux suelen sorprenderse de que no se hable de herramientas de


desfragmentación del sistema de archivos, debido a que tales programas son muy u/lizados en el
mundo de Windows.

Sin embargo, los sistemas de archivos na/vos en sistemas opera/vos /po UNIX, incluyendo Linux,
/enden a no sufrir problemas serios de fragmentación.

Esto se debe principalmente a que no tratan de poner archivos en las regiones más internas del
disco, en donde el acceso es más rápido. En vez de eso, dejan espacio libre a través del disco, de tal
forma de que cuando un archivo va a ser creado, hay mejores posibilidades de que haya una región
de bloques libres lo su.cientemente grande como para contener el archivo completo, ya sea en
una o pocas partes.

En cuanto al hardware moderno, el concepto de regiones internas del disco no es tan claro debido
a los cambios que está experimentando la tecnología; en cuanto a los disposi/vos SSDs, la
defragmentación podría acortar la vida ú/l del almacenamiento, debido a que posee ciclos .nitos
de lectura/borrado/escritura.

Además, los sistemas de archivos con journaling más nuevos (incluyendo ext4), trabajan con
extents (regiones con/guas grandes) por diseño.
Pese a lo anterior, existe una herramienta para desfragmentar sistemas de archivos ext4:

$ sudo e4defrag
Usage : e4defrag [-v] .le...| directory...| device...
: e4defrag -c .le...| directory...| device...

e4defrag es parte del paquete e2fsprogs y debería estar en todas las distribuciones modernas de
Linux, aunque no viene en RHEL 6, la cual se está quedando atrás. Las únicas dos opciones son las
siguientes:
 -v: Muestra los detalles de la operación.
 -c: No haga nada realmente, sólo analizar y reportar.

El argumento puede ser:


 Un archivo
 Un directorio
 Un disposi/vo completo

Ejemplos:

LFS201: Fundamentos de Administración de Sistemas Linux 201


$ sudo e4defrag -c /var/log
Fragmented .les> now/best size/ext
1. /var/log/lastlog 5/1 9 KB
2. /var/log/sa/sa24 3/1 80 KB
3. /var/log/rhsm/rhsm.log 2/1 142 KB
4. /var/log/messages 2/1 4590 KB
5. /var/log/Xorg.1.log.old 1/1 36 KB

Total/best extents 120/112


Average size per extent 220 KB

Fragmenta/on score 1 [0-30 no problem: 31-55 a li@le bit fragmented: 56- needs defrag]
This directory (/var/log) does not need defragmenta/on.
Done.

$ sudo e4defrag /var/log


ext4 defragmenta/on for directory(/var/log)
[2/152]/var/log/Xorg.2.log: 100% [ OK ]
[3/152]/var/log/Xorg.0.log.old: 100% [ OK ]
[4/152]/var/log/messages-20141019.gz: 100% [ OK ]
[5/152]/var/log/boot.log: 100% [ OK ]
[7/152]/var/log/cups/page_log-20140924.gz: 100% [ OK ]
[8/152]/var/log/cups/access_log-20141019.gz: 100% [ OK ]
[9/152]/var/log/cups/access_log: 100% [ OK ]
[10/152]/var/log/cups/error_log-20141018.gz: 100% [ OK ]
[11/152]/var/log/cups/error_log-20141019.gz: 100% [ OK ]
[12/152]/var/log/cups/access_log-20141018.gz: 100% [ OK ]
[14/152]/var/log/cups/page_log-20141018.gz: 100% [ OK ]

...
[152/152]/var/log/Xorg.1.log.old: 100% [ OK ]
Success: [ 112/152 ]
Failure: [ 40/152 ]

Ejecute e4defrag en varios archivos, directorios y disposi/vos completos, siempre intentando con
-c primero.
Encontrará que generalmente los sistemas de archivos Linux /enden a necesitar defragmentación
cuando están cercanos a llenarse, sobre el 90 por ciento, o cuando son pequeños y /enen archivos
rela/vamente grandes, como sucede con las par/ciones usadas para boot.

LFS201: Fundamentos de Administración de Sistemas Linux 202


14.10 Laboratorio 14.2
Laboratorio 14.2: Modicación de parámetros del sistema de archivos con tune2fs

Vamos a modi.car algunas propiedades de un sistema de archivos formateado con ext4. Esto no
requiere desmontar el sistema de archivos.
En el ejercicio de a con/nuación puede trabajar con un archivo de imagen que puede crear de la
siguiente forma:
$ dd if=/dev/zero of=image.le bs=1M count=1024
o puede reemplazar image.le por /dev/sdaX , usando cualquier par/ción que contenga el sistema
de archivos que desea modi.car.
1. Usando dumpe2fs obtenga información acerca del sistema de archivos del cual desea ajustar
las propiedades.
2. Determinar la con.guración para el conteo máximo de montaje luego del cual el sistema de
archivos será forzado a veri.cación y modiOquelo a 30.
3. Con.gure el parámetro Check interval a tres semanas (la can/dad de /empo luego del cual un
sistema de archivos es forzado a una veri.cación).
4. Calcule el porcentaje de bloques reservados y luego recon.gúrelo a 10%.

LFS201: Fundamentos de Administración de Sistemas Linux 203


Solución 14.2
1. $ dumpe2fs image.le > dump_results
2. $ grep -i “Mount count” dump_results
Mount count: 0
Maximum mount count: -1

$ sudo tune2fs -c 30 image.le


$ grep -i “Mount count” dump_results

Mount count: 0
Maximum mount count: 30 3.

3. $ grep -i “Check interval” dump_results


Check interval: 0 (none)
$ sudo tune2fs -i 3w image.le
$ grep -i “Check interval” dump_results

Check interval: 1814400 (3 weeks)


4. $ grep -i “Block Count” dump_results
Block count: 131072
Reserved block count: 6553

$ echo “scale=4; 6553/131072” | bc


.0499

$ sudo tune2fs -m 10 image.le


$ tune2fs 1.42.9 (28-Dec-2013)

Senng reserved blocks percentage to 10% (13107 blocks)


$ grep -i “Block Count” dump_results
Block count: 131072
Reserved block count: 13107

Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Describir las características principales del sistemas de archivos ext4y la forma en
la que ocupa el disco.
 Explicar los conceptos de grupos de bloques, superbloque, bloques de
datos e inodos.
 Usar las herramientas dumpe2fs y tune2fs.
 Enumerar las mejoras del sistema de archivos ext4.

LFS201: Fundamentos de Administración de Sistemas Linux 204


Capítulo 15. Los sistemas de archivos XFS y btrfs
Los sistemas de archivos XFS y btrfs han surgido como desafíos importantes a la
dominación de ext4 en las distribuciones empresariales de Linux. Estos sistemas de
archivos de nueva generación tienen capacidades robustas en relación a manejar
tamaños grandes, abarcan múltiples volúmenes físicos y lógicos, como también métricas
de rendimiento.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Describir el sistema de archivos XFS.
 Mantener el sistema de archivos XFS.
 Describir el sistema de archivos btrfs.

LFS201: Fundamentos de Administración de Sistemas Linux 205


15.1 Características de XFS
XFS fue creado y diseñado originalmente por SGI y usado en el sistema operativo IRIX, y
luego portado a Linux. Fue diseñado explícitamente para lidiar con conjuntos de datos
grandes como también para manejar tareas en paralelo de E/S muy eficientemente.
Este puede manejar:

 Hasta 16 EB (exabytes) para el total del sistema de archivos


 Hasta 8 EB para un archivo individual

El alto rendimiento es uno de los elementos clave del diseño de XFS, el cual implementa
métodos para:

 Usar E/S de DMA (Direct Memory Access)


 Garantizar una tasa de E/S
 Ajustar tamaño de banda para igualar los dispositivos RAID o LVM subyacentes.

En contraste a los sistemas de archivos tradicionales, XFS puede manejar la información


de las cuotas con journaling. Esto conduce a una reducción del tiempo de recuperación
cuando un sistema de archivos que tiene cuotas se desmonta de forma fallida. Además, el
journal puede estar en un dispositivo externo.
Al igual que otros sistemas de archivos de UNIX y Linux, XFS soporta atributos
extendidos.

15.2 Mantenimiento del sistema de archivos XFS

El realizar mantenimiento a un sistema de archivos XFS se facilita por el hecho de que la


mayor parte de este tipo de tareas puede ser llevada a cabo en línea, es decir, con el
sistema de archivos montado. Estas incluyen:

 Defragmentar
 Ampliar
 Realizar respaldo/Restaurar

Para crear respaldos y restaurar se usan las siguientes herramientas nativas de XFS:

 xfsdump
 xfsrestore

los cuales pueden ser pausados de forma conveniente y retomados luego. Debido a que
estos programas son multihebra, los respaldos y restauraciones de XFS pueden ser
llevadas a cabo muy rápidamente.

LFS201: Fundamentos de Administración de Sistemas Linux 206


Mientras que XFS no soporta directamente snapshots de hardware o software, la
herramienta xfs-freeze puede ser usada para poner el sistema de archivos en reposo,
permitiendo a algún programa de snapshot trabajar en el dispositivo subyacente. Las
herramientas LVM de Linux usan xfs-freeze automáticamente para detener la actividad
del sistema de archivos para tomar snapshots.
XFS soporta cuotas y los comandos tradicionales de cuota pueden usarse para manipular
las cuotas por sistema de archivos en un volumen XFS. Sin embargo, si usa el comando
xfs-quota puede hacer uso de las cuotas por directorio que XFS soporta.

15.3 El sistema de archivos btrfs

Tanto desarrolladores como usuarios de Linux con sistemas de alto rendimiento y alta
capacidad o necesidades específicas, están siguiendo el desarrollo e implementación
gradual del sistema de archivos btrfs, el cual fue creado por Chris Mason. El nombre
viene de sistema de archivos B-tree. La documentación completa puede ser encontrada
en http://btrfs.wiki.kernel.org/index.php/Main_Page .

btrfs apunta a resolver la falta de pooling, snapshots, checksums e integral multi-device


spanning en otros sistemas de archivos tales como ext4. Esas características pueden ser
cruciales para que Linux escale a configuraciones de almacenamiento más grande de
tipo empresarial.

Mientras que btrfs ha estado en el mainline kernel (versión de mantenimiento) desde


2.6.29, ha sido considerado como experimental, aunque unos pocos vendedores lo han
usado en productos nuevos.

Una de las características principales es la habilidad de tomar snapshots frecuentes de


sistemas de archivos completos, o de subvolúmenes de sistemas de archivos en muy
poco tiempo. Debido a que btrfs hace amplio uso de la técnica COW (Copy on Write), un
snapshot no involucra mucho espacio inicial para bloques de datos o cualquier otra
actividad E/S, con la excepción de algunos metadatos que requieren ser actualizados.

Es posible revertir el sistema a un estado descrito por snapshots anteriores e incluso


hacer que el kernel arranque una snapshot anterior del sistema de archivos raíz .
btrfs mantiene su propio framework interno para agregar o remover particiones nuevas
y/o medios físicos a sistemas de archivos existentes, de forma similar a como lo
hace LVM (Logical Volume Management).

Algunas tareas deben ser terminadas antes de que btrfs esté listo para el trabajo diario
en sistemas de archivos críticos. Para revisar la historia de desarrollo de btrfs y la
evolución que se espera revise http://lwn.net/Articles/575841.

LFS201: Fundamentos de Administración de Sistemas Linux 207


Comprobación de conocimientos 15.1

15.4 Laboratorio 15.1


Laboratorio 15.1: Más información acerca de xfs

No tenemos un ejercicio de laboratorio detallado para xfs; muchos sistemas todavía no /enen
instalados los módulos del kernel y herramientas de usuario importantes. Sin embargo, si su kernel
Linux y su distribución lo soportan, puede crear un sistema de archivos fácilmente con mkfs -t xfs.

Puede encontrar información relacionada a las herramientas xfs con:

$ man -k xfs
a@r (1) - extended a@ributes on XFS .lesystem objects
.lesystems (5) - Linux .le-system types: minix, ext, ext2, ext3, ext4,...
fs (5) - Linux .le-system types: minix, ext, ext2, ext3, ext4,...
fsck.xfs (8) - do nothing, successfully
fsfreeze (8) - suspend access to a .lesystem (Linux Ext3/4, ReiserFS...
mkfs.xfs (8) - construct an XFS .lesystem
pmdaxfs (1) - XFS .lesystem performance metrics domain agent (PMDA)
xfs (5) - layout of the XFS .lesystem
xfs_admin (8) - change parameters of an XFS .lesystem
xfs_bmap (8) - print block mapping for an XFS .le
xfs_copy (8) - copy the contents of an XFS
.lesystem xfs_db (8) - debug an XFS .lesystem
xfs_es/mate (8) - es/mate the space that an XFS .lesystem will take
xfs_freeze (8) - suspend access to an XFS .lesystem
xfs_fsr (8) - .lesystem reorganizer for XFS
xfs_growfs (8) - expand an XFS .lesystem
xfs_info (8) - expand an XFS .lesystem
xfs_io (8) - debug the I/O path of an XFS .lesystem
xfs_logprint (8) - print the log of an XFS .lesystem
xfs_mdrestore (8) - restores an XFS metadump image to a .lesystem image
xfs_metadump (8) - copy XFS .lesystem metadata to a .le
xfs_mk.le (8) - create an XFS .le
xfs_ncheck (8) - generate pathnames from i-numbers for XFS

LFS201: Fundamentos de Administración de Sistemas Linux 208


xfs_quota (8) - manage use of quota on XFS .lesystems
xfs_repair (8) - repair an XFS .lesystem
xfs_rtcp (8) - XFS real/me copy command
xfsdump (8) - XFS .lesystem incremental dump u/lity
xfsinvu/l (8) - xfsdump inventory database checking and pruning u/lity
xfsrestore (8) - XFS .lesystem incremental restore u/lity
xqmstats (8) - Display XFS quota manager sta/s/cs from /proc

Lea acerca de estos programas y vea si puede realizar algunas operaciones con el sistema de
archivos que creó.

Objetivos de aprendizaje (Revisión)

Actualmente usted debería ser capaz de:


 Describir el sistema de archivos XFS.
 Mantener el sistema de archivos XFS.
 Describir el sistema de archivos btrfs.

LFS201: Fundamentos de Administración de Sistemas Linux 209


Capítulo 16. Logical Volume Manager (LVM)

LVM permite tener un sistema de archivos lógico sobre múltiples volúmenes físicos y
particiones, la cual al usarla se presenta como una sola partición. Cuando se usa LVM es
muy fácil contraer y expandir los sistemas de archivos según se necesite; sin embargo,
tales operaciones son difíciles de realizar en particiones físicas fijas.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Explicar los conceptos detrás de LVM.
 Crear volúmenes lógicos.
 Visualizar volúmenes lógicos.
 Redimensionar volúmenes lógicos.
 Usar snapshots de LVM.

LFS201: Fundamentos de Administración de Sistemas Linux 210


16.1 LVM

LVM (Logical Volume Manager) separa una partición virtual en varias partes, cada de una
de las cuales puede estar en distintas particiones y/o discos.
Hay muchas ventajas al usar LVM; en particular, se torna bastante fácil el modificar el
tamaño de las particiones lógicas y sistemas de archivos, agregar más espacio de
almacenamiento y reorganizarlo.

Uno o más volúmenes físicos (particiones de disco) están agrupadas en un grupo de


volúmenes. Luego el grupo de volumen es subdividido en volúmenes lógicos, lo cual
imita particiones de disco físicas y pueden ser formateadas para contener sistemas de
archivos.

Hay una variedad de herramientas de línea de comandos para crear, eliminar,


redimensionar, etc., volúmenes físicos y lógicos. La herramienta gráfica system-config-
lvm se usa en la mayoría de distribuciones de Linux. Sin embargo, en RHEL 7 ya no está
soportada y no hay ninguna herramienta gráfica que sea confiable con los cambios más
recientes de los sistemas de archivos. Afortunadamente, las herramientas de la línea de
comandos no son difíciles de usar y son más flexibles.

LVM tiene un impacto en el rendimiento. Hay un costo adicional definido que proviene de
la sobrecarga de la capa de LVM. Sin embargo, aún en sistemas sin RAID, si se
usa striping (dividir los datos en más de un disco) es posible lograr algunas mejoras de
paralelización.

LFS201: Fundamentos de Administración de Sistemas Linux 211


16.2 LVM y RAID

Al igual que RAID (lo cual discutiremos en el próximo capítulo), el uso de volúmenes
lógicos es un mecanismo para crear sistemas de archivos que pueden abarcar más de un
disco físico.

Para crear volúmenes lógicos primero se ponen todos los dispositivos en un pool grande
de espacio de disco (el grupo de volúmenes). Luego de eso, se asigna espacio desde el
pool con el cual se crea un volumen lógico.

Los volúmenes lógicos tienen características similares a los dispositivos de RAID. De


hecho pueden estar construidos sobre un dispositivo RAID. Esto le daría al volumen
lógico la redundancia de un dispositivo RAID con la escalabilidad de LVM.

LVM tiene mejor escalabilidad que RAID: los volúmenes lógicos pueden ser fácilmente
redimensionados, tanto para agrandarlos como reducirlos. Si se requiere más espacio, es
posible agregar dispositivos adicionales en cualquier momento.

16.3 Volúmenes y Grupos de volúmenes

Las particiones son convertidas a volúmenes físicos y múltiples volúmenes físicos se


agrupan en grupos de volúmenes; puede haber más de un grupo de volúmenes en el
sistema.
El espacio en el grupo de volúmenes se divida en extents, los cuales son por defecto de
4 MB de tamaño, pero puede ser modificado en el momento de la asignación.
Hay una serie de herramientas de línea de comandos que se usan para crear y manipular
grupos de volúmenes, cuyos nombres comienzan siempre con vg. Algunas de estas
utilidades son:
 vgcreate: Crea grupos de volúmenes.
 vgextend: Agrega volúmenes físicos a un grupo de volúmenes.
 vgreduce: Reduce un grupo de volúmenes.

Las herramientas que agregan o quitan particiones físicas de un grupo de volúmenes


comienzan con pv e incluyen:
 pvcreate: Convierte una partición en un volumen físico.
 pvdisplay: Muestra los volúmenes físicos en uso.
 pvmove: Mueve los datos desde un volumen físico a otro, dentro del mismo grupo
de volúmenes; esto puede ser requerido si un disco o una partición va a ser
eliminada por alguna razón. A continuación podría ejecutarse:
 pvremove: Elimina una partición desde un volumen físico.

Para obtener una lista completa de las herramientas LVM ejecute man lvm.

LFS201: Fundamentos de Administración de Sistemas Linux 212


16.4 Herramientas de volúmenes lógicos

Hay una serie de herramientas que manipulan volúmenes lógicos. Como era de esperar,
todos comienzan con lv. Revisaremos los más utilizados, pero una lista corta puede ser
obtenida con:

$ ls -lF /sbin/lv*

lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvchange -> lvm*


lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvconvert -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvcreate -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvdisplay -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvextend ->
lvm*
-r-xr-xr-x. 1 root root 1196016 Mar 26 2014 /usr/sbin/lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvmchange -> lvm*
-r-xr-xr-x. 1 root root 7230 Mar 26 2014 /usr/sbin/lvmconf*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvmdiskscan ->
lvm*
-r-xr-xr-x. 1 root root 7412 Mar 26 2014 /usr/sbin/lvmdump*
-r-xr-xr-x. 1 root root 48728 Mar 26 2014 /usr/sbin/lvmetad*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvmsadc -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvmsar -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvreduce -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvremove -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvrename -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvresize -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvs -> lvm*
lrwxrwxrwx. 1 root root 3 Sep 3 03:58 /usr/sbin/lvscan -> lvm*

Nota:
 Estas herramientas están en /sbin y no en /usr/sbin , ya que pueden ser
necesitados para arrancar o reparar y recuperar un sistema.

 La mayoría de ellas están enlazadas simbólicamente a lvm, un programa al estilo


navaja Suiza que realiza todo el trabajo y que sabe qué debe hacer basado en el
nombre por el cual es invocado. Esto también es válido para la mayoría de las
herramientas pv* y vg*, lo cual se puede comprobar fácilmente.

LFS201: Fundamentos de Administración de Sistemas Linux 213


16.5 Creación de volúmenes lógicos

lvcreate asigna volúmenes lógicos desde los grupos de volúmenes. El tamaño puede
especificarse ya sea en bytes o número de extents (recuerde que son de 4 MB por
defecto). Los nombres son a elección.
lvdisplay informa acerca de los volúmenes lógicos disponibles.
Los sistemas de archivos se localizan en los volúmenes lógicos y se formatean como de
costumbre, con mkfs.
Si se comienza con un grupo de volúmenes nuevo, los pasos asociados a la configuración
y uso de un volumen lógico nuevo son los siguientes:
1. Crear particiones en las unidades de disco (escriba 8e en fdisk)
2. Crear volúmenes físicos desde las particiones.
3. Crear el grupo de volúmenes.
4. Asignar volúmenes lógicos desde el grupo de volúmenes.
5. Montar los volúmenes lógicos (y actualizar /etc/fstab según sea necesario).

Por ejemplo, asumiendo que uno ya creó las particiones /dev/sdb1 y/dev/sdc1 , y que les
asignó un tipo 8e:

$ sudo pvcreate /dev/sdb1


$ sudo pvcreate /dev/sdc1
$ sudo vgcreate -s 16M vg /dev/sdb1
$ sudo vgextend vg /dev/sdc1
$ sudo lvcreate -L 50G -n mylvm vg
$ sudo mkfs -t ext4 /dev/vg/mylvm
$ mkdir /mylvm
$ sudo mount /dev/vg/mylvm /mylvm

Asegúrese de agregar la línea


/dev/vg/mylvm /mylvm ext4 defaults 0 0
a /etc/fstab para que el punto de montaje sea persistente.

LFS201: Fundamentos de Administración de Sistemas Linux 214


16.6 Desplegar información de los volúmenes lógicos

Los siguientes programas de línea de comandos están disponibles para desplegar


información acerca de LVM:
 pvdisplay muestra los volúmenes físicos

$ sudo pvdisplay
$ sudo pvdisplay /dev/sda5

 vgdisplay muestra los grupos de volúmenes

$ sudo vgdisplay
$ sudo vgdisplay /dev/vg0

 lvdisplay muestra los volúmenes lógicos

$ sudo lvdisplay
$ sudo lvdisplay /dev/vg0/lvm1

Si no se proveen argumentos, estas herramientas desplegarán todos los volúmenes


físicos, grupos de volúmenes o volúmenes lógicos, según corresponda.

16.7 Redimensionar volúmenes lógicos

Una de las grandes ventajas de usar LVM es que es fácil y rápido cambiar el tamaño de
un volumen lógico, especialmente cuando se intenta hacer lo mismo con una partición
física que ya contiene un sistema de archivos.
Cuando se hace esto, los extents pueden agregarse o substraerse desde el volumen
lógico, y pueden provenir desde cualquier parte en el grupo de volúmenes; de hecho no
necesitan ser de regiones físicas contiguas del disco.
Si el volumen contiene un sistema de archivos, expandirlo o contraerlo es una operación
completamente diferente que cambiar el tamaño del volumen:
 Cuando se expande un volumen lógico que tiene un sistema de archivos, se debe
expandir primero el volumen y luego el sistema de archivos.
 Cuando se contrae un volumen lógico que contiene un sistema de archivos,
primero se debe contraer el sistema de archivos y luego el volumen.

El sistema de archivos no puede estar montado mientras se reduce el tamaño del mismo.
Sin embargo, algunos sistemas de archivos permiten ser expandidos mientras están
montados.
Obviamente, las herramientas para modificar el tamaño del sistema de archivos dependen
del tipo del mismo; para ext4el programa es resize2fs.

LFS201: Fundamentos de Administración de Sistemas Linux 215


16.8 Ejemplos de rendimiento

Para extender un volumen lógico con un sistema de archivos ext4:

$ sudo umount /mylvm


$ sudo lvextend -L +500M /dev/vg/mylvm
$ sudo resize2fs /dev/vg/mylvm
$ sudo mount /dev/vg/mylvm

donde el signo más indica que se está agregando espacio.


Para reducir el sistema de archivos:

$ sudo umount /mylvm


$ sudo fsck -f /dev/vg/mylvm
$ sudo resize2fs /dev/vg/mylvm 200M
$ sudo lvreduce -L 200M /dev/vg/mylvm
$ sudo mount /dev/vg/mylvm

Si usted tiene una versión reciente de las herramientas lvm, puede realizar estas
operaciones en un paso en vez de dos, usando la opción -r, como se muestra a
continuación:

$ sudo
$ sudo lvextend -r -L +100M /dev/vg/mylvm
$ sudo lvreduce -r -L -100M /dev/vg/mylvm

en donde las cantidades usan el signo más o menos para indicar el cambio requerido.
Esto usa la herramienta subyacente fsadm, la cual puede redimensionar cualquier tipo de
sistema de archivos para cual cual el sistema operativo tenga soporte. Le recomendamos
leer la página man de fsadm.
Es posible reducir un grupo de volúmenes de la siguiente forma:

$ sudo pvmove /dev/sdc1


$ sudo vgreduce vg /dev/sdc1

16.9 Snapshots de LVM

Las snapshots LVM crean una copia exacta de un volumen lógico.

Son muy útiles para realizar respaldos, probar aplicaciones e implementar VMs (máquinas
virtuales). El estado original de la snapshot se mantiene, como por ejemplo el mapa de
bloques.

Los snapshots usan espacio para almacenar las diferencias (conocidas como deltas):

 Cuando el volumen lógico original cambia, los bloques de datos originales son
copiados a la snapshot.
 Si la información se agrega directamente al snapshot, se almacena ahí solamente.

LFS201: Fundamentos de Administración de Sistemas Linux 216


Para crear una snapshot de un volumen lógico existente:

$ sudo lvcreate -l 128 -s -n mysnap /dev/vg/mylvm

Para crear un punto de montaje y montar la snapshot:

$ mkdir /mysnap
$ mount -o ro /dev/vg/mysnap /mysnap

Para desmontar/usar la snapshot y luego removerla:

$ sudo umount /mysnap


$ sudo lvremove /dev/vg/mysnap

Asegúrese siempre de remover la snapshot cuando va a trabajar con ella. Si no remueve


la snapshot y esta se llena a causa de los cambios, será deshabilitada automáticamente.
Una snapshot con el tamaño del original nunca se desbordará.

Comprobación de conocimientos 16.1

LFS201: Fundamentos de Administración de Sistemas Linux 217


Comprobación de conocimientos 16.2

16.10 Laboratorio 16.1


Laboratorio 16.1: Volúmenes lógicos

Vamos a crear un volumen lógico usando dos par/ciones de 250 MB. Supondremos que /ene
espacio Osico disponible en disco para par/cionar.
1. Crear dos par/ciones de 250 MB de /po volumen lógico (8e).
2. Conver/r las par/ciones a volúmenes Osicos.
3. Crear un grupo de volúmenes llamado myvg y agregue los dos volúmenes Osicos al mismo.
Use el tamaño por defecto para el extent.
4. Asignar un volumen lógico de 300 MB, llamado mylvm desde el grupo de volúmenes myvg.
5. Formatear y montar el volumen lógico mylvm en /mylvm
6. Use lvdisplay para ver información del volumen lógico.
7. Ex/enda el volumen lógico y el sistema de archivos correspondiente a 350 MB.

LFS201: Fundamentos de Administración de Sistemas Linux 218


Solución 16.1
1. Ejecute:

$ sudo fdisk /dev/sda

use el disco duro que sea apropiado y cree las dos par/ciones. Estando en fdisk escriba t para
con.gurar el /po de par/ción a 8e. Si bien es cierto no es requerido de.nir el /po, es buena
idea hacerlo para evitar confusiones. Use w para reescribir la tabla de par/ción y salga. Luego
haga.

$ sudo partprobe -s

o reinicie para asegurarse que las par/ciones nuevas tomen efecto.

2. Asumiendo que las par/ciones nuevas son /dev/sdaX y /dev/sdaY:

$ sudo pvcreate /dev/sdaX


$ sudo pvcreate /dev/sdaY
$ sudo pvdisplay

3. $ sudo vgcreate myvg /dev/sdaX /dev/sdaY


$ sudo vgdisplay
4. $ sudo lvcreate -L 300M -n mylvm myvg
$ sudo lvdisplay
5. $ sudo mkfs.ext4 /dev/myvg/mylvm
$ mkdir /mylvm
$ sudo mount /dev/myvg/mylvm /mylvm

Si desea que el montaje sea persistente, edite /etc/fstab e incluya la línea:


/dev/myvg/mylvm /mylvm ext4 defaults 0 0

6. $ sudo lvdisplay

7. $ df -h
$ sudo lvextend -L 350M /dev/myvg/mylvm
$ sudo resize2fs /dev/myvg/mylvm
$ df -h

or
$ sudo lvextend -r -L +50M /dev/myvg/mylvm

LFS201: Fundamentos de Administración de Sistemas Linux 219


Objetivos de aprendizaje (Revisión)

Actualmente usted debería ser capaz de:


 Explicar los conceptos detrás de LVM.
 Crear volúmenes lógicos.
 Visualizar volúmenes lógicos.
 Redimensionar volúmenes lógicos.
 Usar snapshots de LVM.

LFS201: Fundamentos de Administración de Sistemas Linux 220


Capítulo 17. RAID
Al usar RAID se reparte la actividad de E/S en múltiples discos físicos en vez de sólo uno.
El propósito de esto es mejorar la integridad y capacidad de recuperación en caso de
falla, como también aumentar el rendimiento cuando es usado con dispositivos modernos
de almacenamiento. Hay diversos niveles de RAID, los cuales varían en sus fortalezas
relativas de seguridad, rendimiento, complejidad y costo.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Explicar el concepto de RAID.
 Proveer un resumen de los niveles de RAID.
 Configurar un dispositivo RAID usando los pasos esenciales entregados.
 Monitorear dispositivos RAID de múltiples maneras.
 Usar discos de reserva (hot spares).

LFS201: Fundamentos de Administración de Sistemas Linux 221


17.1 RAID

RAID (Redundant Array of Independent Disks) reparte la carga de E/S en múltiples


discos. Esto realmente puede incrementar el rendimiento en interfaces de controladoras
de disco modernas, tales como SCSI, las cuales pueden realizar el trabajo en paralelo, de
forma eficiente.

RAID puede ser implementado ya sea en software (es una parte madura del kernel Linux)
o en hardware. Si su hardware de RAID es conocido por tener una buena calidad, podría
ser más eficiente que usar RAID de software. En una implementación de hardware, el
sistema operativo no está consciente de que está usando RAID, esto es transparente. Por
ejemplo, tres discos duros de 512 GB (dos para datos, uno para paridad) configurados
con RAID-5, se verán como un disco único de 1 TB.

Por otro lado, una desventaja de usar RAID de hardware es que si la controladora del
disco falla, debe ser reemplazado por una compatible, la cual puede no ser fácil de
obtener en todos los casos. Cuando se usa RAID de software, los mismos discos pueden
conectarse y funcionar con cualquiera controladora de disco. Tales consideraciones
pueden ser relevantes para hardware de gama media y baja.

Tres características esenciales de RAID son:


 mirroring (espejamiento): escribe los mismos datos en más de un disco.
 striping (división): divide o reparte los datos en más de un disco.
 parity (paridad): datos extra son almacenados para permitir la detección y reparación
de problemas, proveyendo tolerancia a fallos.

Por lo tanto el uso de RAID puede mejorar tanto el rendimiento y fiabilidad.


Uno de los principales propósitos de RAID es crear un sistema de archivos el cual se
reparte en más de un disco. Esto nos permite crear crear sistemas de archivos que son
más grandes que cualquier dispositivo único. Los dispositivos RAID son creados
generalmente combinando particiones de diferentes discos juntos.
Otra ventaja de los dispositivos RAID es la habilidad de proveer mejor rendimiento,
redundancia o ambos. Striping provee mejor rendimiento al repartir la información sobre
múltiples dispositivos, de tal forma que la escritura simultánea es posible. Mirroring o
espejamiento escribe la misma información en múltiples discos proveyendo una mejor
redundancia.
mdadm se usa para crear y administrar dispositivos RAID.
Una vez creado, el nombre del arreglo /dev/mdX puede ser usado como cualquier otro
dispositivo, tal como/dev/sda1.

LFS201: Fundamentos de Administración de Sistemas Linux 222


17.2 Niveles de RAID

Existe una serie de especificaciones de RAID de complejidad y uso creciente. Los más
comúnmente conocidos son los niveles 0, 1 y 5.
 RAID 0 usa striping solamente. Los datos se reparten a través de discos últiples.
Sin embargo, a pesar del nombre, no hay redundancia y no hay estabilidad o
capacidades de recuperación. De hecho, si cualquier disco falla la información se
perderá. Pero el rendimiento puede ser mejorada significativamente debido a la
paralelización de tareas de E/S.
 RAID 1 usa mirroring solamente; cada disco tiene un duplicado, lo cual es bueno
para la recuperación de los datos. Se requieren al menos dos discos.
 RAID 5 usa una banda de paridad de rotación; si una unidad de disco falla, no se
producirá una pérdida de datos, solamente se reducirá el rendimiento. Tienen que
haber al menos 3 discos.
 RAID 6 tiene discos con stripping y paridad dual; puede soportar la pérdida de dos
discos y requiere al menos 4. Debido a que RAID 5 puede imponer un estrés
significante sobre los discos, lo cual puede conducir a fallas durante el proceso de
recuperación, RAID 6 se ha vuelto más importante.
 RAID 10 es un set de datos con mirroring y striping. Se necesitan al menos 4
discos.

Como regla general, el agregar más discos mejora el rendimiento.

17.3 Configuración de RAID de software

Los pasos esenciales para configurar un dispositivo de RAID de software son:


 Crear las particiones en cada disco (teclee fd en fdisk)
 Crear el dispositivo RAID con mdadm
 Formatear el dispositivo RAID
 Agregar el dispositivo a /etc/fstab
 Montar el dispositivo RAID
 Capturar detalles del RAID para asegurar la persistencia

El comando:
$ sudo mdadm -S

se usa para detener/desactivar el RAID.

LFS201: Fundamentos de Administración de Sistemas Linux 223


Por ejemplo:
Crear primero dos particiones de tipo fd en los discos sdb and sdc
(digamos /dev/sdbX y /dev/sdcX) usandofdisk en cada una de ellas:

$ sudo fdisk /dev/sdb


$ sudo fdisk /dev/sdc

Entonces configure el arreglo, dele formato, agréguelo a la configuración y móntelo:

$ sudo mdadm—create /dev/md0 --level=1 --raid-disks=2 /dev/sdbX


/dev/sdcX
$ sudo mkfs.ext4 /dev/md0
$ sudo bash -c “mdadm—detail—scan >> /etc/mdadm.conf”
$ sudo mkdir /myraid
$ sudo mount /dev/md0 /myraid

Asegúrese de agregar una línea en /etc/fstab para el punto de montaje.

/dev/md0 /myraid ext4 defaults 0 0

Puede examinar /proc/mdstat para ver el estado del RAID, tal como se muestra aquí:

$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb8[1] sdc7[0]
---------- 521984 blocks [2/2]
unused devices: <none>

Use lo siguiente para detener el dispositivo RAID:

$ sudo mdadm -S /dev/md0

17.4 Monitoreo de RAID

Usted puede monitorear dispositivos RAID de diversas formas:

$ sudo mdadm—detail /dev/md0


$ cat /proc/mdstat

También es posible usar mdmonitor, el cual requiere configurar /etc/mdadm.conf. El


siguiente comando mostrará el estado actual del dispositivo RAID /dev/mdX:

$ sudo mdadm—detail /dev/mdX

Otra forma de hacerlo es examinar el sistema de archivos /proc:

$ cat /proc/mdstat

LFS201: Fundamentos de Administración de Sistemas Linux 224


mostrará el estado de todos los dispositivos RAID en el sistema.
También puede darle el siguiente uso al servicio mdmonitor,
editando /etc/mdadm.conf y agregando una línea como la siguiente:

MAILADDR eddie@haskell.com

lo anterior le enviará un email a eddie@haskell.com cuando un dispositivo RAID esté


experimentando algún problema, tal como un arreglo que falla al iniciar o que cae en un
estado degradado de funcionamiento. Lo puede habilitar con:

$ sudo service mdmonitor start

y asegúrese que va a iniciar en el arranque con:

$ sudo chkconfig mdmonitor on

Nota: En sistemas Ubuntu el servicio se llama mdadm en vez de mdmonitor.

17.5 Discos de reserva de RAID

Una de las cosas importantes que provee RAID es redundancia. Para asegurar que
cualquier reducción en esa redundancia es resuelta lo antes posible, se usa un disco de
reserva.

Para crear un disco de reserva cuando se está creando el arreglo RAID:

$ sudo mdadm—create /dev/md0 -l 5 -n3 -x 1 /dev/sda8 /dev/sda9 /dev/sda10


/dev/sda11

La opción -x 1 le indica a mdadm que use un dispositivo de reserva. Tenga en cuenta


que un disco de reserva también puede ser agregado más tarde.
El comando:

$ sudo mdadm—fail /dev/md0 /dev/sdb2

probará la redundancia y el disco de de reserva de su arreglo.


Para restaurar la unidad probada o un disco nuevo en caso de una falla legítima, primero
remueva el miembro defectuoso y luego agregue el miembro nuevo, como se muestra a
continuación:

$ sudo mdadm—remove /dev/md0 /dev/sdb2


$ sudo mdadm—add /dev/md0 /dev/sde2

LFS201: Fundamentos de Administración de Sistemas Linux 225


Comprobación de conocimientos 17.1

Comprobación de conocimientos 17.2

LFS201: Fundamentos de Administración de Sistemas Linux 226


17.6 Laboratorio 17.1
Laboratorio 17.1: Creación de un disposi/vo RAID

Normalmente cuando se crea un disposi/vo RAID, deberíamos usar par/ciones en discos


separados. Sin embargo, en este ejercicio probablemente no vamos a disponer de tal hardware.
Por lo tanto vamos a necesitar dos par/ciones en el mismo disco, o podemos usar par/ciones LVM
solo para propósitos de demostración. Note que no podemos usar archivos de imágenes y
loopback para este ejercicio.
El proceso será el mismo si las par/ciones están en un disco o en varios. Aunque obviamente hay
pocas razones para crear un RAID en un disco solamente.
1. Cree dos par/ciones de 200 MB de /po raid (fd), ya sea en su disco duro, usando fdisk, o con
LVM.
2. Cree un RAID 1 y use /dev/md0 para el disposi/vo. Use las dos par/ciones para tal efecto.
3. Formatee el disposi/vo RAID con sistema de archivos ext4. Luego móntelo en /myraid y
con.gure el punto de montaje de forma persistente.
4. Ponga la información acerca de /dev/md0 en el archivo /etc/mdadm.conf usando mdadm.
Dependiendo de su distribución, este archivo podría no exis/r previamente.
5. Examine /proc/mdstat para ver el estado de su disposi/vo RAID

LFS201: Fundamentos de Administración de Sistemas Linux 227


Solución 17.1
1. Si usted está usando par/ciones en un disco real, haga lo siguiente:

$ sudo fdisk /dev/sda

y cree las par/ciones como lo hemos hecho anteriormente. Para propósitos del ejercicio los
llamaremos /dev/sdaX y /dev/sdaY. Necesitará correr partprobe, kpartx o reiniciar luego que
ha terminado para asegurarse de que el sistema reconozca las par/ciones nuevas.

Las par/ciones LVM estarán perfectamente bien para este ejercicio. Pueden crearse de la
siguiente forma:

$ sudo lvcreate -L 200M -n MD1 VG


$ sudo lvcreate -L 200M -n MD2 VG

donde hemos nombrado el grupo de volúmenes como VG. No es necesario hacer nada más
luego de la creación de las par/ciones LVM nuevas para que el sistema esté al tanto de ellas.

2. $ sudo mdadm -C /dev/md0 --level=1 --raid-disks=2 /dev/sdaX /dev/sdaY

$ sudo mdadm -C /dev/md0 --level=1 --raid-disks=2 /dev/VG/MD1 /dev/VG/MD2

3. $ sudo mkfs.ext4 /dev/md0


$ sudo mkdir /myraid
$ sudo mount /dev/md0 /myraid

y agregar a /etc/fstab

/dev/md0 /myraid ext4 defaults 0 0

4. $ mdadm—detail—scan >> /etc/mdadm.conf

5. $ cat /proc/mdstat
Personali/es : [raid1]
md0 : ac/ve raid1 dm-14[1] dm-13[0]
204736 blocks [2/2] [UU]

unused devices: (none)

Probablemente deberá veri.car que el volumen RAID se monta automá/camente luego de


reiniciar el sistema. Cuando esté listo, remueva la línea de /etc/fstab para eliminar las referencias
de las par/ciones u/lizadas en este ejercicio

LFS201: Fundamentos de Administración de Sistemas Linux 228


Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Explicar el concepto de RAID.
 Proveer un resumen de los niveles de RAID.
 Configurar un dispositivo RAID usando los pasos esenciales entregados.
 Monitorear dispositivos RAID de múltiples maneras.
 Usar discos de reserva (hot spares).

LFS201: Fundamentos de Administración de Sistemas Linux 229


Capítulo 18. Seguridad del sistema local

Una tarea esencial de cualquier administrador de sistemas es asegurar el o los sistemas


contra amenazas tanto internas como externas. El trabajo comienza con el diseño de una
política de seguridad apropiada, creada para defenderse contra amenazas esperadas e
inesperadas. Adicionalmente se requiere mantener los sistemas en un punto saludable; se
necesita realizarles mantención y actualizarlos de forma oportuna, como también
protegerlos físicamente de robos. Además, políticas sensatas tienen que garantizar que
solo los usuarios apropiados tienen privilegios potencialmente peligrosos, y solo aquellos
que son absolutamente necesarios.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Evaluar los riesgos de seguridad del sistema.
 Implementar políticas y procedimientos de seguridad informática.
 Proteger de forma eficiente la BIOS y el cargador de arranque con contraseñas de
acceso.
 Usar de forma apropiada las opciones setuid y setgid del comando mount, para
mejorar la seguridad.

LFS201: Fundamentos de Administración de Sistemas Linux 230


18.1 Seguridad del sistema local

Los computadores son inherentemente inseguros y necesitan ser protegidos de la gente


que podría inmiscuirse en ellos o atacarlos. Los atacantes suelen hacer esto con el fin de
dañar el sistema, denegar servicios o robar información.

Ningún computador puede ser absolutamente seguro. Todo lo que podemos hacer es
ralentizar y desalentar a los intrusos con el fin de que abandonen el ataque, para buscar
blancos más fáciles, o para atraparlos en el acto y tomar las acciones apropiadas.

La seguridad puede ser definida en términos de la habilidad del sistema para hacer con
regularidad lo que se supone que tiene que hacer, su integridad y exactitud, como también
en la garantía de que el sistema está disponible solamente para quienes están
autorizados a usarlo.

El mayor problema es encontrar la mezcla apropiada entre seguridad y productividad; si


las restricciones de seguridad presionan mucho al usuario, son difíciles, no están
totalmente claras y básicamente son medidas ineficaces, los usuarios eludirán los
procedimientos.

Las cuatro áreas que necesitamos proteger incluyen la física, local, remota y el personal.
En esta sección no nos concentraremos en la seguridad de la red, sino más bien en los
factores locales.

18.2 Crear una política de seguridad

Es importante crear y dar a conocer en la organización una política de seguridad clara.


Esta debería:
 Ser simple y fácil de comprender.
 Ser actualizada constantemente.
 Estar por escrito en un documento, como también en línea de ser necesario.
 Describir tanto políticas como procedimientos.
 Especificar las acciones coercitivas.
 Especificar las accionar a tomar en respuesta a una brecha de seguridad.

Las políticas deben ser genéricas y fáciles de entender, ya que eso las hace más fáciles
de seguir. Deben salvaguardar la información que necesita ser protegida, denegar acceso
a los servicios asociados y proteger la privacidad de los usuarios.
Estas políticas deberían ser actualizadas regularmente; de hecho las políticas necesitan
cambiar en la medida en que los requerimientos lo hacen. Tener una política
desactualizada puede ser peor que no tener una.

LFS201: Fundamentos de Administración de Sistemas Linux 231


18.3 Que incluir en la política de seguridad

Una política de seguridad debe incluir métodos de protección de la información, para


evitar sea leída o copiada por personal no autorizado. También debería debería incluir
protección para que la información no sea alterada o eliminada sin el permiso del dueño.
Todos los servicios deberían estar protegidos para que estén disponibles y no degradados
de alguna forma sin autorización.
Aspectos esenciales:
 Confidencialidad

 Integridad de los datos

 Disponibilidad

 Consistencia

 Control

 Auditoría

Debe asegurarse que la información es la correcta y que el sistema se comporta como se


espera. En efecto, debería haber procesos para determinar quien está consiguiendo
acceso a su sistema. El factor humano es el enlace más débil en la cadena de seguridad;
esto requiere la mayor atención a través de una auditoría constante.

18.4 Riesgos a evaluar

El análisis de riesgo está basado en las siguientes tres preguntas:


 ¿Qué quiero proteger?
 ¿Contra quién lo estoy protegiendo?
 ¿Cuánto tiempo, personal y dinero se necesita para brindar la protección
adecuada?

Este es el primer paso a tomar para construir una política de seguridad informática. Es un
prerrequisito para planear y luego aplicar políticas y procedimientos para proteger sus
sistemas.

LFS201: Fundamentos de Administración de Sistemas Linux 232


18.5 Elegir una filosofía de seguridad

Existen dos filosofías básicas que se pueden encontrar en la mayoría de ambientes


computacionales:
 Cualquier cosa no expresamente permitida es denegada.
 Cualquier cosa que no está expresamente prohibida es permitida.

Usted debe decidir cuál filosofía es la mejor para su organización.


La primera opción es más estricta: un usuario está habilitado para hacer solo lo que está
clara y explícitamente especificado como permisible sin privilegios. Esta es la filosofía
usada más comúnmente.
La segunda alternativa constituye un ambiente más liberal en donde a los usuarios se les
permite hacer todo excepto lo que está expresamente prohibido. Esto implica un alto
grado de confianza y se utiliza con menos frecuencia por razones obvias.

18.6 Guías generales de seguridad

A continuación algunas guías generales a recordar durante la implementación de filosofías


de seguridad:
1. El factor humano es el eslabón más débil.
Debe educar a sus usuarios y mantenerlos contentos. El mayor porcentaje de
vulneraciones de seguridad son internos y a menudo no son maliciosos.
2. No existe un ambiente informático invulnerable.
El único sistema totalmente seguro es el que no está conectado a nada, guardado
en una habitación segura y apagado.
3. La paranoia es buena.
Sospeche, esté atento y sea perseverante al asegurar un sistema informático. Es
un proceso continuo al que se le debe prestar atención constantemente. Verifique
los procesos, usuarios y fíjese en cualquier cosa que parezca estar fuera de lo
normal.
Los usuarios nunca deberían poner el directorio actual en el path. Es decir, no ponga algo
como lo siguiente en su archivo ~/.bashrc:

PATH=./:$PATH

Esto tiene un riesgo de seguridad importante; una persona maliciosa podría


reemplazar un programa con otro del mismo nombre, el cual podría hacer cosas
perjudiciales. Piense en un script llamado ls que contenga solo la siguiente línea:

/bin/rm -rf $HOME

Si usted fuera al directorio que contiene ese archivo y ejecutara ls, borraría todo su
directorio de usuario.

LFS201: Fundamentos de Administración de Sistemas Linux 233


18.7 Actualizaciones y seguridad

Es crítico prestar atención a las actualizaciones de su distribuidor de Linux y aplicarlas


tan pronto sea posible.
La mayoría de los ataques explotan agujeros de seguridad conocidos en el período de
tiempo entre la revelación del problema y la aplicación de parches. Los ataques de
día cero son mucho más raros; en este caso un atacante usa un agujero de seguridad
que no ha sido descubierto o para el cual no se ha liberado un parche.
Los administradores de sistemas son reacios a aplicar tales parches inmediatamente
después de que han sido liberados, más que nada basados en experiencias negativas
con compañías de software privativo, las que pueden causar más problemas que
soluciones con los parches que incluyen. Sin embargo, esas regresiones son
extremadamente raras en Linux, y probablemente el peligro de retrasar la aplicación de
un parche de seguridad no es justificable.

18.8 Acceso al hardware y vulnerabilidades

En cualquier momento el hardware que está accesible físicamente puede ser


comprometido por:
 Key logging: Almacenar la actividad en tiempo real de un usuario de computador
(con un software de tipo keylogger), incluyendo las teclas que presiona. La
información capturada puede ser almacenada localmente o transmitida a
máquinas remotas.

 Analizador de paquetes de red: Captura y visualización de los datos a nivel de


paquetes de red.

 Arrancar con un live CD/DVD o de rescate.

 Montar nuevamente el disco y modificar su contenido.

El acceso físico a un sistema permite a los atacantes aprovechar fácilmente diferentes


vectores de ataque, lo cual torna en irrelevantes todas las recomendaciones a nivel de
sistema operativo.
Por lo anterior, la política de seguridad debe partir con requerimientos acerca de cómo
asegurar apropiadamente el acceso físico a los servidores y estaciones de trabajo.

LFS201: Fundamentos de Administración de Sistemas Linux 234


18.9 Directrices de acceso al hardware

Los pasos necesarios incluyen:


 Asegurar las estaciones de trabajo y servidores.

 Proteger el acceso a los enlaces de red de personas en las cuales no confía.

 Proteger los teclados en donde las contraseñas son ingresadas para asegurar que
no puedan ser alterados.

 Configure protección por contraseña en la BIOS de tal forma que el sistema no


pueda ser arrancado con un liveCD/DVD, de rescate o un dispositivo USB.

Para computadores de usuario y aquellos en un ambiente del hogar, algunas de las


características mencionadas (como prevenir el arranque de medios removibles) pueden
ser excesivas y usted podría evitar su uso. Sin embargo, si en su sistema hay información
sensitiva que requiere protección, entonces no debe estar ahí, o debería estar mejor
protegida utilizando los lineamientos mencionados anteriormente.

18.10 Protección de la BIOS

La BIOS es el nivel más bajo de software que configura o manipula su sistema. El


cargador de arranque accede a la BIOS para determinar cómo arrancar la máquina.
La BIOS:
 Es el nivel más bajo de seguridad.

 Debe ser protegido por el uso de una contraseña.

 Debe estar actualizada.

Configurar una contraseña en la BIOS protege de que personas sin autorización cambien
las opciones de arranque para ganar acceso al sistema. Sin embargo, solo importa si
alguien puede conseguir acceso físico a la máquina, ya que esto requiere de presencia
local.
También se recomienda generalmente que la BIOS se mantenga al día con la última
versión del firmware. Sin embargo, la mayoría de las actualizaciones de las BIOS no
tienen relación con el tema de seguridad y los administradores de sistemas suelen instalar
esos parches con mucho cuidado, ya que una pieza de código incompetente en
actualizaciones innecesarias podría inutilizar un sistema.

LFS201: Fundamentos de Administración de Sistemas Linux 235


LFS201: Fundamentos de Administración de Sistemas Linux 236
18.11 Protección del cargador de arranque con contraseña

Usted puede asegurar el proceso de arranque con una contraseña segura para prevenir
que alguien evite el paso de autenticación de usuario. Esto puede funcionar en conjunto
con una protección por contraseña de la BIOS.

Tenga en cuenta que al usar una contraseña en el cargador de arranque va a prevenir que
un usuario edite la configuración del mismo durante el proceso de arranque, sim embargo
no prevendrá que un usuario arranque desde un medio alternativo, tales como CDs/DVDs
o dispositivos USB. Por lo anterior, esto debería ir acompañado con una contraseña en
la BIOS para tener una protección total en esta etapa.

Para sistemas que usan GRUB:

 Para la versión 1 de GRUB (la antigua), ejecute grub-md5-crypt. Esta


herramienta le pedirá una contraseña, la cual cifrará y desplegará.

Luego de eso edite /boot/grub/grub.conf y agregue la línea siguiente debajo de la


línea que contiene la entrada timeout:

password—md5 $1$Wnvo.1$qz781HRVG4jUnJXmdSCZ30

en donde debe ingresar la contraseña cifrada que desplegó la salida de grub-


md5-crypt. Note que es posible forzar el uso de la contraseña solamente para
algunas opciones de arranque, en vez de todas.

 Para la versión 2 de GRUB (la actual) las cosas son más complicadas. Sin
embargo, existe una mayor flexibilidad y es posible hacer cosas como configurar
contraseñas individuales de usuario, las cuales incluso pueden ser las del inicio de
sesión.

Como es usual en la versión 2, nunca edite el archivo de configuración directamente


(/boot/grub/grub.cfg). En vez de eso, edite los archivos de configuración en /etc/grub.d
y luego ejecute update-grub. Una explicación de esto puede encontrarse
aquí: https://help.ubuntu.com/community/Grub2/Passwords.

LFS201: Fundamentos de Administración de Sistemas Linux 237


18.12 Seguridad del sistema de archivos: opciones de mount

Cuando un sistema de archivos se monta, ya sea desde la consola con un comando


mount, o automáticamente a través de /etc/fstab, hay varias opciones que se pueden
especificar para incrementar la seguridad:
 nodev
No interprete caracteres o dispositivos especiales de bloque en el sistema de
archivos.

 nosuid
Los bits set-user-identifier y set-group-identifier no tienen efecto. Vamos a
discutir en breve setuid y setgid.

 noexec
Restringe la ejecución directa de cualquier binario en el sistema de archivos
montado.

 ro
Monta el sistema de archivos en modo de solo lectura, como se muestra a
continuación:

$ mount -o ro,noexec,nodev /dev/sda2 /mymountpt

o en /etc/fstab:
/dev/sda2 /mymountpt ext4 ro,noexec,nodev 0 0

18.13 setuid y setgid

Normalmente un programa corre con los privilegios del usuario que lo ejecutó. Esto
significa que sin importar quien es el dueño del binario que está corriendo, el proceso de
todas formas tiene privilegios restringidos.

Ocasionalmente puede tener sentido que haya usuarios con capacidades extendidas que
no tienen generalmente, tales como la habilidad para iniciar o detener una interfaz de red,
o editar un archivo del cual el superusuario es dueño.
Al configurar el bit setuid (set user ID) en un archivo ejecutable, se modifica el
comportamiento normal y se otorgan derechos de acceso del dueño en vez
del usuario que ejecuta el programa.

Además es posible configurar el bit setgid, de tal forma que el proceso se ejecute con los
privilegios del grupo que es dueño del binario, en vez del de quien lo está corriendo.
Quisiéramos enfatizar que esto es generalmente una mala idea y que es recomendable
evitarlo en la mayoría de las circunstancias. A menudo es mejor escribir un
programa demonio con menos privilegios para este tipo de uso. Algunas distribuciones
recientes han deshabilitado completamente esta característica.
LFS201: Fundamentos de Administración de Sistemas Linux 238
18.14 Configuración de los bits setuid/setgid

Esto se realiza de forma simple con:


$ chmod u+s somefile
$ chmod g+s somefile

en donde el primer ejemplo realiza la operación de setuid y el segundo la de setgid.


En el caso de los directorios, configurar el bit de grupo tiene un efecto diferente; se utiliza
para crear un directorio compartido, como se muestra aquí:
$ chmod g+s somedir

Los archivos creados en este directorio pertenecen al grupo del dueño del directorio (y no
al grupo del usuario que lo crea).
Tenga en cuenta que efectivamente no puede cambiar el setuid de un script shell; de
hecho, no sucederá nada a menos que usted cambie el bit setuid en la consola, lo cual
podría ser un tremendo agujero de seguridad. Solo se puede hacer en binarios
ejecutables.

Comprobación de conocimientos 18.1

LFS201: Fundamentos de Administración de Sistemas Linux 239


18.15 Laboratorio 18.1
Laboratorio 18.1: Seguridad y opciones de mount
Vamos a montar una par/ción o disposi/vo loop con la opción noexec para evitar la ejecución de
programas que en el sistema de archivos. Si bien es cierto que es posible hacer esto con una
par/ción preexistente, puede ser diOcil cambiar el comportamiento mientras la par/ción está
montada. Por lo tanto, para la demostración usaremos un disposi/vo loop, lo cual es un
procedimiento inofensivo.
1. Cree un archivo vacío, ponga un sistema de archivos en él y móntelo.
2. Copie un archivo ejecutable desde alguna parte a este sistema de archivos y pruebe que
funciona en el lugar nuevo.
3. Desmóntelo y móntelo nuevamente con la opción noexec.
4. Pruebe si el ejecutable aún funciona. Debería dar un error debido a la opción noexec de
mount.
5. Limpie lo anterior.

Solución 18.1
1. $ dd if=/dev/zero of=image bs=1M count=100
$ sudo mkfs.ext3 image
$ mkdir mountpoint
$ sudo mount -o loop image mountpoint

2. $ sudo cp /bin/ls mountpoint


$ mountpoint/ls 3.
3. $ sudo umount mountpoint
$ sudo mount -o noexec,loop image mountpoint
or
$ sudo mount -o noexec,remount image mountpoint

4. $ mountpoint/ls
5. $ sudo umount mountpoint
$ rm image
$ rmdir mountpoint

Tenga en cuenta que esto no es persistente. Para hacerlo persistente tendría que agregar la
opción a /etc/fstab, con una línea como la siguiente:
/home/student/image /home/student/mountpoint ext3 loop,rw,noexec 0 0

LFS201: Fundamentos de Administración de Sistemas Linux 240


18.15 Laboratorio 18.2
Laboratorio 18.2: Más de setuid y scripts

Supongamos que tenemos el siguiente programa en C (./writeit.c), el cual intenta sobreescribir un


archivo llamado a.le en el directorio actual:
/*
@*/
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <stdlib.h>
#include <sys/stat.h>

int main(int argc, char *argv[])


{
int fd, rc;
char *buder = “TESTING A WRITE”;

fd = open(“./a.le”, O_RDWR | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);

rc = write(fd, buder, strlen(buder));


prins(“wrote %d bytes\n”, rc);
close(fd);
exit(EXIT_SUCCESS);
}

Si está tomando la versión de autoaprendizaje de este curso, el código fuente está disponible para
su descarga desde la pantalla Laboratorio.
Si el programa se llama writeit.c, puede ser compilado haciendo:
$ make writeit
o de forma equivalente:
$ gcc -o writeit writeit.c

LFS201: Fundamentos de Administración de Sistemas Linux 241


Si intenta ejecutar este programa como un usuario normal sobre un archivo del cual root es el
dueño, obtendrá lo siguiente:
$ sudo touch a.le
$ ./writeit

wrote -1 bytes
pero si lo ejecuta como root:
$ sudo ./writeit
wrote 15 bytes
Por lo tanto, el usuario root fue capaz de sobreescribir el archivo del cual es dueño, pero un
usuario normal no podría. Tenga en cuenta que no ayudará cambiar el dueño de writeit a root:
$ sudo chown root.root writeit
$ ./writeit

wrote -1 bytes
porque todavía no le permi/rá sobreescribir a.le. Al con.gurar el bit setuid usted puede habilitar a
cualquier usuario normal para que lo haga:
$ sudo chmod +s writeit
$ ./writeit

wrote 15 bytes
Usted se podría preguntar por qué simplemente no escribimos un script que realice la operación,
en vez de escribir y compilar un programa ejecutable.
Bajo Linux, si se cambia el setuid en un script ejecutable, no hará nada a menos que usted cambie
el bit setuid en la shell (tal como bash), lo cual sería un gran error; cualquier cosa que se corra
desde ahí podría escalar privilegios.

Objetivos de aprendizaje (Revisión)

Actualmente usted debería ser capaz de:


 Evaluar los riesgos de seguridad del sistema.
 Implementar políticas y procedimientos de seguridad informática.
 Proteger de forma eficiente la BIOS y el cargador de arranque con contraseñas de
acceso.
 Usar de forma apropiada las opciones setuid y setgid del comando mount, para
mejorar la seguridad.

LFS201: Fundamentos de Administración de Sistemas Linux 242


Capítulo 19. Módulos de seguridad de Linux

Un sistema computacional moderno tiene que ser seguro, pero las necesidades varían de
acuerdo a la sensibilidad de la información, número de cuentas de usuario, exposición a
redes externas, requerimientos legales y otros factores. La responsabilidad de habilitar
buenos controles de seguridad recae tanto en los diseñadores de las aplicaciones,
desarrolladores y mantenedores del kernel Linux. Por supuesto, los usuarios también
deben seguir los buenos procedimientos establecidos, pero en un sistema gestionado
adecuadamente, los usuarios no privilegiados deberían tener una capacidad muy limitada
para exponer el sistema a violaciones de seguridad.

En esta sección nos ocuparemos de cómo el kernel Linux mejora la seguridad a través
del uso de Módulos de Seguridad de Linux (LSM), particularmente con la
implementación de SELinux.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Comprender cómo funciona y se implementa la infraestructura de los Módulos de
Seguridad de Linux.
 Listar las diversas implementaciones disponibles de LSM.
 Describir las principales características de SELinux.
 Explicar los diversos modos y políticas disponibles.
 Comprender la importancia de los contextos, cómo obtenerlos y configurarlos.
 Saber cómo usar las herramientas importantes de SELinux.

LFS201: Fundamentos de Administración de Sistemas Linux 243


19.1 Que son los módulos de seguridad de Linux?

Ha habido una serie de ideas acerca de cómo incorporar un módulo de seguridad


informática en Linux. La idea es implementar controles de acceso obligatorios sobre
una variedad de peticiones realizadas al kernel, de una forma en la que:
1. Se minimicen los cambios al kernel.

2. Se minimice la sobrecarga sobre el kernel.

3. Permita flexibilidad y se pueda elegir entre diferentes implementaciones, cada una de


las cuales se presenta como un LSM autónomo (Linux Security Module).

La idea básica es interceptar las llamadas al sistema; insertar código cada vez que una
aplicación solicita una transición a modo kernel con el fin de realizar la tarea que requiere
habilidades extendidas. Este código se asegura de que los permisos son válidos y que
exista protección contra intentos malintencionados. Esto se lleva a cabo al invocar pasos
de seguridad funcionales antes y/o después de que una llamada al sistema es satisfecha
por el kernel.

19.2 Alternativas de LSM

Por un largo tiempo el único modelo de seguridad extendida que se implementaba


fue SELinux. Cuando el proyecto fue sugerido por primera vez para ser incluido
directamente en el kernel, en el 2001, hubo objeciones acerca de usar un solo enfoque a
la seguridad extendida.
Como resultado de lo anterior, el método LSM fue adoptado con el fin de que módulos
alternativos a SELinux podrían ser usados a medida en que fueran desarrollados. Se
incorporó al kernel Linux en 2003.
Las implementaciones actuales de LSM son:

 SELinux: http://selinuxproject.org/page/Main_Page

 AppArmor: http://apparmor.net

 Smack: http://schaufler-ca.com

 TOMOYO: http://tomoyo.sourceforge.jp

Solo un LSM puede ser usado a la vez, ya que potencialmente modifican las mismas
partes del kernel Linux.

Nos concentraremos principalmente en SELinux y de forma secundaria en AppArmor, en


orden de volumen de uso.

LFS201: Fundamentos de Administración de Sistemas Linux 244


19.3 Resumen de SElinux

SELinux fue desarrollado originalmente por la NSA de Estados Unidos


(National Security Administration) y ha sido parte integral de RHEL por mucho tiempo, lo
cual ha traído consigo una gran base de usuarios.
Operacionalmente, SELinux es un conjunto de reglas de seguridad que se usan para
determinar qué procesos pueden acceder a cuáles archivos, puertos y otros ítems en el
sistema.
Funciona con estas tres cantidades conceptuales:
1. Contextos: Son etiquetas a archivos, procesos y puertos. Ejemplos de contextos son
usuarios de SELinux, rol y tipo.

2. Reglas: Describe el control de acceso en términos de contextos, procesos, archivos,


puertos, usuarios, etc.

3. Políticas: Son un conjunto de reglas que describen las decisiones de control de


acceso aplicables a todo el sistema, las que deberían ser aplicadas por SELinux.

Un contexto de SELinux es un nombre usado por una regla para definir cómo los
usuarios, procesos y puertos interactúan entre ellos. Como la política por defecto es
denegar cualquier acceso, las reglas se usan para describir las acciones permitidas en el
sistema.

19.4 Módulos de SELinux

SELinux puede correr en uno de los tres modos siguientes:


 Enforcing: Todo el código SELinux está operativo y el acceso está denegado de
acuerdo a la política. Todas las violaciones a la misma son auditadas y registradas.
 Permissive: Habilita el código SELinux pero solo audita y advierte acerca de las
operaciones que serían denegadas en modo enforcing.
 Disabled: Deshabilita completamente el código para aplicaciones y kernel
de SELinux y deja el sistema sin ninguna de estas protecciones.

Estos modos se seleccionan (y explican) en un archivo


(generalmente/etc/selinux/config), cuya ubicación varía según la distribución (a menudo
se encuentra en /etc/sysconfig/selinux o enlazado desde aquí). El archivo está bien
autodocumentado. La herramienta sestatus despliega el modo y política actual.

LFS201: Fundamentos de Administración de Sistemas Linux 245


LFS201: Fundamentos de Administración de Sistemas Linux 246
Para examinar o configurar el modo actual se puede usar getenforce y setenforce:
$ getenforce
Disabled
$ sudo setenforce Permissive
$getenforce
Permissive

setenforce se usa para cambiar entre modo enforcing y permissive al vuelo, mientras el
sistema está en operación. Sin embargo, no se puede habilitar o deshabilitar el modo
disabled de esta forma. Mientras que setenforce permite cambiar entre los
modos Permissive y Enforcing, no permite deshabilitar SELinux completamente. Hay al
menos dos formas diferentes de deshabilitar SELinux:
 Archivo de configuración: edite el archivo de configuración
(generalmente/etc/selinux/config) y configure SELINUX=disabled. Este es el
método por defecto y debería usarse para deshabilitar SELINUX
permanentemente.

 Parámetro del kernel: Agregue selinux=0 a la lista de parámetros del kernel


cuando reinicie.

Sin embargo es importante notar que no se recomienda deshabilitar SELinux en sistemas


en los cuales va a ser habilitado nuevamente. Es preferible usar el modo Permissive en
vez de deshabilitar SELinux, para evitar que el sistema de archivos sea reetiquetado
completamente, lo cual podría consumir bastante tiempo.

LFS201: Fundamentos de Administración de Sistemas Linux 247


19.5 Políticas de SELinux

El mismo archivo de configuración, generalmente /etc/sysconfig/selinux, también


configura la política de SELinux. Se permiten múltiples políticas, pero solo una puede
estar activa a la vez. Cambiar la política puede requerir un reinicio del sistema y un
reetiquetado del contenido del sistema de archivos, lo cual puede ser lento. Cada política
tiene archivos que deben ser instalados bajo /etc/selinux/[SELINUXTYPE].
Las políticas más comunes son:
 targeted: La política por defecto en la cual SELinux es más restringida a
procesos específicos. Los procesos de usuario e init no están dentro de los
objetivos. SELinux impone restricciones de memoria para todos los procesos, lo
cual reduce la vulnerabilidad ante ataques de desbordamiento de búfer (buffer
overflow).

 minimum: Una modificación sobre la política targeted en donde solo los


procesos seleccionados están protegidos.

 MLS: La política de seguridad de múltiples niveles es mucho más restrictiva; todos


los procesos se ponen en dominios de seguridad específicos con políticas
particulares.

19.6 Herramientas de contexto

Como se mencionó anteriormente, los contextos son etiquetas que se aplican a archivos,
directorios, puertos y procesos. Estas etiquetas se usan para describir reglas de acceso.
Existen cuatro contextos de SELinux:
 User (usuario)

 Role (rol)

 Type (tipo)

 Level (nivel)

Sin embargo, nos focalizaremos en type (tipo), el cual es el contexto más usado
comúnmente. La convención de nombres de etiquetas determina que las etiquetas de
contexto type deben terminar con _t, como en kernel_t.

LFS201: Fundamentos de Administración de Sistemas Linux 248


19.7 SELinux y herramientas estándar de línea de comandos

Muchos comandos estándar de la línea de comandos, como ls y ps, fueron extendidos


para soportar SELinux y las secciones correspondientes fueron agregadas a las páginas
man, explicando los detalles. A menudo el parámetro Z se pasa a las herramientas
estándar de línea de comandos, como en:

$ ps axZ
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t:s0 1 ? Ss 0:04 /usr/lib/systemd/systemd—
switched-root ...
system_u:system_r:kernel_t:s0 2 ? S 0:00 [kthreadd]
...
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2305 ? D 0:00 sshd:
peter@pts/0
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 2306 pts/0 Ss 0:00
-bash
...
system_u:system_r:httpd_t:s0 7490 ? Ss 0:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0 7491 ? S 0:00 /usr/sbin/httpd -DFOREGROUND
...

$ ls -Z /home/ /tmp/
/home/:
drwx------. peter peter unconfined_u:object_r:user_home_dir_t:s0 peter
/tmp/:
-rwx------. root root system_u:object_r:initrc_tmp_t:s0 ks-script-c4ENhg
drwx------. root root system_u:object_r:tmp_t:s0 systemd-private-0ofSvO
-rw-------. root root system_u:object_r:initrc_tmp_t:s0 yum.log

Otras herramientas que fueron extendidas para


soportar SELinux incluyen cp, mv y mkdir.
Tenga en cuenta que si SELinux está deshabilitado, no se mostrará información relevante
en los campos asociados a esas herramientas.

LFS201: Fundamentos de Administración de Sistemas Linux 249


19.8 Herencia y preservación de contexto de SELinux

Los archivos nuevos heredan el contexto del directorio padre, pero al mover o copiar
archivos, el contexto del directorio fuente es el cual debe ser preservado, lo cual puede
causar problemas.
Continuando con el ejemplo anterior, vemos que el contexto de tmpfile no ha cambiado al
mover el archivo desde/tmp a /home/peter:

$ cd /tmp/
$ touch tmpfile
$ ls -Z tmpfile

rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 tmpfile

$ cd
$ touch homefile
$ ls -Z homefile

rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile

$ mv /tmp/tmpfile .
$ ls -Z

rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile


rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 tmpfile

El ejemplo clásico en el cual se crea un problema en SELinux al mover archivos es


cuando son movidos al directorio DocumentRoot del servidor httpd. En sistemas que
tienen habilitado SELinux, el servidor web solo puede acceder a archivos con las
etiquetas de contexto adecuadas. Si se crea un archivo en /tmp y luego se mueve al
directorio DocumentRoot, estará inaccesible para el servidor httpd hasta que el
contexto SELinux del archivo se modifique.

LFS201: Fundamentos de Administración de Sistemas Linux 250


19.9 restorecon

La herramienta restorecon restablece los contextos de un archivo, basado en la


configuración del directorio padre. En el siguiente ejemplo, restorecon restablece la
etiqueta por defecto recursivamente para todos los archivos en el directorio home.

$ ls -Z
rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile
rw-rw-r--. peter peter unconfined_u:object_r:user_tmp_t:s0 tmpfile

$ restorecon -Rv /home/peter


restorecon reset /home/peter/tmpfile context \
unconfined_u:object_r:user_tmp_t:s0->unconfined_u:object_r:user_home_t:s0

$ ls -Z
rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 homefile
rw-rw-r--. peter peter unconfined_u:object_r:user_home_t:s0 tmpfile

Note que el contexto de tmpfile fue reconfigurado al contexto por defecto para archivos
creados en el directorio home. El tipo fue cambiado desde user_tmp_t a user_home_t.

19.19 semanage fcontext

Otro problema es cómo configurar el contexto por defecto para un directorio nuevo. La
herramienta semanage fcontext(proveída por el paquete policycoreutils-python)
despliega y cambia el contexto por defecto de archivos y directorios. Tenga en cuenta
que semanage fcontext cambia la configuración por defecto solamente y no se aplica a
objetos existentes. Esto requiere ejecutar restorecon luego. Por ejemplo:

[root@rhel7 /]# mkdir /virtualHosts


[root@rhel7 /]# ls -Z

...
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 virtualHosts
[root@rhel7 /]# semanage fcontext -a -t httpd_sys_content_t /virtualHosts
[root@rhel7 /]# ls -Z
...
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 virtualHosts
[root@rhel7 /]# restorecon -RFv /virtualHosts
restorecon reset /virtualHosts context
unconfined_u:object_r:default_t:s0-
>system_u:object_r:httpd_sys_content_t:s0
[root@rhel7 /]# ls -Z
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0
virtualHosts

Por lo tanto, el cambio del contexto desde default_t a httpd_sys_content_t se lleva a


cabo solamente después de haber ejecutado restorecon.

LFS201: Fundamentos de Administración de Sistemas Linux 251


19.11 Uso de booleanos de SELinux

El comportamiento de la política de SELinux puede ser configurada en tiempo de


ejecución sin necesidad de reescribir la política. Esto se consigue configurando
los Booleanos de SELinux, los cuales son parámetros de políticas que pueden ser
habilidados y deshabilitados.

Para listar todos los booleanos de la política actual, incluyendo el estado actual y una
descripción corta, haga lo siguiente:

$ sudo semanage boolean -l


SELinux boolean State Default Description
ftp_home_dir (off , off) Allow ftp to home dir
smartmon_3ware (off , off) Allow smartmon to 3ware
mpd_enable_homedirs (off , off) Allow mpd to enable
homedirs
xdm_sysadm_login (off , off) Allow xdm to sysadm login
xen_use_nfs (off , off) Allow xen to use nfs
mozilla_read_content (off , off) Allow mozilla to read
content
...
nfs_export_all_rw (on , on) Allow nfs to export all rw
pcp_bind_all_unreserved_ports (off , off) Allow pcp to bind all
unreserved ports
postgresql_selinux_transmit_client_label (off , off) Allow postgresql to
selinux transmit client label
collectd_tcp_network_connect (off , off) Allow collectd to tcp
network connect
cobbler_use_cifs (off , off) Allow cobbler to use cifs
mcelog_server (off , off) Allow mcelog to server
httpd_setrlimit (off , off) Allow httpd to setrlimit
squid_connect_any (on , on) Allow squid to connect any
ssh_sysadm_login (off , off) Allow ssh to sysadm login
domain_fd_use (on , on) Allow domain to fd use
virt_use_samba (off , off) Allow virt to use samba
cluster_use_execmem (off , off) Allow cluster to use
execmem
nfs_export_all_ro (on , on) Allow nfs to export all ro
cron_can_relabel (off , off) Allow cron to can relabel
sftpd_anon_write (off , off) Allow sftpd to anon write

LFS201: Fundamentos de Administración de Sistemas Linux 252


19.12 getsebool y setsebool

Una alternativa para desplegar la información booleana que produce una salida más
simple, es getsebool -a, la cual imprime solo el nombre booleano y su estado actual.
setsebool se usa para cambiar el estado booleano. El comportamiento por defecto es
aplicar los cambios inmediatamente y no son persistentes luego del reinicio. Sin embargo,
el parámetro -P puede ser proveído para hacer que los cambios sean persistentes.
Un ejemplo de cambio no persistente usando setsebool:

$ getsebool ssh_chroot_rw_homedirs
ssh_chroot_rw_homedirs --> off

$ sudo setsebool ssh_chroot_rw_homedirs on


$ getsebool ssh_chroot_rw_homedirs
ssh_chroot_rw_homedirs --> on

$ sudo reboot
...

$ getsebool ssh_chroot_rw_homedirs
ssh_chroot_rw_homedirs --> off

Un ejemplo de cambio persistente usando setsebool -P:

$ getsebool ssh_chroot_rw_homedirs
ssh_chroot_rw_homedirs --> off

$ sudo setsebool -P ssh_chroot_rw_homedirs on


$ getsebool ssh_chroot_rw_homedirs
ssh_chroot_rw_homedirs --> on

$ sudo reboot

...

$ getsebool ssh_chroot_rw_homedirs
ssh_chroot_rw_homedirs --> on

LFS201: Fundamentos de Administración de Sistemas Linux 253


19.13 Heramientas de resolución de problemas

SELinux viene con un conjunto de herramientas que recopilan información acerca de


problemas en tiempo de ejecución; registran esos problemas y proponen soluciones para
prevenir que esos problemas ocurran de nuevo. Estas herramientas son proveídas por el
paquete setroubleshoot-server. Aquí hay un ejemplo de su uso:

[root@rhel7 ~]# echo ‘File created at /root’ > rootfile


[root@rhel7 ~]# mv rootfile /var/www/html/
[root@rhel7 ~]# wget -O - localhost/rootfile

2014-11-21 13:42:04-- http://localhost/rootfile

Resolving localhost (localhost)... ::1, 127.0.0.1


Connecting to localhost (localhost)|::1|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2014-11-21 13:42:04 ERROR 403: Forbidden.
[root@rhel7 ~]# tail /var/log/messages
Nov 21 13:42:04 rhel7 setroubleshoot: Plugin Exception restorecon
Nov 21 13:42:04 rhel7 setroubleshoot: SELinux is preventing
/usr/sbin/httpd from getattr access on the file .
For complete SELinux messages. run sealert -l d51d34f9-91d5-4219-
ad1e-5531e61a2dc3
Nov 21 13:42:04 rhel7 python: SELinux is preventing /usr/sbin/httpd
from getattr access on the file .
***** Plugin catchall (100. confidence) suggests
**************************
If you believe that httpd should be allowed getattr access on the
file by default.
Then you should report this as a bug.

You can generate a local policy module to allow this access.

Do

allow this access for now by executing

# grep httpd /var/log/audit/audit.log | audit2allow -M mypol

# semodule -i mypol.pp

LFS201: Fundamentos de Administración de Sistemas Linux 254


[root@rhel7 ~]# sealert -l d51d34f9-91d5-4219-ad1e-5531e61a2dc3
SELinux is preventing /usr/sbin/httpd from getattr access on the
file .
***** Plugin catchall (100. confidence) suggests
**************************
If you believe that httpd should be allowed getattr access on the
file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:httpd_t:s0
Target Context unconfined_u:object_r:admin_home_t:s0
Target Objects [ file ]
Source httpd
Source Path /usr/sbin/httpd
Port <Unknown>
Host rhel7
Source RPM Packages httpd-2.4.6-18.el7_0.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.12.1-153.el7_0.11.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name rhel7
Platform Linux rhel7 3.10.0-123.9.3.el7.x86_64 #1 SMP Thu
Oct 30 00:16:40 EDT 2014 x86_64 x86_64
Alert Count 2
First Seen 2014-11-21 12:34:13 CET
Last Seen 2014-11-21 13:42:04 CET
Local ID d51d34f9-91d5-4219-ad1e-5531e61a2dc3

Raw Audit Messages


type=AVC msg=audit(1416573724.395:1598): avc: denied { getattr }
for pid=20180 comm=”httpd”
path=”/var/www/html/rootfile” dev=”dm-0” ino=70624441
scontext=system_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

LFS201: Fundamentos de Administración de Sistemas Linux 255


type=SYSCALL msg=audit(1416573724.395:1598): arch=x86_64
syscall=lstat success=no exit=EACCES
a0=7f2896ed0578 a1=7fffcc64fb30 a2=7fffcc64fb30 a3=0 items=0
ppid=20178 pid=20180
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48
sgid=48 fsgid=48 tty=(none)
ses=4294967295 comm=httpd exe=/usr/sbin/httpd
subj=system_u:system_r:httpd_t:s0 key=(null)

Hash: httpd,httpd_t,admin_home_t,file,getattr

Tenga en cuenta que en RHEL 7 se sugiere ejecutar lo siguiente:

$ grep httpd /var/log/audit/audit.log | audit2allow -M mypol

audit2allow es una herramienta que genera reglas de políticas de SELinux desde


registros de operaciones denegadas. Una herramienta similar es audit2why, la cual
traduce los mensajes de auditoría de SELinux en descripciones de porqué el acceso fue
denegado.
El ejemplo siguiente muestra cómo resolver este problema usando la
herramienta restorecon, la cual fue descrita anteriormente. Siéntase libre de intentar
ambas aproximaciones para resolver el problema encontrado en SELinux.

[root@rhel7 ~]# restorecon -Rv /var/www/html/


restorecon reset rootfile context
unconfined_u:object_r:admin_home_t:s0-
>unconfined_u:object_r:httpd_sys_content_t:s0

[root@rhel7 ~]# wget -q -O - localhost/rootfile


File created at /root

LFS201: Fundamentos de Administración de Sistemas Linux 256


19.14 Recursos adicionales en línea

En esta sección hemos cubierto las tareas de administración de sistemas básicas y más
comunes relacionadas a SELinux. Existen recursos gratuitos que están disponibles en
línea para ítems avanzados de SELinux, los cuales incluyen (documentación disponible
en inglés):

 Red Hat Enterprise Linux 7 SELinux User’s and Administrator’s Guide


(https://access.redhat.com/ documentation/en-
US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/)
 Red Hat Enterprise Linux 6 Security-Enhanced Linux
(https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/)

19.15 AppArmor

AppArmor es una alternativa LSM a SELinux. El soporte para ésta fue incorporado en el
kernel Linux desde 2006. Ha sido usado por SUSE, Ubuntu y otras distribuciones.
AppArmor:
 Provee Control de Acceso Obligatorio (MAC).

 Habilita a administradores a asociar un perfil de seguridad a un programa, lo cual


restringe sus capacidades.

 Es considerado más fácil de usar (por algunos, pero no todos) que SELinux.

 Se considera como neutral al sistema de archivos (no requiere etiquetas de


seguridad).

AppArmor complementa el modelo tradicional de Control de Acceso Discrecional de


UNIX (DAC) al proveer Control de Acceso Obligatorio (MAC).
De forma adicional a la capacidad de especificar perfiles de forma manual, AppArmor
incluye un modo de aprendizaje, en el cual las violaciones al perfil son registradas, pero
no prevenidas. Este registro puede ser convertido en un perfil, basado en el
comportamiento típico del programa.

LFS201: Fundamentos de Administración de Sistemas Linux 257


Comprobación de conocimientos 19.1

Comprobación de conocimientos 19.2

LFS201: Fundamentos de Administración de Sistemas Linux 258


19.16 laboratorio 19.1
Laboratorio 19.1: SELinux
Antes de comenzar este ejercicio veri.que que SELinux esté instalado y en modo enforcing. Edite
/etc/selinux/con.g y reinicie si es necesario.
Obviamente solo puede hacer esto en un sistema que /ene SELinux instalado. En este ejemplo
estamos usando RHEL.
1. Instale los paquetes vs7pd y 7p.
2. Cree una cuenta user1 con la contraseña password.
3. Cámbiese a la cuenta user1 y escriba algún texto en un archivo llamado
/home/user1/user1.le.
4. Salga de la cuenta user1 y asegúrese que el servicio 7p (el nombre del servicio es vs7pd) esté
en ejecución.
5. Haga 7p al localhost, conéctese como user1 e intente obtener user1le. Esto debería fallar.
Tenga en cuenta que esto podría fallar ya sea al conectarse a la cuenta o al transferir el archivo.
La solución a ambos problemas es el mismo, por lo cual el ejercicio no se verá afectado. Las
diferencias en el comportamiento son una consecuencia de las diferencias en las polí/cas de
SELinux.
6. Veri.que /var/log/messages para determinar porqué. Usted debería ver un error rela/vo a
setroubleshoot. Ejecute el comando sealert mostrado anteriormente.
7. Resuelva el problema e intente de nuevo hacer 7p, conectarse como user1 y obtener el
archivo user1le. Esta vez debería funcionar.

Solución 19.1
1. $ sudo yum install vsNpd Np
2. $ sudo useradd user1
$ sudo passwd user1
Changing password for user user1.
New password: password
BAD PASSWORD: The password fails the dic/onary check - it is based on a dic/onary word
Retype new password: password
passwd: all authen/ca/on tokens updated successfully.

LFS201: Fundamentos de Administración de Sistemas Linux 259


3. $ sudo su - user1
[user1@rhel7 ~]$ echo ’.le created at /home/user1’ > user1.le
[user1@rhel7 ~]$ ls
user1.le

4. [user1@rhel7 ~]$ exit

$ sudo systemctl status vsftpd.service


vsftpd.service - Vsftpd ftp daemon Loaded:
loaded (/usr/lib/systemd/system/vsftpd.service; disabled)
Active: active (running) since Fri 2014-11-21 14:08:14 CET; 32min ago
...

5. $ ftp localhost
Trying ::1...
Connected to localhost (::1).
220 (vsFTPd 3.0.2)
Name (localhost:peter): user1
331 Please specify the password.
Password: password
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get user1file
local: user1file remote: user1file
229 Entering Extended Passive Mode (|||35032|).
550 Failed to open file.
ftp> quit
221 Goodbye.

6. $ tail /var/log/messages
Nov 21 14:23:26 rhel7 setroubleshoot: SELinux is preventing /usr/sbin/vsftpd from read
access on the file .
For complete SELinux messages. run sealert -l 7f8e5e6f-bcee-4c59-9cd1-
72b90fb1f462
***** Plugin catchall_boolean (47.5 confidence) suggests ***************
If you want to allow ftp to home dir
Then you must tell SELinux about this by enabling
the ’ftp_home_dir’ boolean.
Do
setsebool -P ftp_home_dir 1
Notice that the suggestion to fix the issue can be found at the log file, and it is not even
necessary to run sealert.

LFS201: Fundamentos de Administración de Sistemas Linux 260


7. $ sudo setsebool -P ftp_home_dir 1
$ ftp localhost
Trying ::1...
Connected to localhost (::1).
220 (vsFTPd 3.0.2) Name (localhost:peter): user1
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get user1file
local: user1file remote: user1file
229 Entering Extended Passive Mode (|||18769|).
150 Opening BINARY mode data connection for user1file (28 bytes).
226 Transfer complete.
28 bytes received in 4.2e-05 secs (666.67 Kbytes/sec)
ftp> quit
221 Goodbye.
$ cat user1file
file created at /home/user1

Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Comprender cómo funciona y se implementa la infraestructura de los Módulos de
Seguridad de Linux.
 Listar las diversas implementaciones disponibles de LSM.
 Describir las principales características de SELinux.
 Explicar los diversos modos y políticas disponibles.
 Comprender la importancia de los contextos, cómo obtenerlos y configurarlos.
 Cómo usar las herramientas importantes de SELinux.

LFS201: Fundamentos de Administración de Sistemas Linux 261


Capítulo 20. Procesos
Un proceso es la encarnación de una aplicación en ejecución que puede o no consistir de
varias hebras. Los procesos tienen atributos y permisos bien definidos. Tienen que estar
en uno de un número de procesos enumerados; los más comunes son running (corriendo)
o sleeping (durmiendo). Es importante saber cuándo un proceso está corriendo en modo
usuario con privilegios limitados o en modo kernel, con privilegios extendidos,
incluyendo un acceso más directo al hardware. Hay diversas formas de crear un
proceso hijo y tanto configurar como modificar sus prioridades.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Describir un proceso y los recursos asociados a él.
 Distinguir entre procesos, programas y hebras.
 Comprender los atributos de procesos, permisos y estados.
 Saber la diferencia entre la ejecución de un programa en modo usuario y kernel.
 Describir los procesos demonio (daemon).
 Comprender cómo se crean los procesos nuevos.
 Usar nice y renice para configurar y modificar las prioridades.

LFS201: Fundamentos de Administración de Sistemas Linux 262


20.1 Procesos, programas y hebras

Un proceso es un programa en ejecución y los recursos asociados, incluyendo el


ambiente, archivos abiertos, manejadores de señales, etc. El mismo programa puede ser
ejecutado más de una vez en forma simultánea y por lo tanto es responsable de múltiples
procesos.
Al mismo tiempo, dos o más tareas, o hebras de ejecución, pueden compartir diversos
recursos, como los espacios completos de memoria (o solo áreas de memoria en
particular), archivos abiertos. etc. Cuando hay cualquier circunstancia en la cual
se comparten recursos, hablamos de un proceso multihebra.

En otros sistemas operativos puede haber una gran diferencia entre procesos pesados y
ligeros (full heavy weight processes/light weight); en forma estricta, los procesos pesados
pueden incluir procesos livianos, o solo uno de ellos.

En Linux la situación es bastante diferente. Cada hebra de ejecución se considera


individualmente, la diferencia entre un proceso pesado y ligero tiene relación solamente
con el uso de recursos compartidos y con la velocidad algo más rápida en la conmutación
de contextos entre hebras en ejecución.

A diferencia de otros sistemas operativos, Linux siempre ha hecho un trabajo


excepcionalmente rápido al crear, destruir y conmutar entre procesos. Por lo tanto el
modelo adoptado para aplicaciones de multihebra se asemeja a procesos múltiples; cada
hebra se programa individualmente, como si fuera un proceso independiente normal. Esto
se realiza en vez de involucrar más niveles de complejidad como tener un método por
separado para la programación de las hebras de un proceso, como también tener método
de programación entre diferentes procesos.

Al mismo tiempo, Linux respeta el POSIX y otros estándares de multihebra; por ejemplo,
cada hebra devuelve el mismo ID de proceso (llamado internamente como ID de grupo de
hebra), mientras que devuelve un ID de hebra distinta (llamado internamente como el ID
de proceso). Esto puede conducir a los desarrolladores a una confusión, pero debería ser
transparente a los administradores.

20.2 El proceso init

El primer proceso de usuario en el sistema es init, el cual tiene ID = 1. Este se inicia tan
pronto como el kernel ha sido inicializado y se montado el sistema de archivos raíz.

init se ejecutará hasta que el sistema se apague; este será el último proceso de usuario
que será terminado en ese punto. Este sirve como el padre ancestral de todos los demás
procesos de usuario, tanto directa como indirectamente.

LFS201: Fundamentos de Administración de Sistemas Linux 263


20.3 Procesos

Un proceso es una instancia de un programa en ejecución. Puede estar en diversos


estados, tales como running (en ejecución) o sleeping (durmiendo). Cada proceso tiene
un pid (Process ID), un ppid (Parent Process ID) y un pgid(Process Group ID).
Adicionalmente, cada proceso tiene un código de programa, datos, variables, descriptores
de archivos y un ambiente.

init es generalmente el primer proceso de usuario que se ejecuta en el sistema, y por lo


tanto es el antecesor de todos los procesos subsecuentes, con la excepción de aquellos
que han sido iniciados directamente por el kernel (los cuales se muestran con [] alrededor
del nombre en un listado de ps).

Si el proceso padre muere antes que el hijo, el ppid del hijo se configura en 1; es decir, el
proceso es adoptado por init. Nota: en sistemas Linux recientes que usan systemd,
el ppid será configurado en 2, lo cual corresponde a una hebra interna del kernel
conocida como kthreadd, el que ha asumido de init el rol de adopción de los hijos
huérfanos.

Un proceso hijo que termina su ejecución (ya sea normal o anormalente) antes que su
padre, el cual no esperó por este ni examinó su código de salida, se conoce como un
proceso zombie (o difunto). Los procesos zombies liberan prácticamente todos los
recursos y se mantienen en ese estado solo para transmitir su estado de salida. Una
función del proceso init consiste en verificar los hijos adoptivos y dejar que mueran de
forma adecuada aquellos que ya han terminado. Por lo anterior, a veces se le denomina
el asesino de zombies, o de forma más sombría, el segador de niños.

Los procesos son controlados por la programación de los mismos, lo cual es


completamente preferente. Solo el kernel tiene el derecho de preferencia sobre un
proceso, algo que el resto de los procesos no pueden hacerse entre ellos.

Por razones históricas, el PID más grande ha sido limitado a un número de 16 bit, el cual
corresponde a 32768. Es posible modificar este valor cambiando
/proc/sys/kernel/pid_max, ya que el valor por defecto puede ser inadecuado para
servidores más grandes. A medida en la que los procesos son creados, eventualmente
alcanzarán elpid_max, punto en el cual comenzarán de nuevo en PID = 300.

LFS201: Fundamentos de Administración de Sistemas Linux 264


20.4 Atributos de un proceso

Todos los procesos tienen ciertos atributos:


 El programa que está siendo ejecutado
 Contexto (estado)
 Permisos
 Recursos asociados

Cada proceso ejecuta algún programa. En cualquier momento el proceso puede tomar
una snapshot de sí mismo a través de la captura del estado de los registros de la CPU,
dónde se está ejecutando, qué hay en la memoria del proceso y alguna otra información.
Esto es el contexto del proceso.
Ya que los procesos pueden ser agendados para entrar y salir del tiempo compartido de
CPU con otros (o a veces tienen que ser puestos a dormir mientras esperan que alguna
condición se cumpla, tal como una petición de usuario o datos que están por llegar), es
posible almacenar el contexto completo cuando cambia la condición del proceso y se
restablece su ejecución. Lo anterior es crítico para que el kernel sea capaz de cambiar al
contexto que se requiera en un instante determinado.

20.5 Control de procesos con ulimit

ulimit está construido sobre la base de un comando bash, el cual despliega o restablece
una serie de límites de recursos asociados con procesos corriendo bajo una shell. Si se
ejecuta con el argumento -a muestra lo siguiente:
$ ulimit -a

core file size (blocks, -c) 0


data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31843
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Un administrador de sistemas podría necesitar cambiar alguno de estos valores en una u


otra dirección:

LFS201: Fundamentos de Administración de Sistemas Linux 265


 Para restringir las capacidades de tal forma que un usuario y/o proceso no pueda
acaparar los recursos del sistema, tales como memoria, tiempo de cpu o el
número máximo de procesos en el sistema.
 Para ampliar las capacidades de tal forma que un proceso no esté limitado en sus
recursos; por ejemplo, para un servidor que maneja muchos clientes el valor por
defecto de 1024 archivos abiertos podría hacer que su trabajo sea imposible de
realizar.

Hay dos tipos de límites:


 Hard: El valor máximo, que solo el usuario root puede configurar, al que un usuario
puede elevar el límite de recursos.
 Soft: El valor del límite actual, el cual un usuario puede modificar, pero que no
puede exceder el límite hard.

Es posible configurar cualquier límite en particular haciendo lo siguiente:

$ ulimit [options] [limit]

como en

$ ulimit -n 1600

lo cual aumentaría el número máximo de descriptores de archivos a 1600.

Tenga en cuenta que los cambios afectarán solamente a la shell actual. Para que los
cambios sean efectivos para todos los usuarios logueados, es necesario
modificar /etc/security/limits.conf, un archivo muy bien autodocumentado, y luego
reiniciar.

20.6 Permisos de los procesos y setuid

Cada proceso tiene permisos basados en el usuario específico que lo invocó.


Adicionalmente, puede tener permisos basados en el usuario dueño del archivo del
programa.

Tal como se comentó en la sección de seguridad local, los programas que están
marcados con una s en el bit de ejecución tienen un user id efectivo diferente al de
su usuario real. Estos se conocen como programas setuid. Se ejecutan con el user id del
usuario que es dueño del programa; los programas que no tienen setuid definidos se
ejecutan con los permisos del usuario que los corre. Los programas setuid de los cuales
root es dueño tienen el potencial de ser un problema de seguridad conocido.

La herramienta passwd es un ejemplo de un programa setuid. Cualquier usuario puede


ejecutarlo. Cuando un usuario ejecuta este programa, el proceso debe correr con
permisos de root para poder actualizar los archivos restringidos de escritura /etc/passwd
y /etc/shadow, en donde se mantienen las contraseñas de usuario.

LFS201: Fundamentos de Administración de Sistemas Linux 266


20.7 Estados de un proceso

Los procesos pueden estar en uno de varios estados posibles. Los principales son los
siguientes:
 En ejecución:
El proceso está siendo ejecutado actualmente ya sea en una CPU, o núcleo de
CPU o en la cola de ejecución, esperando una nueva tajada de tiempo. Se
reanudará cuando el planificador decide que merece utilizar la CPU, o cuando otra
CPU queda libre y el planificador migra el proceso a esa CPU.
 Durmiendo (es decir, esperando):
El proceso está esperando una solicitud (generalmente E/S) que se realizó y que
no puede continuar hasta que se complete. Cuando la petición se ha completado,
el kernel despertará el proceso y lo pondrá de vuelta en la cola de ejecución, y se
le otorgará una tajada de tiempo en una CPU cuando el planificador decida
hacerlo.

 Detenido:
El proceso ha sido suspendido. Este estado se experimenta comúnmente cuando
un programador quiere examinar la memoria del programa en ejecución, los
registros de la CPU, banderas u otros atributos. Una vez que esto se ha realizado
el proceso podría ser reanudado. Esto generalmente se realiza cuando el proceso
está siendo ejecutado desde un depurador o el usuario teclea Ctrl-Z.

 Zombie:
El proceso entra en este estado cuando termina su ejecución y ningún otro
proceso (generalmente el padre) ha inquirido acerca de su estado de salida. Tales
procesos también se denominan difuntos. Un proceso zombie ha liberado todos
sus recursos con excepción de su estado de salida y su entrada en la tabla de
procesos. Si el padre de cualquier proceso muere, el proceso
es adoptado por init (PID=1) o kthreadd (PID=2).

20.8 Modos de ejecución

En un momento dado un proceso (o cualquier hilo en particular de un proceso multihebra)


puede ser ejecutado ya sea en modo usuario o modo sistema, el cual es llamado
generalmente modo kernel por los desarrolladores del kernel.

Las instrucciones que pueden ser ejecutadas dependen del modo, el cual se aplica a nivel
de hardware, no de software.

El modo no es un estado del sistema; es un estado del procesador en un sistema


multinúcleo o multi-CPU, en donde cada unidad puede estar en su estado individual.
En la jerga de Intel, el modo usuario se denomina Ring 3, y el modo de sistema, Ring 0.

LFS201: Fundamentos de Administración de Sistemas Linux 267


20.9 Modo usuario

Con la excepción de cuando se ejecuta una llamada al sistema (lo cual se describirá en
la sección siguiente), los procesos se ejecutan en modo usuario, donde tienen menos
privilegios que en modo kernel.

Cuando un proceso se inicia, es aislado en su propio espacio de usuario para protegerlo


de otros procesos. Esto promueve la seguridad y crea una estabilidad mayor. A veces esto
se denomina aislación de recursos del proceso.

Cada proceso que se ejecuta en modo usuario tiene su propio espacio de memoria,
partes del cual pueden ser compartidos con otros procesos; excepto para los segmentos
de memoria compartida, un proceso de usuario no puede leer desde o escribir hacia el
espacio de memoria de cualquier otro proceso.

Incluso un proceso ejecutado por el usuario root o un programa con setuid se ejecuta en
modo usuario, excepto cuando realiza una llamada al sistema, caso en el cual tiene una
capacidad limitada para acceder al hardware.

20.10 Modo Kernel

En modo kernel (de sistema) la CPU tiene acceso completo a todo el hardware en el
sistema, incluyendo periféricos, memoria, discos, etc. Si una aplicación necesita acceso a
estos recursos debe realizar una llamada al sistema, lo cual causa un cambio de
contexto desde modo usuario a modo kernel. Este procedimiento se debe realizar
cuando se lee y escribe archivos, se crean procesos nuevos, etc.

El código de las aplicaciones nunca se ejecuta en modo kernel, solo las llamadas al
sistema en sí, lo cual corresponde a código del kernel. Cuando la llamada al sistema está
completa, se devuelve un valor y el proceso vuelve a modo usuario con un cambio de
contexto en el sentido contrario.

Hay oportunidades en las que el sistema está en modo kernel y no tiene relación con los
procesos, tales como manejo de interrupciones de hardware, ejecutar las rutinas del
planificador y otras tareas administrativas del sistema.

LFS201: Fundamentos de Administración de Sistemas Linux 268


20.11 Demonios

Un demonio es un proceso que se ejecuta en segundo plano, cuyo único propósito es


proveer algún servicio específico a los usuarios del sistema. Los demonios:
 Pueden ser muy eficientes debido a que funcionan solo cuando es necesario.
Muchos de ellos se inician en el arranque.
 Sus nombres a menudo (aunque no en todos los casos) terminan con d.
 Algunos ejemplos incluyen httpd y udevd.
 Los demonios pueden responder a eventos externos (udevd) o a tiempo
transcurrido (crond).
 Generalmente no tienen una terminal de control ni dispositivos estándar de
entrada/salida.
 A veces proporcionan un mejor control de la seguridad.

Cuando se usa SysVinit, los scripts en el directorio /etc/init.d inician varios demonios del
sistema. Estos scripts invocan comandos como argumentos de una función de shell
llamada daemon, definida en el archivo/etc/init.d/functions.
Para ver un ejemplo de cómo se hace esto, mire el script del servicio httpd en el
directorio /etc/init.d.
Los sistemas que usan systemd utilizan métodos similares para los demonios.

20.12 Procesos creados por el kernel

No todos los procesos son creados (o forked) a raíz de los procesos padre del usuario. El
kernel Linux crea directamente dos tipos de procesos por iniciativa propia. Estos son:
 Procesos internos del kernel:
Estos se ocupan de tareas de mantención, tales como asegurar que los buffers
fluyen hacia los discos, que la carga se equilibra de manera uniforme en las
diferentes CPUs, que los controladores de dispositivos se hacen cargo del trabajo
que ha sido encolado para ellos, etc. Estos procesos a se ejecutan mientras el
sistema está corriendo y generalmente están durmiendo, a menos de que tengan
algo específico que realizar.
 Procesos externos de usuario:
Estos son procesos que corren en espacio como las aplicaciones normales, pero
que son iniciados por el kernel. Hay muy pocos procesos de este tipo y
generalmente tienen una vida corta.
Es fácil ver los procesos de este tipo; cuando se ejecuta el siguiente comando
$ ps -elf

se listan todos los procesos en el sistema y se muestran los IDs de los procesos padres;
todos los que tienen PPID = 2se refieren a kthreadd, el hilo del kernel, cuyo trabajo es
crear tales procesos. Los nombres de estos procesos estarán encapsulados en paréntesis
cuadrados, como [ksoftirqd/0], por ejemplo.
LFS201: Fundamentos de Administración de Sistemas Linux 269
20.13 Creación de procesos y forking

Un sistema Linux promedio está constantemente creando procesos nuevos. A menudo


esto se denomina forking; el proceso original padre continúa ejecutándose mientras que
el proceso hijo recién creado se inicia.

Cuando la mayoría de los computadores tenían procesadores individuales solamente,


generalmente eran configurados para que el padre realizara una pausa inicial mientras
que el hijo se iniciaba; hay una expresión de UNIX que dice “Los niños son lo primero”.
Sin embargo, con sistemas modernos multi CPU ambos correrán simultáneamente en
diferentes CPUs.

A menudo, en vez de un fork, se sigue con un exec, en donde el proceso padre termina y
el proceso hijo hereda el ID del proceso padre. Los términos fork y exec se usan tan a
menudo que la gente piensa que son la misma palabra.

Los sistemas UNIX antiguos a menudo usan un programa llamado spawn, el cual es
similar en diversas formas a fork y exec, pero difiere en algunos detalles. No es parte del
estándard POSIX ni de Linux.

Para tener una idea de cómo un proceso podría iniciarse, considera un servidor web que
maneja muchos clientes. El servidor web puede lanzar un proceso nuevo cada vez que
una conexión nueva se hace a través de un cliente. Por otro lado, podría iniciar
simplemente un nuevo hilo como parte del mismo proceso; en Linux realmente no existe
mucha diferencia en el aspecto técnico entre crear un proceso completo o solo un hilo
nuevo, ya que cada mecanismo toma aproximadamente el mismo tiempo y usa una
cantidad similar de recursos.

Otro ejemplo es el demonio sshd: este es iniciado cuando el proceso init ejecuta el script
de inicio sshd, el que a su vez es responsable de iniciar el demonio sshd. Este proceso
demonio escucha solicitudes ssh de usuarios remotos.

Cuando se recibe una solicitud, sshd crea una copia nueva de sí mismo para atender el
requerimiento de servicio. Cada usuario remoto obtiene su propia copia del
demonio sshd que está en ejecución, para atender su conexión remota. El
proceso sshd inciará el programa login para validar el usuario remoto. Si la autenticación
es exitosa, el proceso login hará un fork de shell (por ejemplo, bash) para interpretar los
comandos de usuario, y así sucesivamente.

LFS201: Fundamentos de Administración de Sistemas Linux 270


20.14 Creación de procesos en una Shell

¿Qué sucede cuando un usuario ejecuta un comando en un intérprete de shell, tal


como bash?
 Un proceso nuevo se crea, como un fork desde la shell de inicio de sesión del
usuario.

 Una llamada al sistema de espera pone a dormir el proceso de la shell padre.

 El comando se carga en el espacio del proceso hijo a través de la llamada al


sistema exec. En otras palabras, el código del comando reemplaza el
programa bash en el espacio de memoria del proceso hijo.

 El comando completa su ejecución y el proceso hijo muere a través de la llamada


al sistema de salida.

 La shell padre se despierta nuevamente por la muerte del proceso hijo y procede a
crear un nuevo intérprete de comandos. Entonces la shell padre espera por la
próxima solicitud de comando desde el usuario, momento en el cual el ciclo se
repetirá.

Si un comando se ejecuta en segundo plano (agregando un signo & al final de la línea de


comandos), la shell padre se salta la solicitud de espera y queda libre para crear una
nueva shell inmediatamente, permitiendo que el proceso en segundo plano se ejecute en
paralelo. Por otro lado, para las solicitudes de primer plano la shell espera hasta que el
proceso hijo se ha completado o es detenido a través de una señal.
Algunos comandos de shell (tales como echo y kill) están construidos en la shell misma y
no implican la carga de archivos de programa. Para la ejecución de esos comandos no se
utiliza fork ni exec.

20.15 Uso de nice para establecer prioridades

La prioridad de los procesos puede ser controlada a través de los


comandos nice y renice. Desde los primeros días de UNIX la idea ha sido que el proceso
nice disminuya su prioridad para cedérsela de los demás. Por lo tanto, a medida en
que nice es mayor, la prioridad es menor.

El rango de nice va desde -20 (la prioridad más alta) a +19 (la prioridad más baja). La
forma normal de ejecutar nice es la siguiente:

$ nice -n 5 command [ARGS]

lo cual aumentaría nice en 5. Esto es equivalente a hacer lo siguiente:

$ nice -5 command [ARGS]

LFS201: Fundamentos de Administración de Sistemas Linux 271


Si usted no provee un valor para nice, se utilizará el predeterminado, el cual consiste en
incrementarlo en 10. Si no da ningún argumento se informará del valor actual. Por
ejemplo:

$ nice
0
$ nice cat &
[1] 24908
$ ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 500 4670 4603 0 80 0 - 16618 wait pts/0 00:00:00 bash
0 S 500 24855 4670 0 80 0 - 16560 wait pts/0 00:00:00 bash
0 T 500 24908 24855 0 90 10 - 14738 signal pts/0 00:00:00 cat
0 R 500 24909 24855 0 80 0 - 15887 - pts/0 00:00:00 ps

Tenga en cuenta que al aumentar el valor de nice de un proceso no significa que este no
se ejecutará; incluso podría obtener todo el tiempo de la CPU si no hay nada con lo cual
competir.

Si usted provee un gran incremento o decremento que sale del rango -20 a 19, el valor de
incremento será truncado.

20.16 Modificar el valor de nice

Por defecto solo un superusuario puede disminuir el valor de nice, es decir, incrementar la
prioridad. Sin embargo es posible darle a los usuarios normales la habilidad de disminuir
el valor de nice para sus procesos, en un rango predeterminado, lo cual se realiza
editando el archivo /etc/security/limits.conf.

Para cambiar el valor de nice de un proceso que está en ejecución, usamos el


comando renice, así:

$ renice +3 13848

lo cual incrementará en valor de nice en 3, del proceso con pid = 13848. Puede hacerlo
con más de un proceso a la vez y hay algunas otras opciones interesantes que puede ver
con man renice.

Comprobación de conocimientos 20.1

LFS201: Fundamentos de Administración de Sistemas Linux 272


Comprobación de conocimientos 20.2

20.17 Laboratorio 20.1


Laboratorio 20.1: Control de procesos con ulimit
Por favor haga:
$ help ulimit
y lea /etc/security/limits.conf
antes de ejecutar los pasos que vienen a con/nuación.
1. Inicie una terminal shell ejecutando bash (o abra una terminal nueva) de tal forma que los
cambios sean efec/vos en esa shell solamente. Vea el límite actual del número de archivos
abiertos y explícitamente el número de los límites hard y soN.
2. Con.gure el valor del límite hard y veri.que que haya funcionado.
3. Con.gure el valor del límite hard a 2048 y veri.que que haya funcionado.
4. Intente con.gurar el límite al valor previo. ¿Funcionó?

LFS201: Fundamentos de Administración de Sistemas Linux 273


Solución 20.1
1. $ bash
$ ulimit -n
1024

$ ulimit -S -n 1024
$ ulimit -H -n
4096

2. $ ulimit -n hard
$ ulimit -n
4096

3. $ ulimit -n 2048
$ ulimit -n
2048

$ ulimit -n 4096
bash: ulimit: open .les: cannot modify limit: Opera/on not permi@ed
$ ulimit -n
2048

¡No es posible hacerlo!

Tenga en cuenta que si hubiéramos escogido un límite diferente, como el tamaño del stack (-s),
podríamos aumentar el valor nuevamente debido a que el límite hard es unlimited.

LFS201: Fundamentos de Administración de Sistemas Linux 274


20.17 Laboratorio 20.2
Laboratorio 20.2: Examinar la ac/vidad de System V IPC

System V IPC es un método bastante an/guo de Comunicación Entre Procesos (IPC) que se
remonta a los primeros días de UNIX. Este involucra tres mecanismos:
 Segmentos de memoria compar/da
 Semáforos
 Colas de mensajes

Algunos programas modernos /enen a usar los métodos de POSIX IPC para esos tres mecanismos,
pero todavía se puede encontrar un montón de aplicaciones System V IPC.
Ejecute el siguiente comando para obtener un resumen general de la ac/vidad System V IPC en su
sistema:
$ ipcs
------ Message Queues --------
key msqid owner perms used-bytes messages
------ Shared Memory Segments --------

key shmid owner perms bytes na@ch status


0x01114703 0 root 600 1000 6
0x00000000 98305 coop 600 4194304 2 dest
0x00000000 196610 coop 600 4194304 2 dest
0x00000000 23068675 coop 700 1138176 2 dest
0x00000000 23101444 coop 600 393216 2 dest
0x00000000 23134213 coop 600 524288 2 dest
0x00000000 24051718 coop 600 393216 2 dest
0x00000000 23756807 coop 600 524288 2 dest
0x00000000 24018952 coop 600 67108864 2 dest
0x00000000 23363593 coop 700 95408 2 dest
0x00000000 1441811 coop 600 2097152 2 dest

------ Semaphore Arrays --------

key semid owner perms nsems


0x00000000 98304 apache 600 1
0x00000000 131073 apache 600 1
0x00000000 163842 apache 600 1
0x00000000 196611 apache 600 1
0x00000000 229380 apache 600 1

LFS201: Fundamentos de Administración de Sistemas Linux 275


Tenga en cuenta que casi todos los segmentos de memoria compar/da actualmente en ejecución
/enen 0 en el campo key (también conocido como IPC_PRIVATE), lo cual signi.ca que solo se
comparten entre procesos en una relación padre/hijo. Además, todos con la excepción de uno,
están marcados para destrucción, ya que no /enen procesos asociados.
Es posible obtener más información acerca de los procesos que han creado los segmentos y que se
han asociado a ellos con:
$ ipcs –p
------ Message Queues PIDs --------
msqid owner lspid lrpid

------ Shared Memory Creator/Last-op PIDs --------

shmid owner cpid lpid


0 root 1023 1023
98305 coop 2265 18780
196610 coop 2138 18775
23068675 coop 989 1663
23101444 coop 989 1663
23134213 coop 989 1663
24051718 coop 20573 1663
23756807 coop 10735 1663
24018952 coop 17875 1663
23363593 coop 989 1663
1441811 coop 2048 20573

Por lo tanto, haciendo:


$ ps aux |grep -e 20573 -e 2048
coop 2048 5.3 3.7 1922996 305660 ? Rl Oct27 77:07 /usr/bin/gnome-shell
coop 20573 1.9 1.7 807944 141688 ? Sl 09:56 0:01 /usr/lib64/thunderbird/thunderbird
coop 20710 0.0 0.0 112652 2312 pts/0 S+ 09:57 0:00 grep—color=auto -e 20573 -e 2048

LFS201: Fundamentos de Administración de Sistemas Linux 276


vemos que thunderbird está usando un segmento de memoria compar/da creado por gnome-
shell.
Realice estos pasos en su sistema e iden/.que los diversos recursos que están siendo usados y por
quién. ¿Hay alguna fuga potencial en el sistema (recursos compar/dos que no están en uso por
ningún proceso)? Por ejemplo:
$ ipcs
....
------ Shared Memory Segments --------
key shmid owner perms bytes na@ch status
....
0x00000000 622601 coop 600 2097152 2 dest
0x0000001a 13303818 coop 666 8196 0
....

muestra un segmento de memoria compar/da que no /ene procesos asociados y que no está
marcado para ser destruido. Por lo anterior, si el proceso con/núa así para siempre y no se asocia a
ningún proceso, podría signi.car una fuga de memoria.

Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Describir un proceso y los recursos asociados a él.
 Distinguir entre procesos, programas y hebras.
 Comprender los atributos de procesos, permisos y estados.
 Saber la diferencia entre la ejecución de un programa en modo usuario y kernel.
 Describir los procesos demonio (daemon).
 Comprender cómo se crean los procesos nuevos.
 Usar nice y renice para configurar y modificar las prioridades.

LFS201: Fundamentos de Administración de Sistemas Linux 277


Capítulo 21. Señales
Las señales se usan para emitir notificaciones para que los procesos tomen acción en
respuesta a eventos que generalmente son impredecibles. Estos pueden ser generados
desde dentro de un proceso, o desde eventos externos y otros procesos. Muchas señales
son fatales y resultan en el término del proceso. Sin embargo, la muerte de los procesos
se puede evitar si los desarrolladores del programa deciden manejar ciertas señales de
finalización.
Por otro lado, muchas señales son más benignas y son informativas solamente o solicitan
otro tipo de acciones. Es posible enviar señales (incluyendo aquellas que inducen a la
finalización de un proceso) desde la línea de comandos usando kill, killall y pkill.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Explicar qué son las señales y cómo se usan.
 Conocer los diferentes tipos de señales que están disponible en Linux.
 Usar kill, killall and pkill para enviar señales desde la línea de comandos.

LFS201: Fundamentos de Administración de Sistemas Linux 278


21.1 Qué son las señales?

Las señales son uno de los métodos más antiguos de Comunicación Inter-
Procesos (IPC) y se usan para notificar procesos acerca de eventos asincrónicos (o
excepciones).
Por asincrónico entendemos que el proceso receptor de la señal puede:

 No esperar que ocurra el evento.

 Esperar el evento, pero no saber en qué momento va a ocurrir.

Por ejemplo, si un usuario decide terminar un programa en ejecución, podría enviar una
señal al proceso a través del kernel para interrumpir y finalizar el proceso.

Hay dos vías a través de las cuales se envían señales a los procesos:

 Desde el kernel a un proceso de usuario como resultado de una excepción o de un


error de programación.

 Desde un proceso de usuario (usando una llamada al sistema) al kernel, el cual la


enviará a un proceso de usuario. El proceso que envía la señal puede ser el
mismo que la reciba de vuelta.

Las señales solamente pueden enviarse entre procesos de propiedad del mismo usuario,
o desde un proceso del superusuario a cualquier proceso.
Cuando un proceso recibe una señal, lo que hará a continuación depende de la forma en
la cual el programa está escrito. Puede tomar acciones específicas, codificadas en el
programa para manipular la señal, o solo responder de acuerdo a los valores por defecto
en el sistema. Dos señales (SIGKILL y SIGSTOP, que se mencionarán en seguida) no
pueden ser manipuladas y siempre finalizarán el programa.

21.2 Tipos de señales

Hay una variedad de tipos de señales, y la señal en particular que es enviada indica el
tipo de evento (o excepción) ocurrida. Generalmente las señales se usan para manejar
dos cosas:
1. Excepciones detectadas por el hardware (tal como una referencia ilegal a
memoria).

2. Excepciones generadas por el ambiente (tal como la finalización prematura de un


proceso desde la terminal del usuario).

Para ver una lista de las señales en Linux, junto con los números correspondientes, haga
lo siguiente:

LFS201: Fundamentos de Administración de Sistemas Linux 279


$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX

Las señales de SIGRTMIN se denominan como de tiempo real y son una adición
relativamente reciente. No tienen un propósito predefinido y difieren de forma importante
en algunos aspectos con relación a las señales normales; pueden ser encoladas y son
manejadas en orden FIFO (First In First Out).

El significado implícito en el tipo de señal indica qué evento causó que fuera enviada.
Mientras los usuarios pueden explícitamente enviar cualquier tipo de señal a uno de sus
procesos, el significado implícito podría no estar relacionado al número o tipo de la señal,
y puede usarse en cualquier forma que el proceso desea.

man 7 signal le dará mayor información al respecto.

21.3 kill

Un proceso no puede enviar una señal directamente a otro proceso; este debe pedirle al
kernel que envíe la señal mediante la ejecución de una llamada al sistema. Los usuarios
(incluyendo el superusuario) pueden enviar señales a otros procesos desde la línea de
comandos o scripts usando kill, tal como se muestra a continuación:

$ kill 1991
$ kill -9 1991
$ kill -SIGKILL 1991

en el comando anterior enviamos una señal al proceso con PID = 1991. Si no se provee
un número de señal (como en el primer ejemplo), el valor por defecto a enviar es SIGTERM
(15), una señal de finalización que puede ser manipulada; el programa puede tomar una
acción evasiva o limpiarse a sí mismo en vez de finalizar inmediatamente. Si esta señal es
ignorada, el usuario puede enviar una SIGKILL (9), la cual no puede ser ignorada.

El nombre kill es un nombre realmente malo, el cual sobrevive por razones históricas.
Aunque a menudo se utiliza para matar (terminar) procesos, la función real del comando
es enviar cualquier y todas las señales a los procesos, incluso a los que son benignos y
totalmente informativos.

LFS201: Fundamentos de Administración de Sistemas Linux 280


LFS201: Fundamentos de Administración de Sistemas Linux 281
21.4 killall y pkill

killall termina todos los procesos con un nombre dado, en el caso que el usuario tenga
los permisos necesarios. Usa un nombre de comando en vez de un ID de proceso y
puede ser ejecutado así:

$ killall bash
$ killall -9 bash
$ killall -SIGKILL bash

pkill envía una señal a un proceso utilizando un criterio de selección:

$ pkill [-signal] [options] [pattern]

Por ejemplo:

$ pkill -u libby foobar

terminará todos los procesos de libby que se llamen foobar.


Otro ejemplo:

$ pkill -HUP rsyslogd

hace que rsyslog relea su archivo de configuración.

Comprobación de conocimientos 21.1

Comprobación de conocimientos 21.2

LFS201: Fundamentos de Administración de Sistemas Linux 282


Comprobación de conocimientos 21.3

Comprobación de conocimientos 21.4

LFS201: Fundamentos de Administración de Sistemas Linux 283


21.5 Laboratorio 21.1
Laboratorio 21.1: Examinar prioridades de las señalas y su ejecución

Le hemos proporcionado un programa en C que incluye un manejador de señales el que puede


manejar cualquier señal. El manejador en cues/ón evita hacer llamadas al sistema (tales como las
que podrían ocurrir mientras se realizan operaciones de E/S).

/*
* Examining Signal Priori/es and Execu/on.
*
* The code herein is: Copyright the Linux Founda/on, 2014
* Author: J. Cooperstein
*
* This Copyright is retained for the purpose of protec/ng free
* redistribu/on of source.
*
* This code is distributed under Version 2 of the GNU General Public
* License, which you should have received with the source.
* @*/

#include #include #include #include #include #include


#include
#include
#include
#include
#include
#de.ne NUMSIGS 64
/* prototypes of locally-de.ned signal handlers */

void (sig_handler) (int);


int sig_count[NUMSIGS + 1]; /* counter for signals received */
vola/le sta/c int line = 0;
vola/le int signumbuf[6400], sigcountbuf[6400];
int main(int argc, char *argv[])
{
sigset_t sigmask_new, sigmask_old;
struct sigac/on sigact, oldact;
int signum, rc, i;
pid_t pid;
pid = getpid();

/* block all possible signals */


rc = sig.llset(&sigmask_new);
rc = sigprocmask(SIG_SETMASK, &sigmask_new, &sigmask_old);
/* Assign values to members of sigac/on structures */

LFS201: Fundamentos de Administración de Sistemas Linux 284


memset(&sigact, 0, sizeof(struct sigac/on));
sigact.sa_handler = sig_handler; /* we use a pointer to a handler */
sigact.sa_jags = 0; /* no jags */
/* VERY IMPORTANT */
sigact.sa_mask = sigmask_new; /* block signals in the handler itself */

/*
* Now, use sigac/on to create references to local signal
* handlers * and raise the signal to myself
*

/ prins
("\nInstalling signal handler and Raising signal for signal number:\n\n");
for (signum = 1; signum <= NUMSIGS; signum++) {
if (signum == SIGKILL || signum == SIGSTOP || signum == 32
|| signum == 33) {
prins(" --");
con/nue;
}
sigac/on(signum, &sigact, &oldact);
/* send the signal 3 /mes! */
rc = raise(signum);
rc = raise(signum);
rc = raise(signum);
if (rc) {
prins("Failed on Signal %d\n", signum);
} else {
prins("%4d", signum);
if (signum % 16 == 0)
prins("\n");
}
}
yush(stdout);

/* restore original mask */


rc = sigprocmask(SIG_SETMASK, &sigmask_old, NULL);

prins("\nSignal Number(Times Processed)\n");


prins("--------------------------------------------\n");
for (i = 1; i <= NUMSIGS; i++) {
prins("%4d:%3d ", i, sig_count[i]);
if (i % 8 == 0)
prins("\n");
}

LFS201: Fundamentos de Administración de Sistemas Linux 285


prins("\n");

prins("\nHistory: Signal Number(Count Processed)\n");


prins("--------------------------------------------\n");
for (i = 0; i < line; i++) {
if (i % 8 == 0)
prins("\n");
prins("%4d(%1d)", signumbuf[i], sigcountbuf[i]);
}
prins("\n");
exit(EXIT_SUCCESS);
}
void sig_handler(int sig)
{
sig_count[sig]++;
signumbuf[line] = sig;
sigcountbuf[line] = sig_count[sig];
line++;
}

Si está tomando la versión autodidacta en línea de este curso, encontrará el código fuente
disponible para su descarga en la pantalla Lab. Necesitará compilarlo y ejecutarlo como se muestra
a con/nuación:

$ gcc -o signals signals.c


$ ./signals

Al ser ejecutado, el programa realiza lo siguiente:


 No envía las señales SIGKILL o SIGSTOP, las cuales no pueden ser manejadas y siempre
.nalizan un programa.
 Almacena la secuencia de señales a medida en que llegan y actualiza un arreglo de contadores
para cada señal que indica cuántas veces la señal ha sido manejada.
 Comienza por suspender el proceso de todas las señales y luego instala un conjunto nuevo de
manejadores de señal para todas ellas.
 Envía cada señal posible múl/ples veces, luego desbloquea el manejo de señales e invoca a los
manipuladores de señales que estaban en espera.
 Imprime las estadís/cas, incluyendo:
o El número total de veces que cada señal fue recibida.
o El orden en el cual se recibieron las señales, señalando cada vez el número total de
veces que la seáal se haía recibido hasta ese momento.
Tenga en cuenta lo siguiente:

LFS201: Fundamentos de Administración de Sistemas Linux 286


 Si una señal determinada se emite en varias oportunidades mientras el proceso las había
bloqueado, ¿el proceso las recibe múl/ples veces? ¿El comportamiento de señales en /empo
real es diferente de las señales normales?
 ¿El proceso recibe todas las señales, o algunas de ellas son manejadas antes que lleguen a él?
 ¿En qué orden se reciben las señales?

La señal SIGCONT (18 en x86 puede que no logre llegar a des/no, ¿se le ocurre por qué?

Nota:
En algunas distribuciones Linux las señales 32 y 33 no pueden ser bloqueadas y causarán que el
programa falle. A pesar de que los archivos de cabecera del sistema indican SIGRTMIN=32, el
comando kill -l indica SIGRTMIN=34. Tenga en cuenta que POSIX dice que se deberían usar
nombres en vez de números, los cuales están habilitados para ser completamente dependientes de
la implementación. En general se debeía evitar el envío de estas señales.

LFS201: Fundamentos de Administración de Sistemas Linux 287


Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Explicar qué son las señales y cómo se usan.
 Conocer los diferentes tipos de señales que están disponibles en Linux.
 Usar kill, killall and pkill para enviar señales desde la línea de comandos.

LFS201: Fundamentos de Administración de Sistemas Linux 288


Capítulo 22. Monitoreo del sistema
Linux tiene una amplia variedad disponible de herramientas de monitoreo del sistema,
incluyendo top, ps y sar. La mayoría de estas herramientas hacen un uso extensivo de
los pseudosistemas de archivos montados en /proc y /sys. Si bien es cierto que hay
interfaces gráficas (dependientes de la distribución), nos concentraremos en los métodos
de la línea de comandos.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Reconocer y usar las herramientas disponibles de monitoreo del sistema.
 Usar los pseudosistemas de archivos /proc y /sys.
 Usar sar para obtener información de la actividad y rendimiento del sistema, para
crear reportes en forma cómoda para su análisis.

LFS201: Fundamentos de Administración de Sistemas Linux 289


22.1 Herramientas disponibles de monitoreo

Las distribuciones Linux vienen con diversas herramientas estándar instaladas por
defecto para medir el rendimiento y visualizar el estado del sistema. Muchas de ellas
provienen de otros sistemas operativos tipo UNIX, mientras que otras fueron
desarrolladas específicamente para Linux.
La mayoría de estas herramientas hacen uso de pseudosistemas de archivos montados,
especialmente /proc, y /sys de forma secundaria (los cuales discutimos anteriormente
cuando tratamos los sistemas de archivos y configuración del kernel). En este capítulo
trabajaremos con ambos.
Aunque existe una serie de monitores gráficos del sistema, los cuales esconden muchos
detalles, en este curso consideraremos solamente las herramientas de la línea de
comandos.
Antes de considerar algunas de las herramientas principales veremos un resumen
clasificado por tipo; tenga en cuenta que algunas de las herramientas tienen dominios
superpuestos de cobertura.

LFS201: Fundamentos de Administración de Sistemas Linux 290


22.2 Los pseudosistemas de archivos /proc y /sys

Los pseudosistemas de archivos /proc y /sys contienen bastante información acerca del
sistema. Por otro lado, muchas de las entradas en estos árboles de directorios son
escribibles y pueden usarse para cambiar el comportamiento del sistema; en la mayoría
de los casos esto requiere del usuario root.

Estos son pseudosistemas de archivos porque existen totalmente en memoria; si usted


revisa la partición del disco cuando el sistema no está en ejecución, se dará cuenta que
solo hay un directorio vacío, el cual se usa como punto de montaje.

Por otra parte, la información que se despliega es obtenida solamente cuando se lee; no
hay un sondeo constante o periódico para actualizar las entradas.

22.3 Conceptos básicos de /proc

El pseudosistema de archivos /proc tiene una historia larga; tiene su origen en otras
variantes de sistemas operativos tipo UNIX y en un comienzo fue desarrollado para
desplegar información acerca de los procesos en el sistema, cada uno de los cuales
tiene su propio directorio en /proc, con todas las características importantes de los
procesos.

A través del tiempo creció para contener mucha información acerca de las propiedades
del sistema, tales como interrupciones, memoria, red, etc, en una forma un tanto
anárquica. Todavía es usado de forma extensiva y a menudo nos referiremos a él.

22.4 un vistazo de /proc

Echemos un vistazo a lo que hay en el pseudosistema de archivos /proc:

$ ls -F /proc
1/ 11214/ 15887/ 19/ 26/ 3706/ 509/ 614/ 7402/ asound/
modules
10/ 12/ 15891/ 1929/ 260/ 3707/ 510/ 619/ 741/ buddyinfo
mounts@
1017/ 1284/ 15896/ 1934/ 26218/ 3708/ 511/ 620/ 742/ bus/
mtrr
1018/ 1290/ 15899/ 1959/ 264/ 3709/ 512/ 622/ 743/ cgroups
net@
1023/ 13/ 15905/ 19950/ 265/ 3713/ 513/ 623/ 744/ cmdline
pagetypeinfo
1031/ 1301/ 15909/ 2/ 267/ 3714/ 514/ 625/ 761/ config.gz
partitions
10544/ 14/ 15912/ 2008/ 268/ 375/ 515/ 626/ 763/ consoles
sched_debug
10545/ 1400/ 15919/ 2079/ 27/ 396/ 517/ 641/ 7699/ cpuinfo
schedstat
1061/ 1444/ 15928/ 21/ 28/ 398/ 519/ 642/ 8/ crypto

LFS201: Fundamentos de Administración de Sistemas Linux 291


scsi/
10671/ 1452/ 15938/ 22/ 280/ 414/ 521/ 644/ 8036/ devices
self@
10802/ 1465/ 15941/ 2298/ 281/ 42/ 5302/ 645/ 8226/ diskstats
slabinfo
10803/ 1484/ 15944/ 23/ 29/ 43/ 537/ 648/ 824/ dma
softirqs
10911/ 1490/ 15957/ 237/ 3/ 4555/ 5376/ 649/ 8323/ driver/
stat
11/ 1503/ 15963/ 238/ 30/ 460/ 538/ 651/ 8435/ execdomains
swaps
11087/ 15466/ 15966/ 239/ 30170/ 480/ 5503/ 652/ 8443/ fb
sys/
11089/ 15471/ 15982/ 24/ 31/ 481/ 5506/ 66/ 8444/ filesystems
sysrq-trigger
11090/ 15616/ 16/ 240/ 32/ 482/ 5515/ 67/ 845/ fs/
sysvipc/
11103/ 1563/ 16016/ 241/ 33/ 484/ 5516/ 68/ 8479/ interrupts
timer_list
11104/ 15632/ 16030/ 242/ 34/ 485/ 5524/ 684/ 8594/ iomem
timer_stats
11105/ 15642/ 16037/ 243/ 35/ 486/ 5525/ 690/ 8633/ ioports
tty/
11123/ 15650/ 16039/ 244/ 3557/ 489/ 5530/ 697/ 8643/ irq/
uptime
11124/ 15651/ 16065/ 245/ 3558/ 491/ 5531/ 698/ 8644/ kallsyms
version
11125/ 1570/ 16066/ 246/ 3560/ 494/ 5536/ 699/ 8726/ kcore
vmallocinfo
11126/ 1571/ 16071/ 247/ 36/ 496/ 559/ 7/ 8903/ keys
vmnet/
11163/ 15719/ 16073/ 248/ 3687/ 498/ 560/ 701/ 9/ key-users
vmstat
11165/ 15723/ 16089/ 24819/ 3697/ 5/ 5645/ 709/ 9277/ kmsg
zoneinfo
11166/ 15791/ 16112/ 24822/ 3698/ 500/ 5665/ 712/ 9284/ kpagecount
11187/ 1582/ 1621/ 24823/ 3699/ 501/ 5678/ 714/ 9816/ kpageflags
11194/ 15837/ 16477/ 24879/ 37/ 502/ 583/ 715/ 9853/ latency_stats
11196/ 15840/ 16515/ 257/ 3702/ 503/ 584/ 717/ 9871/ loadavg
11197/ 15844/ 1654/ 258/ 3703/ 504/ 599/ 718/ 988/ locks
11199/ 15847/ 17/ 259/ 3704/ 505/ 600/ 723/ 9885/ meminfo
11206/ 15871/ 18/ 2591/ 3705/ 507/ 613/ 727/ acpi/ misc

Primero vemos que hay un subdirectorio por cada proceso en el sistema, ya sea si están
durmiendo, en ejecución o programados. Revisando uno al azar:

$ ls -lF /proc/16477
total 0
-r-------- 1 coop coop 0 Sep 10 18:11 auxv
-r—r—r-- 1 coop coop 0 Sep 10 12:28 cgroup—w------- 1 coop coop 0 Sep 10
18:11 clear_refs
-r—r—r-- 1 coop coop 0 Sep 10 08:30 cmdline
-rw-r—r-- 1 coop coop 0 Sep 10 12:28 comm
-rw-r—r-- 1 coop coop 0 Sep 10 18:11 coredump_filter
-r—r—r-- 1 coop coop 0 Sep 10 18:11 cpuset
lrwxrwxrwx 1 coop coop 0 Sep 10 18:11 cwd -> /usr/local/coop7/
-r-------- 1 coop coop 0 Sep 10 18:11 environ

LFS201: Fundamentos de Administración de Sistemas Linux 292


lrwxrwxrwx 1 coop coop 0 Sep 10 08:30 exe ->
/usr/lib64/thunderbird/thunderbird*
dr-x------ 2 coop coop 0 Sep 10 08:30 fd/
dr-x------ 2 coop coop 0 Sep 10 18:11 fdinfo/
-rw-r—r-- 1 coop coop 0 Sep 10 18:11 gid_map
• r-------- 1 coop coop 0 Sep 10 18:11 io
-r—r—r-- 1 coop coop 0 Sep 10 18:11 latency
-r—r—r-- 1 coop coop 0 Sep 10 18:11 limits
-r—r—r-- 1 coop coop 0 Sep 10 08:30 maps
-rw------- 1 coop coop 0 Sep 10 18:11 mem
-r—r—r-- 1 coop coop 0 Sep 10 08:30 mountinfo
-r—r—r-- 1 coop coop 0 Sep 10 18:11 mounts
-r-------- 1 coop coop 0 Sep 10 18:11 mountstats
dr-xr-xr-x 4 coop coop 0 Sep 10 18:11 net/
dr-x—x—x 2 coop coop 0 Sep 10 18:11 ns/
-rw-r—r-- 1 coop coop 0 Sep 10 18:11 oom_adj
-r—r—r-- 1 coop coop 0 Sep 10 18:11 oom_score
-rw-r—r-- 1 coop coop 0 Sep 10 18:11 oom_score_adj
-r-------- 1 coop coop 0 Sep 10 18:11 pagemap
-r-------- 1 coop coop 0 Sep 10 18:11 personality
-rw-r—r-- 1 coop coop 0 Sep 10 18:11 projid_map
lrwxrwxrwx 1 coop coop 0 Sep 10 18:11 root -> //
-rw-r—r-- 1 coop coop 0 Sep 10 18:11 sched
-r—r—r-- 1 coop coop 0 Sep 10 18:11 schedstat
-r—r—r-- 1 coop coop 0 Sep 10 18:11 smaps
-r-------- 1 coop coop 0 Sep 10 18:11 stack
-r—r—r-- 1 coop coop 0 Sep 10 08:35 stat
-r—r—r-- 1 coop coop 0 Sep 10 16:59 statm
-r—r—r-- 1 coop coop 0 Sep 10 08:31 status
-r-------- 1 coop coop 0 Sep 10 18:11 syscall
dr-xr-xr-x 35 coop coop 0 Sep 10 10:10 task/
-rw-r—r-- 1 coop coop 0 Sep 10 18:11 uid_map
-r—r—r-- 1 coop coop 0 Sep 10 18:11 wchan

vemos que este corresponde al cliente de correo electrónico thunderbird. Este directorio
está lleno de información, tanto acerca del estado y de los recursos que el proceso está
usando. Por ejemplo:

$ cat /proc/16477/status
Name: thunderbird
State: S (sleeping)
Tgid: 16477
Ngid: 0
Pid: 16477
PPid: 15912
TracerPid: 0
Uid: 500 500 500 500
Gid: 500 500 500 500
FDSize: 256
Groups: 500
VmPeak: 1262996 kB
VmSize: 1139452 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 241644 kB
VmRSS: 201404 kB

LFS201: Fundamentos de Administración de Sistemas Linux 293


VmData: 435360 kB
VmStk: 224 kB
VmExe: 88 kB
VmLib: 89756 kB
VmPTE: 1488 kB
VmSwap: 0 kB
Threads: 33
SigQ: 1/31853
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000f800144ef
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 590633
nonvoluntary_ctxt_switches: 5881

Otras entradas proveen información de todo el sistema. Por ejemplo, las estadísticas
de interrupciones se muestran aquí:

$ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 127 0 0 0 IO-APIC-edge timer
1: 22610 26632 22019 24652 IO-APIC-edge i8042
8: 0 0 1 0 IO-APIC-edge rtc0
9: 0 0 0 0 IO-APIC-fasteoi acpi
16: 10 13 13 11 IO-APIC-fasteoi uhci_hcd:usb3
18: 81801 33810 269011 97396 IO-APIC-fasteoi ehci_hcd:usb1,
uhci_hcd:usb5, uhci_hcd:usb8,enp4s2
19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb7
21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4
23: 459503 414973 2294258 1886762 IO-APIC-fasteoi ehci_hcd:usb2,
uhci_hcd:usb6
43: 7839477 12 17 14 PCI-MSI-edge enp2s0
44: 90833 73862 431567 197408 PCI-MSI-edge ahci
45: 2308942 2324143 2037740 2226651 PCI-MSI-edge nouveau
46: 1706 1853 1806 1740 PCI-MSI-edge snd_hda_intel
NMI: 4021 3150 3201 3076 Non-maskable interrupts
LOC: 8186969 8028365 8257507 7848638 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 4021 3150 3201 3076 Performance monitoring interrupts
IWI: 455847 423644 402570 390176 IRQ work interrupts
RTR: 0 0 0 0 APIC ICR read retries
RES: 6489645 6430364 6430834 6271845 Rescheduling interrupts
CAL: 4816017 4550737 4171364 4829737 Function call interrupts
TLB: 909001 1140883 879189 1152043 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 Machine check exceptions

LFS201: Fundamentos de Administración de Sistemas Linux 294


MCP: 133 133 133 133 Machine check polls
ERR: 0
MIS: 0

Para cada interrupción vemos su tipo, cuántas veces ha sido manipulada en cada CPU y
qué dispositivos están registrados para responder a ella. También obtenemos estadísticas
globales.

22.5 /proc/sys

La mayoría de los parámetros ajustables del sistema pueden encontrarse en el árbol de


subdirectorios /proc/sys:

$ ls -F /proc/sys
total 0
dr-xr-xr-x 1 root root 0 Sep 10 18:17 abi/
dr-xr-xr-x 1 root root 0 Sep 10 18:17 debug/
dr-xr-xr-x 1 root root 0 Sep 10 15:53 dev/
dr-xr-xr-x 1 root root 0 Sep 10 02:14 fs/
dr-xr-xr-x 1 root root 0 Sep 10 02:14 kernel/
dr-xr-xr-x 1 root root 0 Sep 10 18:17 net/
dr-xr-xr-x 1 root root 0 Sep 10 16:10 vm/

Cada uno de estos subdirectorios contiene información como también controles que
pueden ser ajustados (con cuidado):
 abi/
Contiene archivos con información binaria de aplicaciones; raramente se usa.

 debug/
Parámetros de depuración; por ahora solo un control de reportes de excepción.

 dev/
Parámetros de dispositivo incluyendo subdirectorios para
cdrom, scsi, raid y parport.

 fs/
Parámetros de sistemas de archivos, incluyendo cuota, identificadores de archivos
usados y máximos, información de inodos y directorios, etc

 kernel/
Parámetros del kernel. Hay muchas entradas importantes aquí.

 net/
Parámetros de red. Hay subdirectorios para ipv4, netfilter, etc.

 vm/
Parámetros de memoria virtual. Hay muchas entradas importantes aquí.

LFS201: Fundamentos de Administración de Sistemas Linux 295


Ver y cambiar los parámetros puede ser realizarse con comandos simples. Por ejemplo, el
número máximo de hilos permitidos en el sistema puede verse así:

$ ls -l /proc/sys/kernel/threads-max
$ cat /proc/sys/kernel/threads-max 129498

Entonces podemos modificar el valor y verificar que el cambio tuvo efecto:

$ sudo bash -c ‘echo 100000 > /proc/sys/kernel/threads-max’


$ cat /proc/sys/kernel/threads-max 100000

Recuerde de la discusión acerca de sysctl que lo mismo se consigue con:

$ sudo sysctl kernel.threads-max=100000

Los usuarios normales pueden visualizar los valores, sin embargo para modificarlos se
requiere de privilegios de superusuario.

22.6 Conceptos básicos de /sys

El pseudosistema de archivos /sys es una parte integral de lo que se llama el Modelo


Unificado de Dispositivos(Unified Device Model). Conceptualmente está basado en
un árbol de dispositivos a través del cual se puede ir y ver los buses, dispositivos,
controladores, etc. También contiene información que puede o no estar relacionada
estrictamente a los dispositivos, tales como los módulos del kernel.

Tiene una estructura más definida que /proc. La mayoría de las entradas contienen solo
una línea de texto, aunque existen excepciones, no llega a ser como su precedesor
(/proc), el cual tiene entradas de múltiples líneas cuyo contenido exacto ha ido
cambiando entre versiones del kernel. Por lo tanto, la interfaz de /sys es más estable
hasta el momento.

Hay propiedades del sistema que tienen entradas tanto en /proc como en /sys; los ítems
antiguos se están eliminando gradualmente con el fin de mantener una compatibilidad
entre las utilidades de sistema usadas ampliamente.

LFS201: Fundamentos de Administración de Sistemas Linux 296


22.7 Un vistazo de /sys

El soporte para el sistema de archivos virtual sysfs está construido en todos los kernel
modernos, y debería montarse bajo /sys. Sin embargo, el modelo unificado de
dispositivos no requiere que sysfs sea montado para entrar en operación.

Echemos un vistazo a lo que podemos encontrar usando el kernel 3.18; advertimos que el
diseño exacto de este sistema de archivos tiene una tendencia a cambiar. Al visualizar los
directorios de nivel superior encontramos:

$ ls -F /sys
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/

lo cual despliega la jerarquía básica de dispositivos. La implementación del modelos de


dispositivos sysfs también incluye información que no está estrictamente relacionada a
hardware.

Los dispositivos de red pueden examinarse con:

$ ls -lF /sys/class/net
total 0
lrwxrwxrwx 1 root root 0 Apr 30 11:38 eth0 -> \

../../devices/pci0000:00/0000:00:1c.5/0000:02:00.0/net/eth0/
lrwxrwxrwx 1 root root 0 Apr 30 11:38 eth1 -> \

../../devices/pci0000:00/0000:00:1e.0/0000:04:02.0/net/eth1/
lrwxrwxrwx 1 root root 0 Apr 30 06:38 lo -> \

../../devices/virtual/net/lo/

al mirar la primera tarjeta Ethernet obtenemos:

$ ls -l /sys/class/net/eth0/
total 0
-r—r—r-- 1 root root 4096 Apr 30 13:43 addr_assign_type
-r—r—r-- 1 root root 4096 Apr 30 11:38 address
-r—r—r-- 1 root root 4096 Apr 30 11:38 addr_len
-r—r—r-- 1 root root 4096 Apr 30 13:43 broadcast
-r—r—r-- 1 root root 4096 Apr 30 13:43 carrier
lrwxrwxrwx 1 root root 0 Apr 30 11:38 device -> ../../../0000:02:00.0
-r—r—r-- 1 root root 4096 Apr 30 13:43 dev_id
-r—r—r-- 1 root root 4096 Apr 30 13:43 dormant
-r—r—r-- 1 root root 4096 Apr 30 13:43 duplex
-rw-r—r-- 1 root root 4096 Apr 30 11:38 flags
-rw-r—r-- 1 root root 4096 Apr 30 13:43 ifalias
-r—r—r-- 1 root root 4096 Apr 30 11:38 ifindex
-r—r—r-- 1 root root 4096 Apr 30 13:43 iflink
-r—r—r-- 1 root root 4096 Apr 30 13:43 link_mode
-rw-r—r-- 1 root root 4096 Apr 30 13:43 mtu
-rw-r—r-- 1 root root 4096 Apr 30 13:43 netdev_group
-r—r—r-- 1 root root 4096 Apr 30 13:43 operstate
drwxr-xr-x 2 root root 0 Apr 30 13:43 power
LFS201: Fundamentos de Administración de Sistemas Linux 297
drwxr-xr-x 4 root root 0 Apr 30 11:38 queues
-r—r—r-- 1 root root 4096 Apr 30 13:43 speed
drwxr-xr-x 2 root root 0 Apr 30 13:43 statistics
lrwxrwxrwx 1 root root 0 Apr 30 11:38 subsystem ->
../../../../../../class/net
-rw-r—r-- 1 root root 4096 Apr 30 13:43 tx_queue_len
-r—r—r-- 1 root root 4096 Apr 30 11:38 type
-rw-r—r-- 1 root root 4096 Apr 30 11:38 uevent

$ cat /sys/class/net/eth0/mtu
1500

La intención de sysfs es tener un valor de texto por línea, aunque no se espera que esto
se aplique rigurosamente.

El dispositivo y controlador subyacente para la primera interfaz de red pueden encontrarse


a través de device y de los enlaces simbólicos de driver (lo cual vamos a revisar
pronto). Si vemos el directorio correspondiente a la primera tarjeta Ethernet veremos lo
siguiente:

$ ls -l /sys/class/net/eth0/device/
total 0
-rw-r—r-- 1 root root 4096 Apr 30 13:47 broken_parity_status
-r—r—r-- 1 root root 4096 Apr 30 06:38 class
-rw-r—r-- 1 root root 4096 Apr 30 11:38 config
-r—r—r-- 1 root root 4096 Apr 30 13:47 consistent_dma_mask_bits
-r—r—r-- 1 root root 4096 Apr 30 11:38 device
-r—r—r-- 1 root root 4096 Apr 30 13:47 dma_mask_bits
lrwxrwxrwx 1 root root 0 Apr 30 11:38 driver ->
../../../../bus/pci/drivers/sky2/
-rw------- 1 root root 4096 Apr 30 13:47 enable
-r—r—r-- 1 root root 4096 Apr 30 11:38 irq
-r—r—r-- 1 root root 4096 Apr 30 13:47 local_cpulist
-r—r—r-- 1 root root 4096 Apr 30 11:38 local_cpus
-r—r—r-- 1 root root 4096 Apr 30 13:47 modalias
-rw-r—r-- 1 root root 4096 Apr 30 13:47 msi_bus
drwxr-xr-x 3 root root 0 Apr 30 13:47 msi_irqs/
drwxr-xr-x 3 root root 0 Apr 30 11:38 net/
drwxr-xr-x 2 root root 0 Apr 30 13:47 power/
--w—w---- 1 root root 4096 Apr 30 13:47 remove—w—w---- 1 root root
4096 Apr 30 13:47 rescan—w------- 1 root root 4096 Apr 30 13:47 reset
-r—r—r-- 1 root root 4096 Apr 30 13:45 resource
-rw------- 1 root root 16384 Apr 30 13:47 resource0
-rw------- 1 root root 256 Apr 30 13:47 resource2
-rw------- 1 root root 131072 Apr 30 13:47 rom
lrwxrwxrwx 1 root root 0 Apr 30 11:38 subsystem ->
../../../../bus/pci/
-r—r—r-- 1 root root 4096 Apr 30 11:38 subsystem_device
-r—r—r-- 1 root root 4096 Apr 30 11:38 subsystem_vendor
-rw-r—r-- 1 root root 4096 Apr 30 06:38 uevent
-r—r—r-- 1 root root 4096 Apr 30 11:38 vendor
-rw------- 1 root root 32768 Apr 30 13:47 vpd

Para ver la gama completa de información que está disponible en sysfs tendrá que
examinar el directorio.

LFS201: Fundamentos de Administración de Sistemas Linux 298


22.8 sar

sar viene de Systems Activity Reporter (informador de actividad del sistema). Es una
herramienta multipropósito para obtener información acerca de la actividad y rendimiento
del sistema, como también para crear reportes de lectura fácil.

En los sistemas Linux el backend de sar es sadc (recopilador de información de actividad


del sistema), el cual acumula las estadísticas. Este almacena la información en el
directorio /var/log/sa, en una frecuencia diaria por defecto, la cual puede ser ajustada.
La recolección de información puede ser iniciada desde la línea de comandos, y de forma
períodica se realiza desde una tarea de cron almacenada en /etc/cron.d/sysstat.

Entonces sar lee esa información (ya sea desde la ubicación por defecto o usando el
archivo especificado con la opción -f) y luego produce un reporte.

sar se ejecuta de la siguiente forma:

$ sar [ options ] [ interval ] [ count ]

en donde el reporte se repite luego de un intervalo de segundos por un número de veces


(la cual es 1 por defecto). Sin opciones resulta así:

$ sar 3 3
Linux 3.15.9 (q7) 09/26/2014 _x86_64_ (4 CPU)
12:27:32 PM CPU %user %nice %system %iowait %steal %idle
12:27:35 PM all 1.34 0.00 0.33 0.67 0.00 97.66
12:27:38 PM all 7.08 0.00 2.98 0.34 0.00 89.60
12:27:41 PM all 10.60 0.00 1.09 0.08 0.00 88.23
Average: all 6.32 0.00 1.46 0.37 0.00 91.85

entregando un reporte del uso de la CPU.

Aquí hay una lista de las opciones o modos más importantes de sar, en donde cada una
tiene sus propias subopciones:

Tabla 22.5: Opciones de sar


Opción Significado
-A Casi toda la información
-b E/S y estadísticas de las tasas de transferencia (similar a iostat)
-B Estadísticas de paginación, incluyendo los errores de pagǵina
-x Actividad de dispositivos de bloque (similar a iostat -x)
-n Estadísticas de red
-P Estadísticas por CPU (como en sar -P ALL 3)
-q Longitud de las colas (cola de ejecución, procesos e hilos)

LFS201: Fundamentos de Administración de Sistemas Linux 299


-r Estadísticas de uso de memoria y área de intercambio
-R Estadísticas de memoria
-u Uso de CPU (por defecto)
-v Estadísticas acerca de inodos, archivos e identificadores de archivo.
-w Estadísticas de cambio de contexto
Estadísticas de la memoria de intercambio, página de entrada y salida
-W
por segundo
Extrae información desde el archivo especificado, creado con la
-f
opción -o

Almacena los datos en el archivo especificado, para ser leído más tarde
-o
con la opción -f

Por ejemplo, para obtener las estadísticas de paginación:

$ sar -B 3 3
Linux 3.15.9 (q7) 09/26/2014 _x86_64_ (4 CPU)

12:28:51 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s


pgscand/s pgsteal/s %vmeff
12:28:54 PM 0.00 21.33 82.33 0.00 676.67 0.00
0.00 0.00 0.00
12:28:57 PM 0.00 13.33 43.33 0.00 285.00 0.00
0.00 0.00 0.00
12:29:00 PM 0.00 9.33 428.00 0.00 1029.00 0.00
0.00 0.00 0.00
Average: 0.00 14.67 184.56 0.00 663.56 0.00
0.00 0.00 0.00

para obtener las estadísticas de E/S y tasa de transferencia:

$ sar -b 3 3

Linux 3.15.9 (q7) 09/26/2014 _x86_64_ (4 CPU)

12:29:30 PM tps rtps wtps bread/s bwrtn/s


12:29:33 PM 8.00 5.00 3.00 597.33 72.00
12:29:36 PM 0.00 0.00 0.00 0.00 0.00
12:29:39 PM 16.33 0.00 16.33 0.00 237.33
Average: 8.11 1.67 6.44 199.11 103.11

El programa ksar es una herramienta basada en java para generar gráficos agradables a
partir de datos de sar. Puede descargarse desde http://sourceforge.net/projects/ksar .

Comprobación de conocimientos 22.1

LFS201: Fundamentos de Administración de Sistemas Linux 300


Comprobación de conocimientos 22.2

Comprobación de conocimientos 22.3

LFS201: Fundamentos de Administración de Sistemas Linux 301


Comprobación de conocimientos 22.4

22.9 Laboratorio 22.1


Laboratorio 22.1: Uso de stress
stress es un programa escrito en lenguaje C por Amos Waterland de la Universidad de Oklahoma,
licenciado bajo la GPL v2. Está diseñado para imponer una can/dad con.gurable de estrés a través
de la generación de varios /pos de carga de trabajo en el sistema.
Si usted /ene suerte podrá instalar stress directamente desde el sistema de empaquetamiento de
su distribución. De lo contrario, puede obtener el código fuente desde
h@p://people.seas.harvard.edu/~apw/stress y luego compilarlo de la siguiente forma:
$ tar zxvf stress-1.0.4.tar.gz
$ cd stress-1.0.4
$ ./con.gure
$ make
$ sudo make install

Pueden exis/r paquetes binarios descargables en los formatos .deb y .rpm; revise el si/o web para
detalles y ubicaciones de los mismos. Una vez que está instalado, puede hacer:
$ stress—help

para obtener una lista rápida de opciones, o

$ info stress

para acceder a una documentación más detallada.

LFS201: Fundamentos de Administración de Sistemas Linux 302


Por ejemplo, el siguiente comando:
$ stress -c 8 -i 4 -m 6 -t 20s
will:
 Creará 8 procesos intensivos en la CPU, cada uno realizando un cálculo sqrt().
 Creará 4 procesos intensivos de E/S, cada uno realizando una operación sync().
 Creará 6 procesos intensivos de memoria, cada uno realizando una operación malloc(),
asignando 256 MB por defecto. El tamaño puede cambiarse con la opción—vm-bytes
128M.
 Ejecutar la prueba de estr´es por 20 segundos.

Luego de haber instalado stress, usted puede iniciar el monitor de sistema grá.co, el cual
seguramente encontrará en el menú de aplicaciones. También lo puede ejecutar desde la línea de
comandos, ya sea gnome-system-monitor o ksysguard.
Ahora comience a poner estrés en el sistema. Los números exactos que usarán estarán en función
de los recursos de su sistema, tales como el número de CPU y el tamaño de la RAM.
Por ejemplo, si hace
$ stress -m 4 -t 20s

estresa solamente la memoria del sistema. Juegue con las combinaciones de los parámetros y vea
el impacto que generan entre ellos. Probablemente se de cuenta que el programa stress es ú/l
para simular diversas condiciones de carga alta.

Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Reconocer y usar las herramientas disponibles de monitoreo del sistema.
 Usar los pseudosistemas de archivos /proc y /sys.
 Usar sar para obtener información de la actividad y rendimiento del sistema, para
crear reportes en forma cómoda para su análisis.

LFS201: Fundamentos de Administración de Sistemas Linux 303


Capítulo 23. Monitoreo de procesos
Realizar un seguimiento de los procesos en ejecución (y durmiendo) es una tarea de
administración primordial. El programa ps ha sido la herramienta principal para hacer esto
en sistemas basados en UNIX por décadas.

Sin embargo, debido a que la herramienta ha tenido una larga y compleja historia de ser
usada de forma diferente en una variedad de sistemas operativos, tiene muchas opciones
que al combinarlas pueden llevar a confusión. Otra herramienta valiosa es top, la cual
monitorea el estado del sistema de forma interactiva.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Usar ps para visualizar características y estadísticas asociadas a procesos.
 Identificar diferentes campos de salida de ps y personalizar la salida del comando.
 Usar pstree para obtener una descripción visual de la ascendencia de los
procesos y aplicaciones multihilos.
 Usar top para visualizar la carga del sistema interactivamente.

LFS201: Fundamentos de Administración de Sistemas Linux 304


23.1 Herramientas de monitoreo

En esta sección nos concentraremos en monitoreo de procesos. Para llevar a cabo esto,
los administradores de Linux hacen uso de muchas herramientas, tales como
ps, pstree y top, todos los que tienen una larga historia en los sistemas operativos
tipo UNIX.

Revisaremos nuevamente la lista de algunas de las herramientas principales para


monitoreo de procesos:

Tabla 23.1: Herramientas de monitoreo de procesos y carga

Herramienta Propósito Paquete


Actualiza de forma dinámica la actividad de
top procps
los procesos
Por cuánto tiempo ha estado corriendo el
uptime procps
sistema y la carga promedio
ps Información detallada acerca de los procesos procps
pstree Un árbol de procesos y sus conexiones psmisc (o pstree)
mpstat Uso de procesador múltiple sysstat
iostat Uso de CPU y estadísticas de E/S sysstat
Despliegue y recolección de información
sar sysstat
acerca de la actividad del sistema
Información de NUMA (Arquitectura de
numastat numactl
memoria no uniforme)
Información acerca de todas las llamadas al
strace strace
sistema realizadas por un proceso

23.2 Visualización del estado de los procesos con ps

ps es un caballo de batalla para desplegar características y estadísticas asociadas a


procesos, todo lo cual se obtiene desde el directorio asociado al proceso en /proc.
Esta herramienta ha existido en todas las variantes del sistema operativo UNIX y esta
diversidad se refleja en la complicada mezcla de opciones que acepta la versión
de ps en Linux, las cuales se dividen en tres categorías:
1. Opciones UNIX, las cuales deben ser precedidas por -, y que pueden estar agrupadas.
2. Opciones BSD, las cuales no deben ser precedidas por -, y que pueden estar
agrupadas.
3. Las opciones largas de GNU, cada una de las cuales debe ser precedida por --.

Tener todas estas opciones posibles puede tornar la vida del administrador de sistemas
un poco confusa. Muchos de ellos tienden a usar una o dos combinaciones estándar para
su uso diario.
LFS201: Fundamentos de Administración de Sistemas Linux 305
23.3 Opción de formato BSD para ps

Un uso típico con la opción de formato BSD para ps es:

$ ps aux

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 198384 6232 ? Ss 07:14 0:01
/usr/lib/systemd/systemd—switched-root -
root 2 0.0 0.0 0 0 ? S 07:14 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S 07:14 0:03 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< 07:14 0:00 [kworker/0:0H]
root 7 0.0 0.0 0 0 ? S 07:14 0:22 [rcu_preempt]
root 8 0.0 0.0 0 0 ? S 07:14 0:00 [rcu_sched]
root 9 0.0 0.0 0 0 ? S 07:14 0:00 [rcu_bh]
root 10 0.0 0.0 0 0 ? S 07:14 0:03 [migration/0]
....
root 237 0.0 0.0 0 0 ? S 07:14 0:00 [scsi_eh_0]
root 238 0.0 0.0 0 0 ? S< 07:14 0:00 [scsi_tmf_0]
root 239 0.0 0.0 0 0 ? S 07:14 0:00 [scsi_eh_1]
root 240 0.0 0.0 0 0 ? S< 07:14 0:00 [scsi_tmf_1]
....
root 684 0.0 0.0 16744 2648 ? SNs 07:15 0:00 /usr/sbin/alsactl
-s -n 19 -c -E ALSA_CONF
root 690 0.0 0.0 326396 5472 ? Ssl 07:15 0:00
/usr/sbin/ModemManager
root 697 0.0 0.1 181804 8740 ? Ss 07:15 0:00 /usr/sbin/cupsd
-f
....
coop 24400 2.2 0.6 816720 50876 ? Sl 20:19 0:02
/opt/google/chrome/chrome—type=ppapi—c
coop 24819 0.0 0.3 634244 27952 ? Sl 09:01 0:30
/usr/libexec/gnome-terminal-server
coop 30170 0.0 0.0 116660 4816 pts/2 Ss+ 16:14 0:00 bash
....

donde la opción aux muestra todos los procesos. Los comandos que están encerrados en
paréntesis cuadrados (como [ksoftirqd/0]) son hilos que existen totalmente en el kernel;
si hay uno para cada CPU el comando es seguido por un número entero, especificando la
CPU en la cual está ejecutándose.

LFS201: Fundamentos de Administración de Sistemas Linux 306


23.4 Campos de salida de ps

La mayoría de los campos en el ejemplo anterior se autoexplican. En relación a otros:

 VSZ corresponde al tamaño de la memoria virtual del proceso en KB.

 RSS tamaño de la memoria residente; la memoria física que una tarea está
usando en KB

 STAT describe el estado del proceso; en el ejemplo anterior vemos


solamente S para los procesos que están durmiendo o R para los que están en
ejecución. El carácter adicional en el estado (cuando existe) puede ser:

• < para prioridad alta (lo contrario de nice)


• N para prioridad baja (para nice)
• L indica que tiene páginas bloqueadas en memoria
• s para el líder de la sesión
• l es miltihebra
- + está en el grupo de procesos en primer plano

Si se agrega la opción f se mostrarán los procesos conectados por ascendencia, como se


muestra a continuación:
$ ps auxf
....
coop 23666 0.0 0.0 63880 1180 ? S 11:09 0:00 /bin/sh
/usr/lib64/thunder
coop 23670 0.0 0.0 63880 1220 ? S 11:09 0:00 \_ /bin/sh
/usr/lib64/thu
coop 23675 0.4 2.0 764756 84948 ? Sl 11:09 0:54 \_
/usr/lib64/thunder
.....

LFS201: Fundamentos de Administración de Sistemas Linux 307


23.5 Opción de formato UNIX para ps

Un uso típico con la opción de formato UNIX:

$ ps -elf

F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S root 1 0 0 80 0 - 49596 SYSC_e 07:14 ? 00:00:01
/usr/lib/systemd/systemd—switc
1 S root 2 0 0 80 0 - 0 kthrea 07:14 ? 00:00:00
[kthreadd]
1 S root 3 2 0 80 0 - 0 smpboo 07:14 ? 00:00:03
[ksoftirqd/0]
1 S root 5 2 0 60 -20 - 0 worker 07:14 ? 00:00:00
[kworker/0:0H]
1 S root 7 2 0 80 0 - 0 rcu_gp 07:14 ? 00:00:22
[rcu_preempt]
1 S root 8 2 0 80 0 - 0 rcu_gp 07:14 ? 00:00:00
[rcu_sched]
1 S root 9 2 0 80 0 - 0 rcu_gp 07:14 ? 00:00:00
[rcu_bh]
1 S root 10 2 0 -40 - - 0 smpboo 07:14 ? 00:00:03
[migration/0]
....
1 S root 237 2 0 80 0 - 0 scsi_e 07:14 ? 00:00:00
[scsi_eh_0]
1 S root 238 2 0 60 -20 - 0 rescue 07:14 ? 00:00:00
[scsi_tmf_0]
1 S root 239 2 0 80 0 - 0 scsi_e 07:14 ? 00:00:00
[scsi_eh_1]
1 S root 240 2 0 60 -20 - 0 rescue 07:14 ? 00:00:00
[scsi_tmf_1]
....
0 S root 684 1 0 99 19 - 4186 poll_s 07:15 ? 00:00:00
/usr/sbin/alsactl -s -n 19 -c -E
....
1 S coop 24400 5536 2 80 0 - 204180 futex_ 20:19 ? 00:00:09
/opt/google/chrome/chrome—type
0 S coop 24819 1 0 80 0 - 158561 poll_s 09:01 ? 00:00:31
/usr/libexec/gnome-terminal-serv
0 S coop 30170 24819 0 80 0 - 29165 n_tty_ 16:14 pts/2 00:00:00 bash
....

Tenga en cuenta que en este caso se muestra el PID del proceso padre (PPID) y el factor
de nice (NI). En este ejemplo (tomado en RHEL 7, usando systemd) es posible observar
que muchos procesos muestran PPID=2, el cual es un proceso interno del
kernel, kthreadd, el cual está diseñado para adoptar hijos cuando el proceso padre
muere. En sistemas con versiones antiguas del kernel veríamos PPID=1, haciendo
mención a /sbin/init, pero básicamente es la misma idea.

LFS201: Fundamentos de Administración de Sistemas Linux 308


Algunas opciones comunes de selección en el formato UNIX son:

 -A o -e: Selecciona todos los procesos.


 -N: Niega la selección (es decir, indica lo contrario).
 -C: Selecciona por nombre de comando.
 -G: Selecciona por ID real de grupo (también soporta nombres).
 -U: Selecciona por ID real de usuario (también soporta nombres).

23.6 Personalizar la salida de ps

Si se usa la opción -o seguida de una lista de campos identificadores separados por


coma, es posible imprimir una lista personalizada de campos de ps:
 pid: número identificador del proceso.
 uid: número identificador del usuario dueño del proceso.
 cmd: comando con todos los argumentos .
 cputime: tiempo de CPU acumulado.
 pmem: relación de tamaño del conjunto residente a la memoria física de la
máquina, expresada como porcentaje.

A continuación un ejemplo:

$ ps -o pid,uid,command
PID UID COMMAND
7989 500 bash
8228 500 ps -o pid,uid,command

Usted puede consultar la página man de ps para obtener muchas otras opciones de
salida.

23.7 Uso de pstree

pstree provee una descripción visual de la ascendencia del proceso y aplicaciones


multihebra:

$ pstree -aAp 2408


bash,2408
|-emacs,24998 pmonitor.tex
| |-{emacs},25002
| ‘-{emacs},25003
|-evince,18036 LFS201-SLIDES.pdf
| |-{evince},18040
| |-{evince},18046
| ‘-{evince},18047

LFS201: Fundamentos de Administración de Sistemas Linux 309


Consulte la página man de pstree para obtener una explicación completa del resto de las
opciones; en el ejemplo de arriba solo quisimos mostrar información para el pid=2048.
Tenga en cuenta que uno de sus procesos hijos (evince con pid=18036) tiene tres hijos
propios. Otra forma de verlo es la siguiente:

$ ls -l /proc/18036/task
total 0
dr-xr-xr-x 5 coop coop 0 Sep 11 07:15 18036
dr-xr-xr-x 5 coop coop 0 Sep 11 07:15 18040
dr-xr-xr-x 5 coop coop 0 Sep 11 07:15 18046
dr-xr-xr-x 5 coop coop 0 Sep 11 07:15 18047

23.8 Visualizar la carga del sistema con top

Cuando se desea saber qué está haciendo el sistema operativo, la primera herramienta
que se suele usar es top. Si se ejecuta sin argumentos muestra lo siguiente:

$ top

top - 09:27:44 up 2:09, 4 users, load average: 1.05, 0.35, 0.11


Tasks: 270 total, 3 running, 267 sleeping, 0 stopped, 0 zombie
Cpu(s): 4.0%us, 1.7%sy, 0.3%ni, 90.0%id, 4.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4045232k total, 3972700k used, 72532k free, 623928k buffers
Swap: 4642048k total, 0k used, 4642048k free, 2370804k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


4376 root 20 0 430m 72m 10m R 48.9 1.8 8:59.68 Xorg
4561 coop 20 0 60112 1844 752 S 9.8 0.0 0:00.14 make
4603 coop 20 0 315m 18m 8516 R 2.0 0.5 0:16.45 gnome-terminal
5033 root 20 0 61028 2560 648 S 2.0 0.1 0:00.04 make
5098 coop 20 0 12876 1108 712 R 2.0 0.0 0:00.01 top
5202 root 20 0 60176 1712 712 S 2.0 0.0 0:00.01 make
1 root 20 0 10356 632 536 S 0.0 0.0 0:01.78 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.06 migration/0
4 root 20 0 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/0
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root RT 0 0 0 0 S 0.0 0.0 0:00.15 migration/1
7 root 20 0 0 0 0 S 0.0 0.0 0:00.04 ksoftirqd/1
...

top se refresca cada 3 segundos por defecto.

LFS201: Fundamentos de Administración de Sistemas Linux 310


23.9 Opciones de top

top es una herramienta antigua y tiene muchísimas opciones, como también comandos
interactivos que se inician cuando se presionan ciertas teclas. Por ejemplo, si se
presiona 1, cada CPU se muestra por separado. Si se presiona i, solo se muestran los
procesos activos. Haciendo ambas cosas se obtiene lo siguiente:

top - 12:51:50 up 1 day, 5:31, 6 users, load average: 0.09, 0.14, 0.22
Tasks: 288 total, 1 running, 287 sleeping, 0 stopped, 0 zombie
%Cpu0 : 3.4 us, 1.3 sy, 0.0 ni, 94.6 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 3.7 us, 0.7 sy, 0.0 ni, 95.0 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 3.6 us, 1.3 sy, 0.0 ni, 95.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 2.3 us, 1.0 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 8170032 total, 6360684 used, 1809348 free, 46888 buffers
KiB Swap: 4193776 total, 4848 used, 4188928 free. 4292304 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


2036 coop 20 0 1876580 396628 37704 S 8.0 4.9 113:14.62 gnome-
shell
15082 coop 20 0 547140 185968 21444 S 3.0 2.3 13:22.17 skype-bin
1648 root 20 0 254972 68920 27208 S 2.3 0.8 33:11.09 Xorg
2301 coop 20 0 642600 32156 18908 S 1.0 0.4 1:16.76 gnome-
terminal-
18712 root 20 0 0 0 0 S 0.7 0.0 0:00.25
kworker/1:1
2111 coop 20 0 995392 29424 21076 S 0.3 0.4 0:03.13 nautilus
15465 coop 20 0 1032892 191332 105244 S 0.3 2.3 0:10.88 chrome
18973 coop 20 0 123768 3108 2492 R 0.3 0.0 0:00.04 top

Se tiene mucho control sobre cómo se ordenan los procesos y qué campos se despliegan;
hay muchas otras opciones además de las por defecto. Por ejemplo, si se
presiona h o ? se obtiene una lista breve de los comandos interactivos y q se usa para
salir.

Además es posible terminar una tarea presionando k, o cambiar su prioridad (renice)


con r.

Si hace man top obtendrá documentación extensiva acerca de las opciones de


configuración y posibilidades interactivas.

Tenga en cuenta que hay alternativas populares al comando estándar top, algunos de los
cuales proveen interfaces más visuales o información adicional, tales
como htop, ntop y atop. La mayoría de las distribuciones Linux tienen un monitor gráfico
del sistema (como gnome-system-monitor o ksysguard), los cuales tienen una ventana
de despliegue similar a top.

LFS201: Fundamentos de Administración de Sistemas Linux 311


Comprobación de conocimientos 23.1

Comprobación de conocimientos 23.2

23.10 Laboratorio 23.1


Laboratorio 23.1: Procesos
1. Ejecute ps con las opciones -ef. Luego ejecútelo de nuevo pero con las opciones aux. Note las
diferencias en la salida de cada comando.
2. Ejecute ps de tal forma que solo se despliegue el ID de proceso, la prioridad, el valor de nice y
la línea de comandos del proceso.
3. Ejecute bash en la línea de comandos para iniciar una sesión nueva de esa shell. Inicie otra
sesión bash usando el comando nice, pero esta vez dándole a nice un valor de 10.
4. Ejecute ps como en el paso 2 y note las diferencias entre los valores de prioridad y nice.
También tome nota de los ID de proceso de las dos sesiones de bash.
5. Usando renice, cambie el valor de nice de una de las sesiones de bash a 15. Observe
nuevamente el cambio en los valores de prioridad y nice.
6. Ejecute top y vea la salida a medida en que cambia. Presione q para detener el programa.

LFS201: Fundamentos de Administración de Sistemas Linux 312


Solución 23.1
1. $ ps -ef
$ ps aux

2. $ ps -o pid,pri,ni,cmd
PID PRI NI CMD
2389 19 0 bash
22079 19 0 ps -o pid,pri,ni,cmd

(Nota: no debería haber espacios entre los parámetros.)

3. $ bash
$ nice -n 10 bash
$ ps -o pid,pri,ni,cmd
2389 19 0 bash
22115 19 0 bash
22171 9 10 bash
22227 9 10 ps -o pid,pri,ni,cmd

4. $ renice 15 -p 22227
$ ps -o pid,pri,ni,cmd
PID PRI NI CMD
2389 19 0 bash
22115 19 0 bash
22171 4 15 bash
22246 4 15 ps -o pid,pri,ni,cmd

5. $ top

23.10 Laboratorio 23.1


Laboratorio 23.2: Monitoreo del estado de los procesos
1. Use dd para iniciar un proceso que corra en segundo plano, que lea desde /dev/urandom y
escriba a /dev/null.
2. Veri.que el estado del proceso. ¿Cuál debería ser?
3. Traiga el proceso a primer caso usando el comando fg. Luego teclee Ctrl-Z. ¿Qué hace esto?
Mire el estado del proceso nuevamente, ¿cuál es ahora?
4. Ejecute el programa jobs. ¿Qué información le entrega?
5. Lleve la tarea a segundo plano, luego termínela usando kill desde otra ventana.

LFS201: Fundamentos de Administración de Sistemas Linux 313


Solución 23.2
1. $ dd if=/dev/urandom of=/dev/null &
2. $ ps -C dd -o pid,cmd,stat
25899 dd if=/dev/urandom of=/dev/ R
Should be S or R.

3. $ fg
$ ^Z
$ ps -C dd -o pid,cmd,stat
PID CMD STAT
25899 dd if=/dev/urandom of=/dev/ T

¿El estado debería ser T.

4. ejecute el comando jobs. ¿Qué información le entrega?

$ jobs
[1]+ Stopped dd if=/dev/urandom of=/dev/null

5. Lleve la tarea de vuelta al segundo plano, luego termínela usando el comando kill desde otra
ventana.

$ fg
$ kill 25899

LFS201: Fundamentos de Administración de Sistemas Linux 314


Objetivos de aprendizaje (Revisión)

Actualmente usted debería ser capaz de:


 Usar ps para visualizar características y estadísticas asociadas a procesos.
 Identificar diferentes campos de salida de ps y personalizar la salida del comando.
 Usar pstree para obtener una descripción visual de la ascendencia de los
procesos y aplicaciones multihilos.
 Usar top para visualizar la carga del sistema interactivamente.

LFS201: Fundamentos de Administración de Sistemas Linux 315


Capítulo 24. Monitoreo y ajuste de E/S

Existe una fuerte y complicada relación entre E/S y rendimiento del sistema. No es fácil
desentrañar la competencia entre procesos por ancho de banda de E/S para
almacenamiento, uso de CPU, memoria y cuellos de botella de la red.
Dos herramientas que pueden ayudar a identificar y aislar problemas de este tipo
son iostat e iotop. La herramienta ionice puede usarse para ayudar a priorizar la
competición entre procesos.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Usar iostat para monitorear la actividad de dispositivos de E/S del sistema.
 Usar iotop para desplegar una tabla del uso actual de E/S.
 Usar ionice para configurar tanto la clase de planificación de E/S como la
prioridad de un proceso dado.

LFS201: Fundamentos de Administración de Sistemas Linux 316


24.1 Cuellos de botella de disco

Los problemas de rendimiento de discos pueden acoplarse estrechamente a otros


factores, tales como memoria insuficiente o hardware de red y ajustes inadecuados.
Solucionar este tipo de problemas puede ser complejo.

Como regla, un sistema puede considerarse como atascado en E/S cuando la CPU está
esperando de forma ociosa que alguna operación de E/S se complete para poder
continuar. Otra posibilidad es que la red esté esperando a que los búferes se limpien.

Sin embargo, es posible ser engañado. Lo que parece ser memoria insuficiente puede
resultar de E/S muy lenta; si los búferes de memoria que están siendo usados para leer y
escribir se llenan, esto puede indicar que el problema está en la memoria, cuando el
problema real es que los búferes no se están llenando o vaciando lo suficientemente
rápido. De manera similar, las transferencias de red pueden estar esperando por
operaciones de E/S que tienen que completarse, lo cual tiene un efecto negativo en el
rendimiento de red.
Tanto el monitoreo en tiempo real como el seguimiento son herramientas necesarias para
localizar y mitigar cuellos de botella. Sin embargo, problemas extraños o que no son
reproducibles pueden hacer que estas tareas sean difíciles de lograr.

Hay muchas variables relevantes y el ajusta de E/S es complejo. Consideraremos


la planificación de E/S más adelante.

24.2 iostat

iostat es el caballo de batalla básico para monitoreo de actividad de E/S en el sistema.


Puede generar reportes con mucha información, en donde el contenido exacto se controla
a través de opciones.

Si se ejecuta iostat sin argumentos obtenemos lo siguiente:

$ iostat
Linux 3.15.9 (q7) 09/11/2014 _x86_64_
(4 CPU)

avg-cpu: %user %nice %system %iowait c%stealc %idle


3.07 0.05 1.30 0.66
0.00 94.92

Device: tps kB_read/s kB_wrtn/s kB_read


kB_wrtn
sda 12.10 170.52 61.69 2170494 785198
dm-0 5.58 46.32 48.74 589608 620384
dm-2 1.22 4.89 0.00 62208 12
dm-3 0.01 0.06 0.00 728 0
dm-5 0.31 1.24 0.00 15780 12

LFS201: Fundamentos de Administración de Sistemas Linux 317


dm-6 0.05 0.20 0.00 2568 12
dm-7 0.03 0.11 0.00 1436 12
dm-8 0.03 0.13 0.00 1636 12
dm-1 0.00 0.01 0.00 152 0
dm-4 0.01 0.03 0.00 364 0
dm-10 0.01 0.03 0.00 364 0
dm-11 0.33 28.50 0.23 362769 2964
dm-13 0.03 0.10 0.00 1268 12
dm-14 0.03 0.10 0.00 1256 12
dm-15 0.01 0.03 0.00 364 0

Luego de un resumen breve del uso de la CPU, se dan las estadísticas de


E/S: tps (transacciones E/S por segundo; las solicitudes lógicas pueden combinarse con
solicitudes reales), bloques leídos y escritos por unidad de tiempo, en donde los bloques
son generalmente sectores de 512 bytes; y el total de bloques leídos y escritos.

La información está dividida por particiones del disco (y si LVM está siendo usada por
particiones lógicas de dm, device mapper).

24.3 Opciones de iostat

Si se especifica la opción -k, se genera una vista un tanto diferente, la cual muestra los
resultados en KB en vez de bloques:

$ iostat -k
Linux 3.15.9 (q7) 09/11/2014 _x86_64_ (4
CPU)

avg-cpu: %user %nice %system %iowait %steal %idle


3.07 0.05 1.29 0.66 0.00 94.93

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn


sda 12.07 170.00 61.53 2170494 785574
dm-0 5.57 46.18 48.61 589608 620632
dm-2 1.22 4.87 0.00 62208 12
....

Es posible usar la opción -m para obtener los resultados en MB.


Otra opción útil es -N, la cual despliega la información por nombre de dispositivo (o -
d para un formato un poco diferente), como se muestra aquí:

iostat -N

Linux 3.18.0 (q7) 12/12/2014 _x86_64_ (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle


4.13 0.00 7.38 1.91 0.00 86.57
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 20.26 3895.58 554.19 95397215 13571286
VG-local 4.04 18.07 45.38 442484 1111280
VG-src 0.03 0.15 0.00 3660 32
VG-dead 0.02 0.07 0.00 1692 12
VG-virtual 15.37 3718.74 481.88 91066729 11800544

LFS201: Fundamentos de Administración de Sistemas Linux 318


VG-P 0.00 0.00 0.00 76 0
VG-pictures 0.28 27.30 0.23 668476 5700
VG-virtual2 0.01 0.05 0.00 1256 12
VG-w7back 0.00 0.01 0.00 364 0

24.4 Opciones extendidas de iostat

Se puede obtener un informe mucho más detallado si se usa la opción -x (de extendido):

$ iostat -xk

Linux 3.15.9 (q7) 09/11/2014 _x86_64_ (4 CPU)


avg-cpu: %user %nice %system %iowait %steal %idle
3.06 0.05 1.29 0.66 0.00 94.94

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await
w_await svctm %util
sda 1.04 2.61 7.68 4.33 169.34 61.23 38.39 0.16 12.96 10.53
17.27 1.86 2.24
dm-0 0.00 0.00 1.15 4.40 45.92 48.38 34.01 0.03 6.23 7.38
5.92 2.42 1.34

en donde los campos tienen los siguientes significados:

Tabla 24.1: Campos extendidos de iostat

Campo Significado
Device Dispositivo o nombre de la partición
rrqm/s Número de solicitudes de lectura por segundo, encoladas al dispositivo
wrqm/s Número de solicitudes de escritura por segundo, encoladas al dispositivo
r/s Número de solicitudes de lectura por segundo, emitidas al dispositivo
w/s Número de solicitudes de escritura por segundo, emitidas al dispositivo
rkB/s KB por segundo leídos desde el dispositivo
wkB/s KB por segundo escritos al dispositivo
avgrq-sz Tamaño promedio de solicitud en sectores de 512 bytes por segundo
avgqu-sz Longitud promedio de la cola de solicitudes emitidas al dispositivo
Tiempo promedio (en milisegundos) de solicitudes de E/S entre cuando
await se emite una solicitud y cuando se ha completado: tiempo de la cola más
tiempo de servicio
svctm Tiempo promedio de servicio (en milisegundos) para solicitudes de E/S
Porcentaje de tiempo de CPU durante las solicitudes servidas a
%util
dispositivos

Tenga en cuenta que si el porcentaje de u/lización se aproxima a 100, el sistema opera/vo o el de


E/S está saturado.

LFS201: Fundamentos de Administración de Sistemas Linux 319


24.5 iotop

Otra herramienta muy útil es iotop, la cual debe ser ejecutada como root. Esta despliega
una tabla del uso actual de E/S y se actualiza periódicamente, de la misma forma que lo
hace top. Si se ejecuta sin opciones muestra lo siguiente:

$ sudo iotop

Total DISK READ : 132.32 M/s | Total DISK WRITE : 132.79 M/s
Actual DISK READ: 132.32 M/s | Actual DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
9791 be/4 root 132.32 M/s 132.79 M/s 0.00 % 72.48 % cp
/usr/s~.sqfs /tmp
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd
-~rialize 22
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
5 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
2054 be/4 coop 0.00 B/s 0.00 B/s 0.00 % 0.00 % gsd-printer
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_preempt]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
9 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_bh]
10 rt/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
.....

Tenga en cuenta que las entradas be y rt en el campo PRIO se explican en la sección de


ionice, y provienen de best effort (mejor esfuerzo) y real time (tiempo real).

Las opciones disponibles se muestran con:

$ sudo iotop—help

Usage: /usr/sbin/iotop [OPTIONS]

DISK READ and DISK WRITE are the block I/O bandwidth used during the
sampling
period. SWAPIN and IO are the percentages of time the thread spent
respectively
while swapping in and waiting on I/O more generally. PRIO is the I/O
priority at
which the thread is running (set using the ionice command).

Controls: left and right arrows to change the sorting column, r to invert
the
sorting order, o to toggle the—only option, p to toggle the—processes
option, a to toggle the—accumulated option, i to change I/O priority, q
to
quit, any other key to force a refresh.

Options:
--version show program’s version number and exit
-h, --help show this help message and exit
-o, --only only show processes or threads actually doing I/O

LFS201: Fundamentos de Administración de Sistemas Linux 320


-b, --batch non-interactive mode
-n NUM, --iter=NUM number of iterations before ending [infinite]
-d SEC, --delay=SEC delay between iterations [1 second]
-p PID, --pid=PID processes/threads to monitor [all]
-u USER, --user=USER users to monitor [all]
-P, --processes only show processes, not all threads
-a, --accumulated show accumulated I/O instead of bandwidth
-k, --kilobytes use kilobytes instead of a human friendly unit
-t, --time add a timestamp on each line (implies—batch)
-q, --quiet suppress some lines of header (implies—batch)

Usar la opción -o puede ser útil para tener una salida más limpia.

24.6 Uso de ionice para ajustar prioridades de E/S

La herramienta ionice le permite ajustar tanto la clase de planificación de E/S y


la prioridad para un proceso dado. Usa la siguiente sintaxis:

$ ionice [-c class] [-n priority] [-p pid ] [COMMAND [ARGS] ]

Si se pasa un pid a través del argumento -p, el resultado aplica al proceso solicitado, de
lo contrario se aplicará al proceso iniciado por COMMAND con los argumentos
correspondientes. Si no se proveen argumentos, ionice provee la clase de planificación y
prioridad del proceso de shell actual, como se muestra aquí:

$ ionice
idle: prio 7

El parámetro -c especifica la clase de planificación de E/S, la cual puede tener los tres
valores que siguen:
Tabla 24.2: Clases de planificación de E/S
Clase de
valor
planificación de de -c Significado
E/S
No tiene acceso a E/S de disco a menos que ningún otro
Idle 1
programa lo haya solicitado por un período definido.
Todos los programas se atienden con el método round-
Best effort 2 robin, de acuerdo a los ajustes de prioridad. Esta es la
configuración por defecto.
Obtiene acceso primero al disco, lo cual puede desplazar
Real Time 3 a otros procesos. La prioridad define el tamaño de la
tajada de tiempo que recibe cada proceso.

Las clases Best Effort y Real Time toman el argumento -n, el cual da la prioridad, la que
puede estar en un rango de 0 a 7, en donde 0 es la prioridad mayor. Un ejemplo:
$ ionice -c 2 -n 3 -p 30078

Nota: ionice funciona solo cuando se usa el planificador de E/S CFQ, el cual se
mencionará en el capítulo siguiente.
LFS201: Fundamentos de Administración de Sistemas Linux 321
Comprobación de conocimientos 24.1

24.7 Laboratorio 24.1


Laboratorio 24.1: bonnie++

bonnie++ es un programa de benchmarking ampliamente disponible que pone a prueba y mide el


rendimiento de discos y sistemas de archivos. Proviene de bonnie, una implementación anterior.
Los resultados pueden leerse desde la terminal o ser direccionados a un archivo, el que puede ser
exportado a formato csv (comma separated value) en caso de ser necesario. Los programas
auxiliares textbYon csv2html y bon.csv2txt pueden usarse para conver/r a formatos de salida
html y texto plano. Le recomendamos leer la página man de bonnie++ antes de usarlo, ya que
/ene bastantes opciones acerca de qué tests realizar y cuan exhaus/vos y estresantes pueden ser.
Una sinopsis rápida se ob/ene con:
$ bonnie++ -help
bonnie++: invalid op/on—’h’
usage:
bonnie++ [-d scratch-dir] [-c concurrency] [-s size(MiB)[:chunk-size(b)]]

[-n number-to-stat[:max-size[:min-size][:num-directories[:chunk-size]]]]
[-m machine-name] [-r ram-size-in-MiB]
[-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use]
[-q] [-f] [-b] [-p processes | -y] [-z seed | -Z random-.le]
[-D]

Version: 1.96
Un test rápido puede obtenerse con un comando como el siguiente:
$ /me sudo bonnie++ -n 0 -u 0 -r 100 -f -b -d /mnt

LFS201: Fundamentos de Administración de Sistemas Linux 322


donde cada parámetro y valor signi.ca:
 -n 0 no realizar las pruebas de creación de archivos.
 -u 0 ejecútelo como root.
 -r 100 .nja que /ene 100 MB de RAM.
 -f saltar las pruebas de carácter de E/S.
 -b hacer fsync después de cada escritura, lo cual fuerza a escribir a disco en vez de al
caché.
 -d /mnt especi.ca el directorio que contendrá temporalmente los archivos creados;
asegúrese que /ene su.ciente espacio disponible, en este caso 300 MB.

Si no suministra una cifra para el tamaño de memoria, el programa averiguará cuánta memoria
/ene el sistema y creará un archivo de prueba de 2 a 3 veces ese tamaño. No haremos eso aquí
debido a que tomaría mucho /empo para probar el programa.
En un sistema RHEL 7:
$ /me sudo bonnie++ -n 0 -u 0 -r 100 -f -b -d /mnt
Using uid:0, gid:0.
Wri/ng intelligently...done
Rewri/ng...done
Reading intelligently...done start ’em...done...done...done...done...done...

Version 1.96 ------Sequen/al Output------ --Sequen/al Input- --Random


Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks—
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
q7 300M 99769 14 106000 12 +++++ +++ 257.3 1
Latency 226us 237us 418us 624ms
1.96,1.96,q7,1,1415992158,300M,,,,99769,14,106000,12,,,+++++,++
+,257.3,1,,,,,,,,,,,,,,,,,,,226us,237us,,418us,624ms,,,,,,

LFS201: Fundamentos de Administración de Sistemas Linux 323


En un sistema Ubuntu 14.04, corriendo una máquina virtual bajo un hipervisor en la misma
máquina Osica:
$ /me sudo bonnie++ -n 0 -u 0 -r 100 -f -b -d /mnt
Using uid:0, gid:0.
Wri/ng intelligently...done
Rewri/ng...done
Reading intelligently...done
start ’em...done...done...done...done...done...

Version 1.97 ------Sequen/al Output------ --Sequen/al Input- --Random


Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks—
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec
%CP
ubuntu 300M 70000 61 43274 31 470061 96 2554 91
Latency 306ms 201ms 9276us 770ms
1.97,1.97,ubuntu,1,1415983257,300M,,,,70000,61,43274,31,,,470061,96,2554,91,,,,,,,,,,,,,,,,,,,306
ms,201ms,,9276us,770ms,,,,,,
Puede apreciar claramente la disminución del rendimiento. Asumiendo que ha guardado las salidas
previas en un archivo llamado bonnie++.out, puede conver/r la salida a html de la siguiente forma:

$ bon_csv2html < bonnie++.out > bonnie++.html

o a texto plano con:

$ bon_csv2txt < bonnie++.out > bonnie++.txt

Luego de leer la documentación, ejecute pruebas más largas y ambiciosas. Intente alguna de las
pruebas que no realizamos. Si su sistema se comporta bien, guarde los resultados para realizar
comparaciones de benchmarking en el futuro, en caso de que su sistema mani.este algún
problema de rendimiento.

LFS201: Fundamentos de Administración de Sistemas Linux 324


24.7 Laboratorio 24.2
Laboratorio 24.2: fs_mark
El programa fs_mark sirve para realizar benchmarking de bajo nivel en sistemas de archivos,
u/lizando operaciones asincrónicas de E/S sobre múl/ples directorios y unidades, las cuales
generan una carga. El programa escrito por Ric Wheeler es bastante an/guo y ha resis/do el paso
del /empo.
Puede descargarse desde h@p://sourceforge.net/projects/fsmark/. Una vez que hay obtenido el
archivo, puede desempaquetarlo y compilarlo de la siguiente forma:

$ tar zxvf fs_mark-3.3.tgz


$ cd fs_mark
$ make

Lea el archivo README para obtener más información, ya que vamos a realizar lo básico. Si la
compilación falla con un error como este:
$ make
....
/usr/bin/ld: cannot .nd -lc
es porque no está instalada la versión está/ca de glibc. En sistemas basados en Red Hat lo puede
hacer como sigue:

$ sudo yum install glibc-sta/c

y en sistemas basados en SUSE con:

$ sudo zypper install glibc-devel-sta/c

En sistemas basados en Debian la biblioteca está/ca está instalada junto a la compar/da, por lo
cual no es necesario instalar algún paquete adicional.
A modo de prueba, vamos a crear 1000 archivos, cada uno de 10 KB, luego de lo cual ejecutaremos
fsync para escribir los cambios al disco. Esto puede hacerse en el directorio /tmp con el comando:

$ fs_mark -d /tmp -n 1000 -s 10240

Mientras esto está ejecutándose, obtenga estadís/cas extendidas en otra terminal con iostat:

$ iostat -x -d /dev/sda 2 20

LFS201: Fundamentos de Administración de Sistemas Linux 325


Las estadís/cas en las que debería .jarse son los números de archivos por segundo reportados por
fs_mark y el porcentaje de /empo de CPU u/lizado por iostat. Si este se aproxima a 100 por
ciento, el sistema de E/S está estresado.
Dependiendo del /po de sistema de archivos que está usando, podría mejorar los resultados
cambiando las opciones de mount. Por ejemplo, para ext3 o ext4 puede probar lo siguiente:

$ mount -o remount,barrier=1 /tmp

para ext4 puede intentar:

$ mount -o remount,journal_async_commit /tmp

Vea cómo cambian los resultados. Tenga en cuenta que estas opciones podrían causar problemas si
usted /ene un corte de energía eléctrica o cualquier otro apagado inesperado; es decir, es
probable que exista una relación inversa entre estabilidad y velocidad. La documentación acerca de
algunas opciones de mount se puede encontrar junto a las fuentes del kernel en
Documenta/on/.lesystems y en la página man de mount

LFS201: Fundamentos de Administración de Sistemas Linux 326


Objetivos de aprendizaje (Revisión)

Actualmente usted debería ser capaz de:


 Usar iostat para monitorear la actividad de dispositivos de E/S del sistema.
 Usar iotop para desplegar una tabla del uso actual de E/S.
 Usar ionice para configurar tanto la clase de planificación de E/Scomo
la prioridad de un proceso dado.

LFS201: Fundamentos de Administración de Sistemas Linux 327


Capítulo 25. Planificación de E/S

El rendimiento del sistema a menudo depende profundamente de optimizar la estrategia


de planificación de E/S. Muchos factores (que compiten frecuentemente) influyen en el
comportamiento; esos incluyen minimizar los tiempos de acceso al hardware, evitando de
esta forma el desgaste del medio de almacenamiento, asegurando la integridad de los
datos, garantizando el acceso oportuno a las aplicaciones que necesitan realizar
operaciones de E/S y priorizando las tareas importantes.

Linux ofrece una variedad de planificadores de E/S a elegir, cada uno de los cuales
tiene parámetros ajustables, como también un número de herramientas para generar
reportes y analizar el rendimiento de E/S.

Objetivos de aprendizaje
Al final de este capítulo usted debería ser capaz de:
 Explicar la importancia de la planificación de E/S y describir los requisitos en
conflicto que deben ser resueltos.
 Delinear y contrastar las opciones disponibles en Linux.
 Comprender cómo funcionan los algoritmos CFQ (Completely FairQueue)
y Deadline.

LFS201: Fundamentos de Administración de Sistemas Linux 328


25.1 Planificación de E/S
El planificador de E/S provee la interfaz entre la capa genérica de bloques y los
controladores de dispositivo físico de bajo nivel. Tanto la VM (memoria virtual) como
el VFS (sistema de archivo virtual) realizan solicitudes de E/S a los dispositivos de bloque;
es trabajo del planificador de E/S el priorizar y ordenar estas solicitudes antes de que
sean enviadas a los dispositivos de bloque.
Cualquier algoritmo planificador de E/S tiene que satisfacer ciertos requerimientos (los
que a veces entran en conflicto):
 Los tiempos de acceso al Hardware deben minimizarse; es decir, las solicitudes
deben ordenarse de acuerdo a la ubicación física en el disco. Esto conduce a un
esquema de ascensor, en donde las solicitudes son insertadas en la cola
pendiente en orden físico.
 Las solicitudes deben mezclarse en tanto se pueda para obtener una región
contigua del mayor tamaño posible, lo cual también minimiza el tiempo de acceso
al disco.
 Las solicitudes deben ser satisfechas con la menor latencia posible; de hecho en
algunos casos el determinismo (en el sentido de los plazos) puede ser importante.
 Las operaciones de escritura generalmente pueden esperar a migrar desde caché
a disco sin que los procesos se estanquen. Sin embargo, las operaciones de
lectura requieren siempre que un proceso espere la finalización antes de seguir
adelante. Favorecer las lecturas sobre las escrituras conduce a mejorar las
operaciones en paralelo y la capacidad de respuesta del sistema.
 Los procesos deben compartir el ancho de banda de E/S de forma justa, o al
menos priorizado de forma consciente; aunque esto signifique cierta
desaceleración del rendimiento global de la capa de E/S, el rendimiento de los
procesos no debería verse muy afectado.

25.2 Alternativas del Planificador de E/S


Debido a que estas demandas pueden ser conflictivas, diversos planificadores de E/S
pueden ser apropiados para diferentes cargas de trabajo; por ejemplo, un servidor grande
de base de datos vs. un sistema de escritorio. Además, el hardware específico podría
ordenar una estrategia diferente. Para proveer flexibilidad, el kernel Linux tiene un
esquema orientado a objetos, en el cual punteros a las diversas funciones necesarias son
proporcionadas en una estructura de datos. Una en particular que puede ser seleccionada
durante el arranque en la línea de comandos del kernel es:
linux ... elevator=[cfq|deadline|noop]
Al menos uno de los algoritmos de planificación de E/S debe estar compilado en el kernel.
Las opciones actuales son:
 Completely Fair Queueing (CFQ)
 Deadline Scheduling
 noop (Un esquema simple)

La opción por defecto es una configuración de la compilación; las distribuciones modernas


eligen CFQ o Deadline.

LFS201: Fundamentos de Administración de Sistemas Linux 329


25.3 Planificador de E/S y dispositivos SSD

La introducción gradual de los dispositivos SSD (discos de estado sólido), los cuales usan
memoria flash para emular discos duros, tienen importantes implicancias para la
planificación de E/S.
Tales dispositivos no requieren de un esquema de ascensor y se benefician de la técnica
conocida como nivelación de desgaste para difundir E/S sobre los dispositivos que
tienen ciclos limitados de escritura/borrado.
Es posible examinar /sys/block/<device>/queue/rotational para ver si el dispositivo
es SSD o no, como se muestra a continuación:

$ cat /sys/block/sda/queue/rotational
1

25.4 Parámetros y cambio del Planificador de E/S en tiempo de ejecución

Cada uno de los planificadores de E/S presentan parámetros que se pueden usar para
ajustar el comportamiento en tiempo de ejecución. Los parámetros se acceden a través
del pseudosistema de archivos montado en /sys.
Adicionalmente, es posible usar diferentes planificadores de E/S para diversos
dispositivos. La elección puede realizarse fácilmente desde la línea de comandos. Por
ejemplo:
$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
$ echo noop > /sys/block/sda/queue/scheduler
$ cat /sys/block/sda/queue/scheduler

[noop] deadline cfq

Los parámetros ajustables pueden variar en relación al planificador de E/S en particular, y


pueden encontrarse bajo:
/sys/block/<device>/queue/iosched

LFS201: Fundamentos de Administración de Sistemas Linux 330


Para un disco que usa CFQ:

$ ls -l /sys/block/sda/queue/iosched
total 0

rw-r—r-- 1 root root 4096 Sep 11 11:15 back_seek_max


rw-r—r-- 1 root root 4096 Sep 11 11:15 back_seek_penalty
rw-r—r-- 1 root root 4096 Sep 11 11:15 fifo_expire_async
rw-r—r-- 1 root root 4096 Sep 11 11:15 fifo_expire_sync
rw-r—r-- 1 root root 4096 Sep 11 11:15 group_idle
rw-r—r-- 1 root root 4096 Sep 11 11:15 low_latency
rw-r—r-- 1 root root 4096 Sep 11 11:15 quantum
rw-r—r-- 1 root root 4096 Sep 11 11:15 slice_async
rw-r—r-- 1 root root 4096 Sep 11 11:15 slice_async_rq
rw-r—r-- 1 root root 4096 Sep 11 11:15 slice_idle
rw-r—r-- 1 root root 4096 Sep 11 11:15 slice_sync
rw-r—r-- 1 root root 4096 Sep 11 11:15 target_latency

Comentaremos algunos de estos parámetros en breve.

25.5 CFQ (Completely fair Queue Scheduler)

El método CFQ (Completely Fair Queue) tiene el objetivo de propagar un ancho de banda
de E/S igual entre todos los procesos.

En teoría, cada proceso tiene su propia cola de E/S, la cual trabaja en conjunto a una cola
de despacho que recibe las solicitudes hacia el dispositivo. En la práctica, el número de
colas es fijo (64) y un proceso hash basado en el ID del proceso se usa para seleccionar
una cola cuando se ingresa una solicitud.

El desencole de las solicitudes se realiza con el mecanismo round robin en todas las
colas, cada una de las cuales funciona en orden FIFO (primero en entrar, primero en
salir). De esa forma se lleva a cabo el trabajo. Para evitar operaciones excesivas de
búsqueda, se selecciona una ronda completa y se pasa a la cola de despacho antes de
que las solicitudes reales de E/S se emitan al dispositivo.

LFS201: Fundamentos de Administración de Sistemas Linux 331


25.6 Parámetros ajustables de CFQ

En los ejemplos de abajo, el parámetro HZ es una cantidad configurada por el kernel, la


que corresponde al número de unidades de tiempo por segundo (jiffies), que el núcleo
usa como una medida gruesa de tiempo. Sin entrar en detalles, permítanos decir que la
unidad de tiempo HZ/2 es 0.5 segundos y 5 * HZ son 5 segundos, etc.
 quantum
Longitud máxima de la cola en una ronda de servicio (valor por defecto = 4).

 queued
Solicitud mínima de asignación por cola (valor por defecto = 8).

 fifo_expire_sync
timeout FIFO para solicitudes de sincronización (valor por defecto = HZ/2).

 fifo_expire_async
timeout FIFO para solicitudes asincrónicas (valor por defecto = 5 * HZ).

 fifo_batch_expire
Velocidad a la cual expira FIFO (valor por defecto = HZ/8).

 back_seek_max
Búsqueda hacia atrás máxima, en KB (valor por defecto = 16K).

 back_seek_penalty
Penalización por una búsqueda hacia atrás (valor por defecto = 2).

25.7 Planificador Deadline

El planificador de E/S Deadline reordena agresivamente solicitudes con los objetivos de


mejorar el rendimiento general y prevenir latencias grandes para solicitudes individuales;
es decir, limita la inanición por falta de recursos.
Con cada solicitud el kernel asocia una fecha límite. Las solicitudes de lectura obtienen
una prioridad más alta que las de escritura.
Se mantienen cinco colas de E/S por separado:
 Se mantienen dos listas ordenadas; una para lectura y otra para escritura,
ordenadas por bloque de inicio.
 Se mantienen dos listas FIFO, de nuevo, una para lectura y otra para escritura.
Estas listas se ordenan por tiempo de ingreso.
 Una quinta cola contiene las solicitudes que van a ser enviadas al controlador de
dispositivo. Esta cola se conoce como la cola de envío.

Exactamente cómo las solicitudes son removidas de las primeras cuatro colas y puestas
en la quinta (cola de envío) es donde entra en juego el arte del algoritmo.

LFS201: Fundamentos de Administración de Sistemas Linux 332


25.8 Parámetros ajustables de Deadline

Aquí están los parámetros ajustables del planificador Deadline:


 read_expire:
En cuánto tiempo (en milisegundos) se garantiza que ocurra una solicitud de
lectura (por defecto = HZ/2 = 500 ).
 write_expire:
En cuánto tiempo (en milisegundos) se garantiza que ocurra una solicitud de
escritura (por defecto = 5 * HZ = 5000 ).
 writes_starved:
A cuántas solicitudes de lectura se debería dar preferencia por sobre las de
escritura (por defecto = 2 ).
 fifo_batch:
Cuántas solicitudes deberían moverse desde la lista ordenada del planificador a la
cola de envío, cuando los plazos han expirado (por defecto = 16).
 front_merges:
Las uniones hacia atrás son más comunes que las hacia adelante, ya que una
solicitud contigua generalmente continúa en el bloque siguiente. Se este
parámetro se configura en 0, se deshabilita la unión hacia adelante, lo cual puede
dar un impulso si usted sabe que no va a ser necesario (por defecto = 1 ).

Comprobación de conocimientos 25.1

Comprobación de conocimientos 25.2

LFS201: Fundamentos de Administración de Sistemas Linux 333


25.9 Laboratorio 25.1
Laboratorio 25.1: Comparación de planicadores de E/S
#!/bin/bash
#/*
# * The code herein is: Copyright the Linux Foundation, 2014
# * Author J. Cooperstein

# *
# * This Copyright is retained for the purpose of protecting free
# * redistribution of source.

# *
# * This code is distributed under Version 2 of the GNU General Public
# * License, which you should have received with the source.
# *
# */

NMAX=8
NMEGS=100
[[ -n $1 ]] && NMAX=$1
[[ -n $2 ]] && NMEGS=$2

echo Doing: $NMAX parallel read/writes on: $NMEGS MB size files


TIMEFORMAT=”%R %U %S”
# simple test of parallel reads
do_read_test(){

for n in $(seq 1 $NMAX) ; do

cat file$n > /dev/null &

done

# wait for previous jobs to finish


wait
}

# simple test of parallel writes


do_write_test(){

for n in $(seq 1 $NMAX) ; do

[[ -f fileout$n ]] && rm -f fileout$n


(cp file1 fileout$n && sync) &

done

# wait for previous jobs to finish


wait

LFS201: Fundamentos de Administración de Sistemas Linux 334


}

# create some files for reading, ok if they are the same


create_input_files(){

[[ -f file1 ]] || dd if=/dev/urandom of=file1 bs=1M count=$NMEGS


for n in $(seq 1 $NMAX) ; do

[[ -f file$n ]] || cp file1 file$n

done

echo -e “\ncreating as needed random input files”


create_input_files

# begin the actual work


# do parallel read test
echo -e “\ndoing timings of parallel reads\n”
echo -e “ REAL USER SYS\n”
for iosched in noop deadline cfq ; do

echo testing IOSCHED = $iosched


echo $iosched > /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/scheduler

# echo -e “\nclearing the memory caches\n”


echo 3 > /proc/sys/vm/drop_caches
time do_read_test
done
##############################################################
# do parallel write test
echo -e “\ndoing timings of parallel writes\n”
echo -e “ REAL USER SYS\n”
for iosched in noop deadline cfq ; do
echo testing IOSCHED = $iosched
echo $iosched > /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/scheduler
time do_write_test

done

LFS201: Fundamentos de Administración de Sistemas Linux 335


Si está tomando la versión autodidacta en línea de este curso, encontrará el código fuente
disponible para su descarga en la pantalla Lab.
Recuerde darle permisos de ejecución con:
$ chmod +x ioscript.sh
Lo que viene a con/nuación es una explicación del funcionamiento del script y de cómo usarlo:
El script realiza lo siguiente:
 Cambiar entre los plani.cadores de E/S disponibles en un disco duro, mientras se hace un
número con.gurable de lecturas y escrituras en paralelo de archivos de tamaño ajustable.
 Pruebas de lectura y escritura en pasos por separado.
 Al llevar a cabo las pruebas de lectura, asegúrese de que está leyendo desde el disco y no
desde las páginas en memoria caché. Puede forzar que el caché se escriba en disco
ejecutando el comando:

$ echo 3 > /proc/sys/vm/drop_caches

antes de realizar el test de lectura. Puede hacer cat a /dev/null para evitar escribir en el
disco.

 Asegúrese de que todas las lecturas están completas antes de obtener información del
/empo tomado; esto puede llevarse a cabo ejecutando el comando wait en una shell.
 Las pruebas de escritura se hacen simplemente copiando un archivo (el cual estará en el
caché luego de la primera lectura) múl/ples veces de forma simultánea. Para asegurarse
que todas las operaciones de escritura se han completado antes de obtener información
del /empo tomado, puede ejecutar el comando sync.

El script proporcionado toma dos argumentos. El primero es el número simuntáneo de lecturas y


escrituras a realizar. El segundo es el tamaño en MB de cada archivo.
Este script debe ejecutarse como root, dado a que ob/ene valores desde los árboles de directorios
/proc y /sys. Compare los resultados obtenidos usando diferentes plani.cadores de E/S.
Para realizar una exploración adicional, podría intentar cambiar algunos de los parámetros
ajustables y ver cómo varían los resultados.

LFS201: Fundamentos de Administración de Sistemas Linux 336


Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Explicar la importancia de la planificación de E/S y describir los requisitos en
conflicto que deben ser resueltos.
 Delinear y contrastar las opciones disponibles en Linux.
 Comprender cómo funcionan los algoritmos CFQ (Completely FairQueue)
y Deadline.

LFS201: Fundamentos de Administración de Sistemas Linux 337


Capítulo 26. Memoria: monitoreo y ajustes

A través del tiempo los sistemas se han vuelto más demandantes de recursos de
memoria, al mismo tiempo que los precios de la RAM han disminuido y el rendimiento ha
mejorado. De todas formas aún sucede que los cuellos de botella en el rendimiento
general del sistema están relacionados a la memoria; las CPUs y el subsistema de E/S
podrían estar esperando que los datos se obtengan o escriban a memoria. Hay muchas
herramientas para monitoreo, depuración y ajuste del comportamiento de un sistema en
relación a su memoria.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Listar las consideraciones primarias y tareas involucradas en la optimización de la
memoria.
Saber cómo usar las entradas en /proc/sys/vm e interpretar/proc/meminfo.
 Usar vmstat para desplegar información de memoria, paginación, E/S, actividad
del procesador y el consumo de memoria de los procesos.
 Comprender cómo el OOM-killer decide cuándo tomar acción y seleccionar qué
procesos deben ser finalizados para liberar memoria.

LFS201: Fundamentos de Administración de Sistemas Linux 338


26.1 Consideraciones al ajustar la memoria

Ajustar el subsistema de memoria puede ser un proceso complejo. Primero que todo hay
que notar que el uso de memoria y el rendimiento de E/S están intrínsicamente
relacionados, ya que en la mayoría de los casos la memoria se usa para poner en caché
el contenido de los archivos en disco.

Por lo tanto, cambiar parámetros de la memoria puede tener grandes efectos en el


rendimiento de E/S. Y cambiar parámetros de E/S puede tener un efecto contrario de igual
tamaño en el subsistema de memoria virtual.

Al ajustar parámetros en /proc/sys/vm, la mejor práctica suele ser modificar una cosa a la
vez y analizar los efectos. Las tareas principales son las siguientes:

 Controlar los parámetros de flujo; es decir, cuántas páginas se permite que


estén sucias (en el área de intercambio) y cuán a menudo se vacían al disco.

 Controlar el comportamiento del área de intercambio; es decir, cuántas páginas


que reflejan contenidos de archivo pueden permanecer en memoria en
comparación a las que necesitan ser escritas a disco debido a que no tienen otra
copia de seguridad.

 Controlar cuánto desborde de memoria se permite, ya que muchos programas no


necesitan la cantidad total de memoria que solicitan, en particular debido a las
técnicas COW (copy on write).

La optimización de memoria a menudo puede ser sutil, y lo que funciona en la situación


de un sistema o carga puede no hacerlo de forma óptima en otras circunstancias.

26.2 Herramientas de monitoreo de memoria

Aquí hay una lista de algunas herramientas básicas importantes para monitorear y
optimizar la memoria en Linux:

Tabla 26.1: Herramientas de monitoreo de memoria

Herramienta Propósito Paquete


free Provee un resumen breve del uso de la memoria procps
Estadísticas detalladas de memoria virtual y bloques de E/S,
vmstat procps
actualizados de forma dinámica
pmap Mapa de memoria de un proceso procps

LFS201: Fundamentos de Administración de Sistemas Linux 339


26.3 /proc/sys/vm

El directorio /proc/sys/vm contiene muchos ajustes para controlar el sistema


de Memoria Virtual. Lo que se encuentra exactamente en este directorio depende en
cierto modo de la versión del kernel. El usuario root puede escribir sobre casi todas las
entradas aquí.
Recuerde que estos valores pueden modificarse ya sea escribiendo directamente en la
entrada o usando la herramienta sysctl. Además, si modifica /etc/sysctl.conf los valores
tendrán efecto en cada arranque.
Tabla 26.2: Entradas en /proc/sys/vm

Entrada Propósito
admin_reserve_kbytes Cantidad de memoria libre reservada para
usuarios con privilegios.
block_dump Habilita depuración de bloques de E/S.
Habilita o deshabilita la compactación de
compact_memory memoria (esencialmente la defragmentación)
cuando está configurada como parte del kernel.
dirty_background_bytes Umbral de memoria sucia que provoca que las
páginas se escriban a disco.
dirty_background_ratio Porcentaje total de páginas con el que el kernel
comenzará a escribir datos sucios al disco.
dirty_bytes La cantidad de memoria sucia que un proceso
necesita para iniciar la escritura por sí solo.
Cuando los datos sucios son los suficientemente
dirty_expire_centisecs antiguos para ser escritos en centésimas de
segundo.
Porcentaje de páginas en el cual un proceso de
dirty_ratio escritura comenzará a escribir datos sucios por sí
solo.
Intervalo en el cual los demonios de reescritura
dirty_writeback_centisecs periódica se despiertan para limpiar. Si se
configura en cero, no hay reescritura periódica
automática.
Echo 1 se usa para liberar el caché de páginas, 2
para los cachés dentry e inodo, 3 para liberar
drop_caches todos. Tenga en cuenta que solo las páginas
limpias en caché se eliminan; primero haga sync
para eliminar las páginas sucias.
extfrag_threshold Controla cuando el kernel debe compactar
memoria.
hugepages_treat_as_movable Se usa para cambiar la forma en la que huge
pages es tratada.
hugetlb_shm_group Configura un ID de grupo que puede usarse para
huge pages System V.
laptop_mode Puede controlar una serie de características para
ahorrar energía en portátiles.
legacy_va_layout Use el diseño antiguo (kernel 2.4) en relación a
cómo se muestran las asignaciones de memoria.
lowmen_reserve_ratio Controla cuánta memoria baja está reservada para

LFS201: Fundamentos de Administración de Sistemas Linux 340


páginas que solo pueden estar ahí; es decir, las
páginas que pueden estar en memoria alta lo
harán. Solo es importante en sistemas de 32 bit
con memoria alta.
Número máximo de áreas de memoria asignada
max_map_count que puede tener un proceso. El valor por defecto
es 64 K.
min_free_kbytes Memoria libre mínima que debe estar reservada
en cada zona.
Cuánto espacio de direcciones puede asignar un
proceso de usuario. Se usa para propósitos de
mmap_min_addr seguridad, para evitar que bugs del tipo
referencias nulas del kernel puedan sobreescribir
las primeras páginas en una aplicación.
nr_hugepages Tamaño mínimo de un pool de hugepage.
Tamaño máximo del pool de
nr_pdflush_hugepages hugepage = nr_hugepages
*nr_overcommit_hugepages
nr_pdflush_threads Número actual de las hebras de pdflush; no se
puede escribir.
oom_dump_tasks Si está habilitado, se genera un archivo de volcado
cuando el oom-killer entra en acción.
Si está configurado, el oom-killer elimina la tarea
oom_kill_allocating_task que generó la situación de sobrememoria, en vez
de tratar de seleccionar el mejor.
Es posible configurar ya
overcommit_kbytes sea overcommit_ratio o esta entrada, pero no
ambas.
Si es 0, el kernel estima cuánta memoria libre
queda cuando se realizan las asignaciones. Si es
overcommit_memory 1, permite todas las asignaciones hasta que la
memoria se agota. Si es 2, evitar cualquier
sobreasignación.
Si overcommit_memory = 2, la asignación de
overcommit_ratio memoria puede alcanzar el área de intercambio
más este porcentaje de RAM.
Número de páginas que pueden ser escritas al
page-cluster área de intercambio de una vez, como una
potencia de dos. El valor por defecto es 3 (lo cual
significa 8 páginas).
panic_on_oom Habilita que el sistema se cuelgue en una
situación de agotamiento de memoria.
percpu_pagelist_fraction Fracción de páginas asignadas para cada cpu en
cada zona de máquinas de CPU con hotplug.
Si se escribe aquí, el sistema escaneará e
scan_unevictable_pages intentará mover páginas para tratar de hacerlas
recuperables.
stat_interval Con qué frecuencia vmstat actualiza las
estadísticas de vm (por defecto en 1 segundo).
swappiness Cuán agresivamente el kernel puede usar la
memoria de intercambio.
Si overcommit_memory está configurado en 2,
user_reserve_kbytes esto configura hasta donde el usuario puede
extraer recursos de memoria.

LFS201: Fundamentos de Administración de Sistemas Linux 341


Cuán agresivamente el kernel podría reclamar
vfs_cache_pressure memoria usada para caché de inodo y dentry. El
valor por defecto es 100; si es 0, nunca se reclama
debido a presión de memoria.

Usted puede encontrar información completa del directorio /proc/sys/vm en las fuentes
del kernel bajo Documentation/sysctl/vm.txt (o en el paquete de documentación del
kernel de su distribución).

26.4 vmstat

vmstat es una herramienta multipropósito que despliega información acerca de la


memoria, paginación, E/S, actividad del procesador y procesos. Tiene muchas opciones.
La forma general del comando es la siguiente:

$ vmstat [options] [delay] [count]

Si delay se provee en segundos, el informe se repite en ese intervalo de tiempo; si no se


provee count, vmstat continuará entregando las estadísticas hasta que el proceso sea
detenido por una señal, tal como Ctl-C.
Si no se proveen otros argumentos, vmstat despliega lo que sigue:

$ vmstat 2 4
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 4521672 375560 1792484 0 0 49 17 363 275 3 1 95 1 0
0 0 0 4521408 375560 1792516 0 0 0 0 490 352 1 1 98 0 0
0 0 0 4521408 375568 1792516 0 0 0 14 436 316 1 0 99 0 0
1 0 0 4521408 375576 1792516 0 0 0 10 452 330 1 0 98 0
0

donde la primera línea muestra los promedios desde el último reinicio, mientras que las
líneas subsiguientes muestran la actividad durante el intervalo especificado.

Los campos que se muestran son:

LFS201: Fundamentos de Administración de Sistemas Linux 342


Tabla 26.3: Campos de vmstat
Campo Subcampo Significado
Processes r Número de procesos en espera para ser ingresados al planificador
Processes b Número de procesos durmiendo
memory swpd Memoria virtual usada (KB)
memory free Memoria libre (ociosa) (KB)
memory buff Memoria usada como búfer (KB)
memory cache Memoria usada como caché (KB)
swap si Memoria de intercambio desde el disco (KB)
swap so Memoria de intercambio hacia el disco (KB)
I/O bi Bloques recibidos desde dispositivos (bloques/seg)
I/O bo Bloques enviados a dispositivos (bloques/seg)
system in Interrupciones/segundos
system cs Cambios de contexto/segundo
CPU us Tiempo de CPU ejecutando código de usuario (porcentaje)
CPU sy Tiempo de CPU ejecutando código del kernel (porcentaje)
CPU id Tiempo ocioso de CPU (porcentaje)
CPU wa Tiempo de espera por E/S (porcentaje)
CPU st Tiempo “robado” desde la máquina virtual (porcentaje)

Si se provee la opción -S m , las estadísticas de memoria se mostrarán en MB en vez de


KB.
Con la opción -a , vmstat despliega información acerca de la memoria activa e inactiva:
$ vmstat -a 2 4
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
r b swpd free inact active si so bi bo in cs us sy id wa st
1 0 0 4448676 1034556 2153152 0 0 49 16 363 274 3 1 95 1 0
0 0 0 4448412 1034556 2153252 0 0 0 0 736 674 2 1 97 0 0
0 0 0 4445908 1034604 2154868 0 0 0 14 2043 2301 5 3 91 0 0
0 0 0 4445560 1034604 2155224 0 0 0 24 1582 1784 5 2 92 0 0

LFS201: Fundamentos de Administración de Sistemas Linux 343


donde las páginas de memoria activa son aquellas que han sido usadas recientemente;
pueden estar limpias (los contenidos en disco están actualizados) o sucias (necesitan
ser actualizadas al disco). Por otro lado, las páginas de memoria inactiva no han sido
usadas recientemente, posiblemente estén limpias y se liberan antes bajo presión de
memoria.

La memoria se puede mover entre las listas de memoria activa e inactiva en tanto hay
cambios, o por otra parte, pueden permanecer en su lugar si se deja mucho tiempo entre
usos.

Para obtener una tabla de estadísticas de memoria y ciertos contadores de eventos use la
opción -s:

$ vmstat -s

8170032 K total memory


3914056 K used memory
2159780 K active memory
1034664 K inactive memory
4255976 K free memory
375984 K buffer memory
1807796 K swap cache
4193776 K total swap
0 K used swap
4193776 K free swap
138381 non-nice user cpu ticks
2408 nice user cpu ticks
58336 system cpu ticks
4126831 idle cpu ticks
31180 IO-wait cpu ticks
0 IRQ cpu ticks
248 softirq cpu ticks
0 stolen cpu ticks
2120046 pages paged in
708910 pages paged out
0 pages swapped in
0 pages swapped out
16047974 interrupts
11926843 CPU context switches
1410434075 boot time
31537 forks

LFS201: Fundamentos de Administración de Sistemas Linux 344


Use la opción -d para obtener una tabla de estadísticas de disco:

$ vmstat -d

disk- ------------reads------------ ------------writes-----------


-----IO------
total merged sectors ms total merged sectors ms cur sec
ram0 0 0 0 0 0 0 0 0 0 0
ram1 0 0 0 0 0 0 0 0 0 0
ram2 0 0 0 0 0 0 0 0 0 0
ram3 0 0 0 0 0 0 0 0 0 0
ram4 0 0 0 0 0 0 0 0 0 0
ram5 0 0 0 0 0 0 0 0 0 0
ram6 0 0 0 0 0 0 0 0 0 0
....
loop0 0 0 0 0 0 0 0 0 0 0
loop1 0 0 0 0 0 0 0 0 0 0
loop2 0 0 0 0 0 0 0 0 0 0
....
sda 98304 13295 4233052 1036054 50011 29441 1422172 915477 0 268
sr0 0 0 0 0 0 0 0 0 0 0
sdb 0 0 0 0 0 0 0 0 0 0
dm-0 14721 0 1175928 108578 50068 0 1126336 313843 0 159
dm-2 15561 0 124416 52057 5 0 24 1184 0 17
dm-3 182 0 1456 7756 0 0 0 0 0 7
dm-5
....

Tabla 26.4: Campos de disco de vmstat

Campo Subcampo Significado


reads total Lecturas en total completadas de forma exitosa
reads merged Lecturas agrupadas (resultando en una E/S)
reads ms Milisegundos gastados en lecturas
writes total Escrituras en tital completadas de forma exitosa
writes merged Escrituras agrupadas (resultando en una I/O)
writes ms Milisegundos gastados en escrituras
I/O cur E/S en progreso
I/O sec segundos gastados en E/S

LFS201: Fundamentos de Administración de Sistemas Linux 345


Si solo desea obtener algunas estadísticas rápidas en una partición, use la opción -p:

$ vmstat -p /dev/sda1 2 4
sda1 reads read sectors writes requested writes
23913 1969794 11412 291672
23913 1969794 11417 291712
23913 1969794 11417 291712
23913 1969794 11419 291736

26.5 /proc/meminfo

Como se mencionó anteriormente, en /proc/meminfo se puede encontrar un resumen


relativamente largo de estadísticas de memoria:

$ cat /proc/meminfo
MemTotal: 8170032 kB
MemFree: 4506996 kB
MemAvailable: 6747268 kB
Buffers: 376744 kB
Cached: 1865956 kB
SwapCached: 0 kB
Active: 2155424 kB
Inactive: 1036312 kB
Active(anon): 951000 kB
Inactive(anon): 49300 kB
Active(file): 1204424 kB
Inactive(file): 987012 kB
Unevictable: 32 kB
Mlocked: 32 kB
SwapTotal: 4193776 kB
SwapFree: 4193776 kB
Dirty: 48 kB
Writeback: 0 kB
AnonPages: 949168 kB
Mapped: 397340 kB
Shmem: 51312 kB
Slab: 336148 kB
SReclaimable: 302240 kB
SUnreclaim: 33908 kB
KernelStack: 8352 kB
PageTables: 29752 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 8278792 kB
Committed_AS: 3790248 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 327116 kB
VmallocChunk: 34359398732 kB
AnonHugePages: 344064 kB
HugePages_Total: 0

LFS201: Fundamentos de Administración de Sistemas Linux 346


HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 1252800 kB
DirectMap2M: 7135232 kB

Vale la pena ir a través de la tabla siguiente y entender las entradas:

Tabla 26.5: Entradas de /proc/meminfo

Significado
Entrada
MemTotal RAM total disponible (memoria física menos la memoria reservada por el
kernel)
MemFree Memoria libre tanto en zonas bajas como altas
Buffers Memoria usada para almacenamiento temporal de bloques de E/S
Cached Memoria de caché de páginas, principalmente para E/S de archivos

SwapCached Memoria que fue sacada del área de intercambio pero que todavía
permanece en el archivo de intercambio
Active Memoria usada recientemente, no va a ser recuperada primero

Inactive Memoria que no ha sido usada recientemente, más elegible para ser
recuperada
Active(anon) Memoria activa para páginas anónimas
Inactive(anon) Memoria inactiva para páginas anónimas
Active(file) Memoria activa para páginas de archivos respaldados
Inactive(file) Memoria inactiva para páginas de archivos respaldados
Unevictable Páginas que no pueden ser sacadas del área de intercambio ni liberadas
Mlocked Páginas que están bloqueadas en memoria
SwapTotal Espacio total de intercambio disponible
SwapFree Espacio de intercambio que no está en uso
Dirty Memoria que necesita ser escrita nuevamente al disco
Writeback Memoria que está siendo escrita activamente de nuevo a disco
AnonPages Páginas respaldadas (que no corresponden a archivos) en caché
Mapped Páginas mapeadas a memoria, tales como bibliotecas
Shmem Páginas usadas para memoria compartida
Slab Memoria usada en slabs
SReclaimable Memoria de caché en slabs que puede ser recuperada
SUnreclaim Memoria de caché en slabs que no puede ser recuperada
KernelStack Memoria usada en el stack del kernel

LFS201: Fundamentos de Administración de Sistemas Linux 347


PageTables Memoria que está siendo usada por estructuras de tabla de página
Bounce Memoria usada para búfers de rebote de dispositivos de bloque

WritebackTmp Memoria usada por sistemas de archivos FUSE para búfers de


reescritura
CommitLimit Memoria total disponible para ser usada, incluyendo overcommit
Committed_AS Memoria total asignada actualmente, tanto si está en uso o no
VmallocTotal Memoria total disponible en el kernel para asignaciones de vmalloc
VmallocUsed Memoria realmente usada por asignaciones vmalloc
VmallocChunk Mayor área contigua posible de vmalloc
HugePages_Total Tamaño total del pool de hugepages
HugePages_Free Hugepages que todavía no se asignan
HugePages_Rsvd Hugepages que han sido reservadas pero que aún no se usan
HugePages_Surp Hugepages que son un excedente, usadas para overcommit
Hugepagesize Tamaño de una hugepage

Tenga en cuenta que las entradas exactas dependerán de la versión específica del kernel
en ejecución.

26.6 OOM Killer

La manera más simple de lidiar con presión de memoria sería permitir las asignaciones de
memoria en tanto hay memoria disponible y luego denegarlas cuando la memoria se ha
agotado.

La segunda forma más simple es usar un área de intercambio en disco para hacer
espacio en memoria; en este caso la memoria disponible total (al menos en teoría) es
la RAM más el tamaño del área de intercambio. La parte compleja de esto es determinar
qué páginas de memoria van a ir al área de intercambio cuando el sistema esté bajo
presión. Bajo este enfoque, una vez que el área de intercambio se llena, las solicitudes
para asignar memoria deben ser denegadas.

Sin embargo, Linux tiene una solución mejor; permite que el sistema realice un
overcommit de memoria, de tal forma que puede conceder solicitudes de memoria que
exceden el tamaño de la RAM más el área de intercambio. Si bien es cierto esto puede
parecer temerario, muchos de los procesos (si no la mayoría) no usan toda la memoria
solicitada.

LFS201: Fundamentos de Administración de Sistemas Linux 348


Un ejemplo sería un programa que asigna un búfer de 1 MB y luego usa solo unas pocas
páginas de memoria. Otro ejemplo es que cada vez que un proceso hijo es creado, recibe
una copia completa del espacio de memoria del padre. Debido a que Linux usa la
técnica COW (copy on write), a menos de que uno de los procesos modifique la memoria,
no se necesita hacer ninguna copia real. Sin embargo el kernel tiene que asumir que sería
necesario realizar esa copia.

Así, el kernel permite el overcommit de memoria, pero solo para páginas dedicadas a
procesos de usuario; las páginas usadas en el kernel no van al área de intercambio y
siempre se asignan al momento de ser solicitadas.
Es posible modificar e incluso desactivar el overcommit ajustando el valor
de /proc/sys/vm/overcommit_memory:

 0: (valor por defecto) Se permite el overcommit, pero se deniegan overcommits


obvios. Se les asigna un poco más de memoria a los usuarios root que a los
normales.

 1: Todas las solicitudes de memoria pueden realizar un overcommit.

 2: Deshabilita el overcommit. Las solicitudes de memoria serán denegadas cuando


el total de memoria requerida alcance el tamaño del área de intercambio más un
porcentaje configurable de la RAM (50 por defecto). Este factor puede modificarse
en /proc/sys/vm/overcommit_ratio.

Si la memoria se agota, Linux invoca el OOM-killer (Out Of Memory) para decidir qué
proceso(s) deben ser terminados para liberar memoria.

No hay una ciencia exacta para esto; el algoritmo debe ser heurístico y no puede
satisfacer a todos. En las mentes de muchos desarrolladores, el propósito del OOM-killer
es permitir un cierre exitoso, en vez de ser parte de las operaciones normales.

Andries Brouwer escribió algo divertido al respecto (http://lwn.net/Articles/104185/):


“Una compañía de aviones descubrió que era más barato volar sus aviones con menos
combustible a bordo. Los aviones serían más livianos y usarían menos combustible, de tal
forma que se ahorraría dinero. Sin embargo, en raras ocasiones la cantidad de
combustible fue insuficiente y el avión se estrelló. El problema fue resuelto por los
ingenieros de la compañía a través del desarrollo del mecanismo especial OOF (out-of-
fuel). En casos de emergencia un pasajero era seleccionado y se expulsaba del avión (el
proceso se repetía cuando era necesario). Se desarrolló una gran teoría al respecto y
muchas publicaciones se dedicaron al problema de elegir adecuadamente la víctima a ser
expulsada. ¿La víctima debería ser elegida al azar? ¿O se debería escoger a la persona
con mayor peso? ¿O el más viejo? ¿Los pasajeros deberían pagar para no ser
expulsados, de tal manera que la víctima sea el más pobre a bordo? Y si en caso de que
se eligiera a la persona con mayor peso, ¿debería haber una excepción en caso de que
fuera el piloto? ¿Los pasajeros de primera clase deberían estar eximidos? Ahora que el
mecanismo OOF existe, podría activarse cada dos por tres y los pasajeros serían
expulsados aún cuando no hubiera ninguna escasez de combustible. Los ingenieros
todavía están estudiando cómo se produce precisamente este mal funcionamiento”.

LFS201: Fundamentos de Administración de Sistemas Linux 349


Para tomar decisiones acerca de quién es sacrificado para mantener vivo el sistema, se
calcula un valor llamado maldad (el cual puede ser leerse desde /proc/[pid]/oom_score)
para cada proceso en el sistema. El orden para matar los procesos se determina por este
valor.

Dos entradas en el mismo directorio pueden usarse para aumentar o disminuir la


probabilidad de exterminio. El valor de oom_adj es el número de bits en los cuales los
puntos se ajustan. Los usuarios normales pueden incrementar el valor solamente; solo un
superusuario puede disminuirlo (un valor negativo de oom_adj). El valor
de oom_adj_scoreajusta directamente el valor del punto. Tenga en cuenta que
ajustar oom_adj es obsoleto actualmente.

Comprobación de conocimientos 26.1

Comprobación de conocimientos 26.2

Comprobación de conocimientos 26.3

Comprobación de conocimientos 26.4

LFS201: Fundamentos de Administración de Sistemas Linux 350


26.7 Laboratorio 26.1
Laboratorio 26.1: Invocando el OOM Killer

Vea qué particiones y archivos de intercambio (swap) están presentes en su sistema en el


archivo /proc/swaps. Deshabilite todas las áreas de intercambio con el comando

$ sudo /sbin/swapoff -a

Asegúrese de habilitar las áreas de intercambio una vez que haya terminado, con

$ sudo/sbin/swapon -a

Ahora vamos a poner el sistema bajo una presión de memoria creciente. Una forma de
hacerlo es con el programa stress que instalamos anteriormente, al ejecutarlo con los
argumentos que se muestran a continuación:

$ stress -m 8 -t 10s

lo cual mantendría ocupados 2 GB por 10 segundos.


Usted debería ver al OOM (Out of Memory) lanzarse en picada a terminar procesos para
mantener vivo al sistema. Puede ver que está sucediendo con dmesg o monitoreando
/var/log/messages, o /var/log/syslog, o a través de alguna interfaz gráfica que exponga lo
que está sucediendo en los registros del sistema.

¿Qué proceso se finaliza primero?

Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Listar las consideraciones primarias y tareas involucradas en la optimización de la
memoria.
Saber cómo usar las entradas en /proc/sys/vm e interpretar/proc/meminfo.
 Usar vmstat para desplegar información de memoria, paginación, E/S, actividad
del procesador y el consumo de memoria de los procesos.
 Comprender cómo el OOM-killer decide cuándo tomar acción y seleccionar qué
procesos deben ser finalizados para liberar memoria.

LFS201: Fundamentos de Administración de Sistemas Linux 351


Capítulo 27. Sistemas de gestión de paquetes
Es necesario introducir orden en la forma en que el software se instala, actualiza y
remueve en los sistemas Linux. Los sistemas de gestión de paquetes proveen una vía
limpia de alcanzar esa meta y puede evitar que los sistemas caigan en un caos, que se
vuelvan viejos o se rompan con el tiempo. Además, proveen un método para verificar que
el software en el sistema no ha sido corrompido, ya sea maliciosamente o por accidente.

Una función esencial de los distribuidores de Linux es desarrollar, mantener los paquetes
y asegurarse que las dependencias son mantenidas apropiadamente con el tiempo.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Explicar por qué se deberían usar los sistemas de gestión de paquetes.
 Comprender el rol tanto de los paquetes binarios como de las fuentes.
 Listar los principales sistemas de gestión de paquetes disponibles.
 Comprender por qué se necesitan dos niveles de herramientas; uno que se ocupa
de los paquetes en sí y otro que se ocupa de las dependencias entre ellos.
 Explicar cómo el crear su propio paquete mejora el control que tiene sobre
exactamente lo que sucede con el software y cómo está instalado.

LFS201: Fundamentos de Administración de Sistemas Linux 352


27.1 Conceptos de empaquetamiento de software

Los sistemas de gestión de paquetes proveen las herramientas que les permiten a los
administradores de sistemas automatizar la instalación, actualización, configuración y
eliminación de paquetes de software, todo ello de una forma conocida, predecible y
consistente. Estos sistemas:
 Reunir y comprimir archivos de software asociado en un solo paquete (archivo), lo
cual puede requerir que uno o más paquetes se instalen primero.
 Permiten que la instalación y eliminación de software sea fácil.
 Puede verificar la integridad del archivo a través de una base de datos interna.
 Puede autenticar el origen de los paquetes.
 Facilita las actualizaciones.
 Agrupa los paquetes por características lógicas.
 Administra las dependencias entre paquetes.

Un paquete puede contener archivos ejecutables, archivos de datos, documentación,


scripts de instalación y archivos de configuración. También se incluyen atributos
de metadatos tales como número de versión, checksums, información del proveedor,
dependencias, descripciones, etc.
Tras la instalación, toda la información se almacena localmente en una base de datos
interna, la cual puede ser consultada de forma conveniente para obtener información del
estado y la versión.

27.2 Razones por las cuales usar paquetes

Los sistemas de gestión de paquetes de software son ampliamente vistos como uno de
los avances más grandes que Linux trajo a los ambientes empresariales de IT. Al llevar
un registro de archivos y metadatos de forma automatizada, predecible y confiable, los
administradores de sistemas pueden usar los sistemas de gestión de paquetes para para
escalar el proceso de instalación a miles de sistemas sin requerir de trabajo manual en
cada sistema por separado. Las características incluyen:

 Automatización: No se necesita realizar instalaciones ni actualizaciones


manuales.

 Escalabilidad: Instalar paquetes en uno o en 10.000 sistemas.

 Repetibilidad y predictibilidad.

 Seguridad y auditoría.

LFS201: Fundamentos de Administración de Sistemas Linux 353


27.3 Tipos de paquetes

Los paquetes vienen en diferentes tipos:


 Los paquetes binarios contienen archivos listos para ser implementados,
incluyendo archivos ejecutables y bibliotecas. Estos son dependientes de la
arquitectura y deben ser compilados para cada tipo de máquina.

 Los paquetes de código fuente se usan para generar paquetes binarios; uno
siempre debería tener la posibilidad de reconstruir un paquete binario (por
ejemplo, usando rpmbuild—rebuild en sistemas basados en RPM) desde el
código fuente. Un paquete de código fuente puede ser usado en múltiples
arquitecturas.

 Los paquetes independientes de la arquitectura contienen archivos y scripts que


se ejecutan bajo intérpretes de script, como también documentación y archivos de
configuración.

 Los metapaquetes son esencialmente grupos de paquetes asociados que


recopilan todo lo necesario para instalar un subsistema relativamente grande, tal
como un ambiente de escritorio, o una suite de oficina, etc.

Los administradores de sistema tienen que lidiar la mayoría del tiempo con los paquetes
binarios. En sistemas de 64 bits que pueden ejecutar programas de 32 bits, es posible
tener dos paquetes binarios instalados para un programa dado; tal vez uno
con x86_64 o amd64 en el nombre y otro con i386 o i686.
Los paquetes de código fuente pueden ser útiles para mantener el seguimiento de los
cambios y el código usado que viene en los paquetes binarios. Generalmente no están
instalados por defecto en un sistema pero siempre pueden ser obtenidos desde el
proveedor de la distribución.

27.4 Sistemas disponibles para gestión de paquetes

Hay dos tipos muy comunes de sistemas de gestión de paquetes:


1. RPM (Red Hat Package Manager)
Este sistema es usado por todas las distribuciones derivadas de Red Hat, tales
como Red Hat Enterprise Linux,CentOS, Scientific Linux y CentOS. También
por SUSE y la comunidad relacionada a la distribución openSUSE.

2. dpkg (Debian Package)


Este sistema es usado por Debian y todas las distribuciones derivadas,
incluyendo Ubuntu y Linux Mint.

Hay otros sistemas de gestión de paquetes: portage/emerge, usados


por Gentoo, pacman, usado por Arch y los especializados, los cuales son utilizados por
sistemas de Linux embebido y Android.

LFS201: Fundamentos de Administración de Sistemas Linux 354


LFS201: Fundamentos de Administración de Sistemas Linux 355
Un sistema antiguo es simplemente proveer los paquetes como archivos tar comprimidos,
sin ninguna gestión real o estrategia de eliminación limpia del paquete; este enfoque es
usada todavía por Slackware, una de las distribuciones más antiguas de Linux.
Pero la mayoría de las veces se usa RPM o dpkg, por lo cual esas serán los únicos
sistemas que consideraremos en este curso.

27.5 Niveles de empaquetamiento y variedad de herramientas

Hay dos niveles de sistemas de empaquetamiento:


1. Herramienta de bajo nivel: esto simplemente instala o elimina un paquete único o
una lista de paquetes en donde cada uno tiene su nombre de forma individual y
específica. Las dependencias no están completamente gestionadas, solo se
generan advertencias acerca de:
- Si otro paquete necesita ser instalado primero, la instalación fallará.
- Si el paquete es una dependencia de otro, su eliminación fallará.

2. Las herramientas rpm y dpkg realizan este rol en los sistemas de


empaquetamiento que los usan.

3. Herramienta de alto nivel. Esta resuelve los problemas de dependencias:


- Si otro paquete o grupo de paquetes necesita ser instalado antes de que el
software pueda serlo, tales necesidades serán satisfechas.
- Si la eliminación de un paquete interfiere con otro que ya está instalado, el
administrador podrá elegir si abortar la operación o remover todo el software
afectado.
Las herramientas yum y zypper (y más recientemente PackageKit) se hacen
cargo de la resolución de dependencias para sistemas con rpm. Por otro lado, apt-
get, apt-cache y otras herramientas se hacen cargo en sistemas con dpkg.

En este curso discutiremos solamente las interfaces de línea de comandos a los sistemas
de gestión de paquetes. Si bien es cierto que las interfaces gráficas usadas por cada
distribución Linux pueden ser útiles, nos gustaría estar menos atado a solo una de ellas y
también tener más flexibilidad.

27.6 Fuentes de paquetes

Cada distribución tiene uno o más repositorios de paquetes desde donde las
herramientas del sistema obtienen software y las actualizaciones de versiones nuevas. Es
trabajo de la distribución asegurarse que todos los paquetes en los repositorios
interactúan bien unos con otros.
Hay otros repositorios, externos, que pueden agregarse a la lista estándar que soporta la
distribución. A veces están estrechamente asociadas a la distribución y raramente
generan problemas importantes; un ejemplo puede ser EPEL(Extra Packages
for Enterprise Linux), un conjunto de repositorios dependientes de la versión de la
distribución, los cuales encajan bien con RHEL ya que su fuente Fedora y los
mantenedores de ésta son cercanos a Red Hat.

LFS201: Fundamentos de Administración de Sistemas Linux 356


Sin embargo, algunos repositorios externos no están muy bien construidos o mantenidos.
Por ejemplo, cuando un paquete se actualiza en el repositorio principal, las dependencias
podrían no estar actualizadas en el repositorio externo, el cual podría conducir a
una dependencia infernal de paquetes.

27.7 Creación de paquetes de software

Construir paquetes de software personalizado facilita distribuir e instalar su propio


software. Casi todas las versiones de Linux tienen algún mecanismo para realizarlo.
Construir su propio paquete le permite controlar exactamente qué va en el software y
cómo se instala. Puede crear el paquete de tal forma que cuando se instale, ejecute
scripts para realizar todas las tareas necesarias a fin de instalar el nuevo software y/o
eliminar el antiguo. Tales tareas incluyen:
 Creación de los enlaces simbólicos necesarios.
 Creación de directorios según sea necesario.
 Configuración de permisos.
 Cualquier cosa que pueda incluirse en un script y que cumpla una tarea específica.

No vamos a discutir los mecanismos acerca de cómo construir paquetes .rpm o .deb, ya
que ese es un asunto que atañe más a desarrolladores de software que a
administradores.

Comprobación de conocimientos 27.1

Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Explicar por qué se deberían usar los sistemas de gestión de paquetes.
 Comprender el rol tanto de los paquetes binarios como de las fuentes.
 Listar los principales sistemas de gestión de paquetes disponibles.
 Comprender por qué se necesitan dos niveles de herramientas; uno que se ocupa
de los paquetes en sí y otro que se ocupa de las dependencias entre ellos.

LFS201: Fundamentos de Administración de Sistemas Linux 357


 Explicar cómo el crear su propio paquete mejora el control que tiene sobre
exactamente lo que sucede con el software y cómo está instalado.

LFS201: Fundamentos de Administración de Sistemas Linux 358


Capítulo 28. RPM
El Red Hat Package Manager (RPM) es usado por una serie de las distribuciones
principales (y sus derivadas) para controlar la instalación, verificación, actualización y
eliminación de software en sistemas Linux. El programa de bajo nivel rpm puede realizar
todas esas operaciones, ya sea en un solo paquete o en una lista de ellos. Las
operaciones que podrían causar problemas no se pueden completar con rpm, tales como
remover un paquete del cual depende otro, o instalar un paquete sin haber satisfecho las
dependencias primero.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Comprender cómo está organizado el sistema RPM y conocer las operaciones
más importantes que el programa rpm puede realizar.
 Explicar las convenciones de nombre usadas tanto para los archivos rpm binarios
y de código fuente.
 Saber cómo consultar, verificar, instalar, desinstalar y actualizar paquetes.
 Comprender por qué los kernels nuevos deberían ser instalados en vez de
actualizados.
 Saber cómo usar rpm2cpio para copiar archivos empaquetados en un
archivo cpio, como también extraer los archivos sin instalarlos.

LFS201: Fundamentos de Administración de Sistemas Linux 359


28.1 RPM

RPM (Redhat Package Manager) fue desarrollado por Red Hat (como era de esperar).
Todos los archivos relacionados a una tarea específica están empaquetados en un
archivo rpm único, el cual también contiene información acerca de cómo y donde
instalar/desinstalar los archivos. Las versiones nuevas de software conducen a
archivos rpm nuevos, los que se usan para la actualización.

Los archivos rpm también contienen información acerca de las dependencias. Tenga en
cuenta que a menos que se especifique una URL para obtener los paquetes, rpm no irá a
buscar los paquetes a internet, sino que más bien los instalará desde la máquina local
solamente, usando rutas absolutas o relativas para tal efecto.

Los archivos rpm generalmente dependen de la distribución; de hecho instalar un paquete


en una distribución diferente para la cual fue creado podría ser difícil o imposible.

28.2 Ventajas en el uso de RPM

RPM le facilita las siguientes tareas a los administradores de sistemas:

 Determinar a qué paquete pertenece un archivo en el sistema (si es el caso).

 Determinar qué versión está instalada.

 Instalar y desinstalar paquetes sin dejar residuos o cabos sueltos.

 Verificar que un paquete se instaló correctamente; esto es útil tanto para


solucionar problemas como para la auditoría del sistema.

 Distinguir los archivos de documentación del resto de los archivos del paquete, y
opcionalmente decidir no instalarlos para ahorrar espacio en disco.

 Usar ftp o HTTP para instalar paquetes desde internet.

RPM ofrece ventajas para los desarrolladores también:


 El software a menudo está disponible en más de un sistema operativo. Con RPM,
la fuente original (sin modificar) se usa como base, pero un desarrollador puede
incluir información para construirlo (compilarlo) en Linux.

 Usando un solo paquete de código fuente es posible construir un paquete binario


para más de una arquitectura.

LFS201: Fundamentos de Administración de Sistemas Linux 360


28.3 Nombres de archivos de paquetes

Los nombres de los paquetes RPM están basados en campos que representan
información específica, tal como se documenta en el estándar RPM (http://www.rpm.org/).

 El formato de nombre estandarizado para un paquete binario es:

<name>-<version>-<release>.<distro>.<architecture>.rpm
sed-4.2.1-10.el6.x86_64.rpm

 El formato de nombre estandarizado para un paquete de código fuente es:

<name>-<version>-<release>.<distro>.src.rpm
sed-4.2.1-10.el6.src.rpm

Tenga en cuenta que el campo distro a menudo especifica el repositorio del cual
proviene el paquete, dado a que una instalación puede usar varios repositorios de
paquetes como discutiremos en la sección de yum y zypper, herramientas que trabajan
sobre RPM.

28.4 Directorio de la base de datos


/var/lib/rpm es el directorio por defecto en el sistema, el cual contiene los archivos de
la base de datos RPM en la forma de archivos hash de Berkeley DB. Los archivos de la
base de datos no deberían ser modificados manualmente; las actualizaciones deberían
realizarse solamente a través del programa rpm.

Es posible especificar un directorio alternativo para la base de datos con la opción—


dbpath en el programa rpm. Por ejemplo, esto podría ser útil para examinar una base de
datos RPM copiada desde otro sistema.

Usted puede usar la opción—rebuilddb para reconstruir los índices de la base de datos
desde los headers de los paquetes instalados; esto es más bien una reparación y no una
reconstrucción desde cero.

LFS201: Fundamentos de Administración de Sistemas Linux 361


28.5 Programas auxiliares y ajustes modificables

Los programas auxiliares y scripts usados por RPM residen en /usr/lib/rpm. Hay un buen
número; por ejemplo, en un sistema RHEL 7:

$ ls /usr/lib/rpm | wc -l
69

donde wc reporta el número de líneas de la salida.


Es posible crear un archivo rpmrc para especificar los ajustes por defecto para rpm. Por
defecto, rpm revisa los siguientes archivos, en el orden tal como se muestra a
continuación:
 /usr/lib/rpm/rpmrc

 /etc/rpmrc

 ~/.rpmrc

Tenga en cuenta que se leen todos esos archivo; rpm no se detiene tan pronto encuentra
uno de esos archivos. Puede especificarse un archivo rpmrc alternativo con la opción —
rcfile.

28.6 Consultas

Todas las consultas rpm incluyen la opción -q, la cual puede ser combinada con diversas
subopciones, como las que siguen:
 ¿Qué versión de un paquete está instalada?

$ rpm -q bash

 ¿De qué paquete proviene este archivo?

$ rpm -qf /bin/bash

 ¿Qué archivos instaló este paquete?

$ rpm -ql bash

 Muestra información acerca del paquete

$ rpm -qi bash

 Muestra información acerca del paquete desde el archivo del paquete en sí, no
desde la base de datos.

$ rpm -qip foo-1.0.0.1.noarch.rpm

LFS201: Fundamentos de Administración de Sistemas Linux 362


 Lista todos los paquetes instalados en el sistema

$ rpm -qa

Un par de opciones útiles son—requires y—whatprovides.


 Entrega una lista de los prerrequisitos de un paquete:

$ rpm -qp—requires foo-1.0.0-1.noarch.rpm

 Muestra qué paquete instalado provee un archivo de requisito en particular:

$ rpm -q—whatprovides libc.so.6

28.7 Verificación de paquetes

La opción -V de rpm permite verificar si los archivos de un paquete en particular son


consistentes con la base de datos de RPM del sistema. Para verificar todos los paquetes
instalados en el sistema:
$ rpm –Va
missing /var/run/pluto
....
S.5....T. c /etc/hba.conf
S.5....T. /usr/share/applications/defaults.list
....L.... c /etc/pam.d/fingerprint-auth
....L.... c /etc/pam.d/password-auth
....
.M....... /var/lib/nfs/rpc_pipefs
....
.....UG.. /usr/local/bin
.....UG.. /usr/local/etc

donde la salida anterior muestra solo unos pocos ítems. Tenga en cuenta que este
comando podría tomar bastante tiempo ya que examina todos los archivos asociados a
cada paquete.

Se genera una salida cuando hay un problema solamente.

LFS201: Fundamentos de Administración de Sistemas Linux 363


Cada uno de los caracteres desplegados arriba denota el resultado de una comparación
de atributo(s) del archivo con valor de los atributo(s) almacenados en la base de datos. Un
“.” único (punto) significa que pasó la prueba, mientras que un “?” único (signo de
interrogación al final) indica que la prueba no se pudo realizar (porque por ejemplo los
permisos del archivo no permiten la lectura). De otra forma, el caracter denota una falla de
la prueba en la verificación correspondiente:
 S: el tamaño de archivo difiere
 M: los permisos del archivo y/o tipo difieren
 5: el checksum MD5 difiere
 D: discrepancia entre los números mayor/menor
 L: discrepancia de ruta de enlace simbólico
 U: el usuario propietario difiere
 G: el grupo propietario difiere
 T: el tiempo de modificación difiere
 P: las capacidades difieren

Tenga en cuenta que muchos de estas pruebas de verificación no indican un problema.


Por ejemplo, muchos archivos de configuración se modifican a medida en que el sistema
evoluciona.

Se examinan los nombres de paquete que son pasados como argumento, como en los
ejemplos que siguen a continuación:

 No hay salida cuando todo está bien

$ rpm -V bash
 La salida indica que el tamaño de archivo, checksum y tiempo de modificación han
cambiado:

$ rpm -V talk
S.5....T in.ntalkd.8

 La salida indica que falta un archivo

$ rpm -V talk
missing /usr/bin/talk

LFS201: Fundamentos de Administración de Sistemas Linux 364


28.8 Instalación de paquetes

Instalar un paquete es tan simple como:

$ sudo rpm -ivh foo-1.0.0-1.noarch.rpm

en donde -i es para instalar, -v para tener una salida detallada y -h imprime marcas de
control para mostrar el progreso de la tarea.
RPM realiza varias tareas cuando se instala un paquete:
 Verifica las dependencias:
Es necesario debido a que algunos paquetes no funcionarán correctamente a
menos que uno o más paquetes estén instalados también.
 Realiza comprobaciones de conflictos:
Incluye intentos de instalar un paquete ya instalado o instalar una versión antigua
sobre unas más recientes.
 Ejecuta comandos requeridos antes de la instalación:
El desarrollador que construye un paquete puede especificar ciertas tareas que
deben llevarse a cabo antes o después de la instalación.
 Lidia inteligentemente con los archivos de configuración:
Cuando se instala un archivo de configuración, si el archivo existe y ha sido
modificado desde que se instaló la previa del paquete, RPM guarda la versión
antigua con el sufijo .rpmsave. Esto permite integrar los cambios realizados
anteriormente en el archivo de configuración antiguo en la versión nueva del
archivo. Esta característica depende de que los paquetes RPM hayan sido
creados correctamente.

 Desempaqueta los archivos desde los paquetes y los instala con los atributos
adecuados:
Además de instalar archivos en el lugar correcto, RPM también configura atributos
tales como permisos, dueños y hora de modificación.

 Ejecuta comandos necesarios después de la instalación:


Realiza cualquier tarea de configuración o inicialización necesaria posterior a la
instalación.

 Actualiza la base de datos RPM:


Cada vez que RPM instala un paquete se actualiza información en la base de
datos. RPM usa esta información cuando verifica conflictos.

LFS201: Fundamentos de Administración de Sistemas Linux 365


28.10 Actualización de paquetes

Una actualización reemplaza el paquete original (si es que está instalado), como se
muestra aquí:

$ sudo rpm -Uvh bash-4.2.45-5.el7_0.4.x86_64.rpm

Es posible proveer una lista de paquetes en vez de uno solo.


Al realizar una actualización, el paquete instalado con anterioridad se desinstala luego de
que la versión nueva se instala. La única excepción es el archivo de configuración de la
instalación original, la cual se mantiene con una extensión.rpmsave.

Si usa la opción -U y el paquete no ha sido instalado anteriormente, simplemente se


instalará.

La opción -i no está diseñado para actualizar; si se intenta instalar un


paquete RPM nuevo sobre uno más antiguo, fallará y dará un mensaje de error, ya que
intenta sobreescribir archivos existentes del sistema.

Sin embargo, diferentes versiones del mismo paquete pueden estar instaladas si cada
versión del paquete no contiene los mismos archivos: los paquetes del kernel y de las
bibliotecas de otras arquitecturas son generalmente los únicos que pueden estar
instalados múltiples veces.

Si desea reemplazar la versión actual de un paquete por una anterior (downgrade)


con rpm -U, debe agregar la opción—oldpackage a la línea de comandos.

28.11 Refrescar paquetes

El siguiente comando:
$ sudo rpm -Fvh *.rpm
intentará refrescar todos los paquetes en el directorio actual. La forma en la cual funciona
es la siguiente:

 Si una versión anterior del paquete está instalada, esta será actualizada a la más
nueva que está en el directorio.

 Si la versión en el sistema es la misma que está disponible en el directorio, no se


hace nada.

 Si no se encuentra ninguna versión instalada del paquete, no se realiza la


instalación del mismo.

El refrescar paquetes puede ser útil para aplicar un montón de partes de una vez (para
actualizar paquetes, por ejemplo).

LFS201: Fundamentos de Administración de Sistemas Linux 366


28.12 Actualización de kernel

Cuando se instala un kernel nuevo en el sistema, se requiere un reinicio para que tome
efecto (una de las pocas actualizaciones que lo requieren). No se debería hacer una
actualización (-U) de un kernel: una actualización desinstalaría el kernel que está
actualmente en ejecución.

Esto en sí mismo no va a detener el sistema, pero si después de reiniciar el sistema usted


tiene cualquier problema, no tendrá la oportunidad de reiniciar con el kernel antiguo, ya
que fue desinstalado del sistema. Sin embargo, si usted lo instala ( -i), ambos kernels van
a coexistir y podrá elegir si arrancar con uno u otro; es decir, puede volver al antiguo si lo
necesita.

Para instalar un kernel nuevo haga lo siguiente:

$ sudo rpm -ivh kernel-{version}.{arch}.rpm

reemplace los nombres correctos para la versión y la arquitectura.


Al hacer lo anterior, el archivo de configuración de GRUB será actualizado
automáticamente para incluir la versión nueva; este será la opción de arranque por
defecto, a menos que reconfigure el sistema para que haga otra cosa.

Una vez que la versión nueva del kernel ha sido probada, usted puede desinstalar la
versión antigua si lo desea, aunque no es necesario. A menos que tenga poco espacio en
disco, es recomendable que mantenga una o más versiones anteriores del kernel.

28.13 uso de rpm2cpio

Supongamos que necesita extraer archivos desde un rpm pero no desea instalar el
paquete.

El programa rpm2cpio puede usarse para copiar archivos desde un rpm a un


archivo cpio, como también extraer los archivos si se desea.
Cree el archivo cpio con el siguiente comando:

$ rpm2cpio foobar.rpm > foobar.cpio

Para listar los archivos en un rpm:

$ rpm2cpio foobar.rpm | cpio -t

pero una forma mejor de hacerlo es ésta:

$ rpm -qilp foobar.rpm

Para extraerlo en el sistema:

$ rpm2cpio bash-4.2.45-5.el7_0.4.x86_64.rpm | cpio -ivd bin/bash


$ rpm2cpio foobar.rpm | cpio—extract—make-directories

LFS201: Fundamentos de Administración de Sistemas Linux 367


Comprobación de conocimiento 28.1

Comprobación de conocimiento 28.2

28.14 Laboratorio 28.1


Laboratorio 28.1: Uso de RPM
Vamos a hacer algunas operaciones simples de consulta y veri.cación de paquetes rpm. Este
laboratorio funcionará igualmente bien tanto en sistemas basados en Red Hat como SUSE.
1. Encuentre a qué paquete pertenece el archivo /etc/logrotate.conf
2. Liste la información acerca del paquete, incluyendo todos los archivos que con/ene.
3. Veri.que la instalación del paquete.
4. Intente desinstalar el paquete.

LFS201: Fundamentos de Administración de Sistemas Linux 368


Solución 28.1
1. $ rpm -qf /etc/logrotate.conf
logrotate-3.8.6-4.el7.x86_64

2. $ rpm -qil logrotate


...
Lo mismo podría hacerse de una forma más elegante, que combina estos dos pasos:
3. $ rpm -qil $(rpm -qf /etc/logrotate.conf)
rpm -V logrotate
..?...... /etc/cron.daily/logrotate
S.5....T. c /etc/logrotate.conf

4. En RHEL 7:
$ sudo rpm -e logrotrate
error: Failed dependencies:

logrotate is needed by (installed) vsNpd-3.0.2-9.el7.x86_64

logrotate >= 3.5.2 is needed by (installed) rsyslog-7.4.7-7.el7_0.x86_64

En openSUSE 13.1:
$ sudo rpm -e logrotate
error: Failed dependencies:
logrotate is needed by (installed) xdm-1.1.10-24.2.1.x86_64
logrotate is needed by (installed) syslog-service-2.0-772.1.2.noarch
logrotate is needed by (installed) wpa_supplicant-2.0-3.4.1.x86_64
logrotate is needed by (installed) mcelog-1.0pre3.6e4e2a000124-19.4.1.x86_64
logrotate is needed by (installed) apache2-2.4.6-6.27.1.x86_64
logrotate is needed by (installed) net-snmp-5.7.2-9.8.1.x86_64
logrotate is needed by (installed) kdm-4.11.12-119.1.x86_64

Tenga en cuenta que el árbol exacto de dependencias de paquetes está en función tanto de la
distribución como del soNware instalado.

LFS201: Fundamentos de Administración de Sistemas Linux 369


28.14 Laboratorio 28.2
Laboratorio 28.2: Reconstrucción de la base de datos RPM
Existen condiciones bajo las cuales la base de datos RPM almacenada en /var/lib/rpm puede
corromperse. En ese ejercicio construiremos una nueva y veri.caremos su integridad.
Este laboratorio funcionará igualmente bien tanto en sistemas basados en Red Hat como SUSE.
1. Realice una copia de seguridad de /var/lib/rpm ya que el proceso de reconstrucción
sobreescribirá el contenido. Si usted no lo hace y algo sale mal, podría estar en serios
problemas.
2. Reconstruya la base de datos.
3. Compare el contenido nuevo del directorio con la copia de seguridad; no examine el contenido
de los archivos, ya que son datos binarios, sino más bien el número de archivos y los nombres.
4. Obtenga una lista de todos los rpms en el sistema. Sería interesante que tome una lista antes
del proceso de reconstrucción y la compare con la obtenida después del mismo. Si el comando
de consulta funciona, la base de datos nueva debería estar bien.
5. Compare de nuevo los contenidos de los dos directorios. ¿Tienen los mismos archivos ahora?
6. Usted podría borrar la copia de seguridad (de unos 100 MB de tamaño probablemente), pero
podría ser buena idea mantenerla por un /empo mientras se asegura de que el sistema se está
comportando adecuadamente.

Eche un vistazo a h@p://www.rpm.org/wiki/Docs/RpmRecovery para examinar con más detalle los


pasos para veri.car y/o recuperar la integridad de la base de datos.

Solución 28.2
1. $ cd /var/lib
$ sudo cp -a rpm rpm_BACKUP

2. $ sudo rpm—rebuilddb

3. $ ls -l rpm rpm_BACKUP

4. $ rpm -qa | tee /tmp/rpm-qa.output

5. $ ls -l rpm rpm_BACKUP

6. ¡Realice este paso una vez que esté seguro de que el sistema está funcionando
correctamente!

$ sudo rm -rf rpm_BACKUP

LFS201: Fundamentos de Administración de Sistemas Linux 370


Objetivos de aprendizaje (revisión)

Actualmente usted debería ser capaz de:


 Comprender cómo está organizado el sistema RPM y conocer las operaciones
más importantes que el programa rpm puede realizar.
 Explicar las convenciones de nombre usadas tanto para los archivos rpm binarios
y de código fuente.
 Saber cómo consultar, verificar, instalar, desinstalar y actualizar paquetes.
 Comprender por qué los kernels nuevos deberían ser instalados en vez de
actualizados.
 Saber cómo usar rpm2cpio para copiar archivos empaquetados en un
archivo cpio, como también extraer los archivos sin instalarlos.

LFS201: Fundamentos de Administración de Sistemas Linux 371


Capítulo 29. DPKG
El Debian Package Manager (DPKG) es usado por todas las distribuciones basadas
en Debian para controlar la instalación, verificación, actualización y desinstalación de
software en sistemas Linux. El programa de bajo nivel dpkg puede realizar todas esas
operaciones, ya sea en un solo paquete o en una lista de ellos. Las operaciones que
podrían causar problemas (como remover un paquete del cual depende otro, o instalar un
paquete sin haber satisfecho las dependencias primero) no se completan.

Objetivos de aprendizaje

Al final de este capítulo usted debería ser capaz de:


 Discutir el sistema de empaquetamiento DPKG y sus usos.
 Explicar la convención de nombres usadas tanto para archivos deb binarios y de
código fuente.
 Saber cómo lucen los paquetes de código fuente.
 Usar operaciones de consulta y verificación sobre los paquetes.
 Instalar, actualizar y desinstalar paquetes Debian.

LFS201: Fundamentos de Administración de Sistemas Linux 372


29.1 Conceptos básicos de DPKG

DPKG (Debian Package) es el sistema de empaquetamiento usado para instalar,


desinstalar y gestionar paquetes de software en Debian y otras
distribuciones Linux derivadas de ella. De la misma forma que RPM, no está diseñada
para obtener e instalar paquetes directamente en el uso diario, pero sí para instalarlos y
desinstalarlos localmente.

Los archivos de paquete tienen un sufijo .deb y la base de datos de DPKG reside en el
directorio /var/lib/dpkg.

Tal como rpm, el programa dpkg tiene una vista parcial del universo: solamente sabe qué
está instalado en el sistema y cualquier cosa que se provee a través de la línea de
comandos. Pero no sabe nada de los otros paquetes disponibles, si están en otro
directorio en el sistema o en internet. Como tal, fracasará también si una dependencia no
se cumple, o si alguien trata de desinstalar un paquete que otros que están instalados
necesitan.

29.2 Nombres de archivo d