Hacer persistentes los cambios en ulimit (limits.conf)
Cuando cambiamos algún valor de los disponibles en ulimit, sólo se mantiene en nuestra sesión. Si salimos y volvemos a entrar los perdemos. Esto es útil para cambios temporales pero no cuando queremos que sean persistentes tras el cierre de sesión.
Como ya sabéis la mayoría, el comando ulimit -a nos dice los valores y límites establecidos para nuestro usuario:
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 20 file size (blocks, -f) unlimited pending signals (-i) 16382 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) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Los que más se suelen cambiar son el número de ficheros abiertos de forma simultanea por el usuario, el número de procesos por usuario, ciclos de cpu, etc. Para nuestra sesión, lo solemos hacer directamente en la línea de comandos:
# ulimit -n 1024 # ulimit -n 2048 # ulimit -n 2048
Si salimos de la sesión y entramos de nuevo, el valor volverá a ser 1024. En el caso de Red Hat y derivados, así como Debian debemos especificar estos valores en el fichero /etc/security/limits.conf, así los haremos persistentes.
El propio fichero está perfectamente documentado con comentarios, sino, también tenemos la página man de limits.conf para más información:
$ man limits.conf
# /etc/security/limits.conf # #Each line describes a limit for a user in the form: # ## #Where: # can be: # - an user name # - a group name, with @group syntax # - the wildcard *, for default entry # - the wildcard %, can be also used with %group syntax, # for maxlogin limit # - NOTE: group and wildcard limits are not applied to root. # To apply a limit to the root user, must be # the literal username root. # # can have the two values: # - "soft" for enforcing the soft limits # - "hard" for enforcing hard limits # # - can be one of the following: # - core - limits the core file size (KB) # - data - max data size (KB) # - fsize - maximum filesize (KB) # - memlock - max locked-in-memory address space (KB) # - nofile - max number of open files # - rss - max resident set size (KB) # - stack - max stack size (KB) # - cpu - max CPU time (MIN) # - nproc - max number of processes # - as - address space limit (KB) # - maxlogins - max number of logins for this user # - maxsyslogins - max number of logins on the system # - priority - the priority to run user process with # - locks - max number of file locks the user can hold # - sigpending - max number of pending signals # - msgqueue - max memory used by POSIX message queues (bytes) # - nice - max nice priority allowed to raise to values: [-20, 19] # - rtprio - max realtime priority # - chroot - change root to directory (Debian-specific) # #
# #* soft core 0 #root hard core 100000 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #ftp - chroot /ftp #@student - maxlogins 4
Llevo unos días haciendo pruebas con una maqueta de Red Hat Cluster Suite en CentOS. De momento, voy estudiando los distintos comandos y ficheros de configuración, aunque utilizo luci/ricci para la gestión del cluster vía web.
Vamos a ver como crear un RAID 1 (espejo) por software entre dos discos extra añadidos a un sistema CentOS o RHEL. Este sistema nos ofrece total redundancia de datos a expensas de utilizar el doble de espacio en disco. En caso de disponer una controladora para hacer el RAID por hardware lógicamente es más recomendable que esta opción, ya que el rendimiento es mucho mejor.
Para una primera toma de contacto con 
Kickstart/Anaconda permite realizar instalaciones desatendidas de sistemas CentOS (y por ende Red Hat y derivados) de modo que podamos instalar y configurar todos los equipos que queramos 
Comentarios recientes