Instalar y Configurar LTSP en Ubuntu

Desktop
https://help.ubuntu.com/community/UbuntuLTSP

https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall

http://doc.ubuntu.com/edubuntu/edubuntu/handbook/C/

http://www.havetheknowhow.com/Configure-the-server/Install-LTSP.html

Instalar LTSP sobre un SO Ubuntu Desktop

Introducción
Vamos a montar el siguiente escenario de red .

Explicación de la red :
Tendremos una subnet interna para los Thin Clients, que conectan a la interfaz Eth0 del
servidor.

La interfaz eth1 del servidor enlaza con la Red Local, con salida a Internet

Para poder pasar paquetes de la eth0 a la eth1, tendremos que activar el IP FORWARDING
(routing interno) en el servidor

Los ThinClients se configuraran a partir del servicio DHCP del servidor, asignandole una IP
interna de la red 192.168.110.0/24.

Después iniciarán sesión remota en el servidor .

En los ThinClient algunas aplicaciones, por ejemplo Firefox, se ejecutarán localmente, saliendo
por tanto con su IP interna. Para ello necesitaremos dos cosas :

- Instalar el Firefox en la imagen del cliente

- Activar el routing en el servidor y configurar por dhcp el gateway de los clientes, que será la IP
del servidor

Lo vamos a montar utilizando máquinas virtuales VMWare Player. Por tanto , la subred de
ThinClients la simularemos asigando la interfaz ETH0 de la VM del servidor y las interfaces de
los clientes al LAN_SEGMENT "LAN_ThinClients"

La interfaz ETH1 de la VM del servidor será tipo BRIDGE, para salir por la tarjeta de red física a
la red local.

Los ThinCLients
Crearemos dos VMs para simular dos Thin Clients.

Crearemos dos configuraciones distintas para los ThinClients. Configuraremos el servidor LTSP
para que asigne una configuración u otra según la MAC del cliente.

Las sesiones de usuario de los ThinClient se validarán contra un servidor de dominio Active
Directory.

El dominio será curso.local

Al iniciar sesión , los clientes tendrán montada automáticamente una carpeta compartida .

Servidor LTSP
Será un servidor LTSP Standalone. Es decir, incluye su servicio DHCP, LDM, NBD server, TFTP,
etc.

Configuraremos la inclusión del servidor en el dominio Active Directory

Crearemos dos chroot ( y sus correspondientes imágenes), para dos tipos de clientes distintos

Vamos ya con la práctica, que constará de distinas fases y pasos !

Preparar la VMs en VMWare Player

* En la VM de los Thin Clients

- Configurar tarjeta de red . Asignarla a un segmento de red. Por ejemplo "LAN-ThinClients"

* En la VM del servidor

- Configurar la primera tarjeta de red . Asignarla al mismo segmento de red anterior. Esta será
por la que accederán los Thin Clients

- Crear una segunda tarjeta de red, de tipo Bridge

Levantamos la VM del servidor , que ya viene instalada con un SO Ubuntu Desktop.

Entramos en el servidor Ubuntu y vamos a configurar los servicios del LTSP

Preparar algunos paquetes opcionales previos

sudo apt-get install gksu
sudo apt-get purge network-manager

El primero es simplemente para poder utilizar gedit como superusuario.

El segundo es para desinstalar el Network Manager, de forma que la gestión de interfaces de

red la haremos nosotros de manera tradicional.

Configuración de red del servidor

Configurar el hostname y domain del servidor

sudo hostname Servidor-LTSP-1
sudo domainname curso.local
sudo vi /etc/hostname
Poner Servidor-LTSP-1

Configuramos las interfaces del servidor :

sudo vim /etc/network/interfaces

Deberá quedar así, adaptando las IPs y MACs que corresponda según nuestra red

# interfaces(5) file used by ifup(8) and ifdown(8)

auto lo
iface lo inet loopback

# The primary network interface

auto eth0
iface eth0 inet static
address 192.168.110.1
netmask 255.255.255.0
network 192.168.110.0
broadcast 192.168.110.255
dns-search curso.local
up iptables-restore < /etc/ltsp/nat

auto eth1
iface eth1 inet static
address 192.168.129.50
netmask 255.255.255.0
network 192.168.129.0
broadcast 192.168.129.255
gateway 192.168.129.1
dns-nameservers IP_DNS_SERVIDOR_WINDOWS_DC IP_DNS_DE_LA_RED
dns-search curso.local

La línea "up iptables-restore < /etc/ltsp/nat" carga la configuración de NAT con ip tables, para
permitir a las aplicaciones locales al ThinClient salir a la red externa. El fichero /etc/ltsp/nat se
genera en el paso de más adelante

Levantar las interfaces

sudo ifdown eth0

sudo ifup eth0

sudo ifdown eth1

sudo ifup eth1
Comprobar la configuración

ip addr list
ip route list

ifconfig
netstat -r

Configurar el IP Forwarding en el servidor y NAT con iptables

Activar routing interno entre las interfaces del servidor

sudo sysctl -w net.ipv4.ip_forward=1

echo 1 > /proc/sys/net/ipv4/ip_forward

Para hacerlo permanente, configurar la opción en el fichero /etc/sysctl.conf

net.ipv4.ip_forward = 1

Activar NAT para permitir a los paquetes de la red interna ThinClient salir a la red exterior

sudo iptables --table nat --append POSTROUTING --jump MASQUERADE --source

192.168.110.0/24

https://help.ubuntu.com/community/UbuntuLTSP/ThinClientHowtoNAT

Para que sea permanente :

sudo sh -c 'iptables-save > /etc/ltsp/nat'

sudo ifdown eth0

sudo ifup eth0

Instalar LTSP
Instalar el paquete de LTSP.
En nuestro caso el paquete es ltsp-server-standalone. Incluye los servicios necesarios (ndb,
dhcp, nfs, tftp)

Si quisieramos configurar aparte estos servicios, especialmente el DHCP y TFTP, entonces

instalaríamos el paquete ltsp-server

sudo apt-get install ltsp-server-standalone

Configurar el servicio DHCP

Para ello editaremos el fichero dhcpd.conf

Al haber instalado el paquete ltsp-server-standalone, lleva su propia configurac ión del DHCP
en

/etc/ltsp/dhcpd.conf

en lugar del paquete standard de Ubuntu

/etc/dhcp/dhcpd.conf

En este caso va a tomar el de /etc/ltsp/dhcpd.conf

sudo vim /etc/ltsp/dhcpd.conf

Quedará de esta manera :

Los valores de IP habrá que adaptarlos a nuestra configuración de red real

authoritative;

subnet 192.168.110.0 netmask 255.255.255.0 {

range 192.168.110.10 192.168.110.20;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.110.255;
option routers 192.168.110.1;
option domain-name "curso.local";
option domain-name-servers 192.168.128.151;
# next-server 192.168.110.1;
# get-lease-hostnames true;
option root-path "/opt/ltsp/i386";
if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/ltsp/i386/pxelinux.0";
} else {
filename "/ltsp/i386/nbi.img";
 }
}

host ThinClient2 {
hardware ethernet A0:0C:29:0D:46:8B;
fixed-address 192.168.110.21;
option host-name "ThinClient2";
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.110.255;
option routers 192.168.110.1;
option domain-name "curso.local";
option domain-name-servers 192.168.128.151;
option root-path "/opt/ltsp/i386-personalizado";
if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/ltsp/i386/pxelinux.0";
}
else{
filename "/ltsp/i386/nbi.img";
}
}

En nuestro caso ,

- uno de los ThinClient tomará el chroot y la imagen de su S.O. por defecto de /opt/ltsp/i386, y
/opt/ltsp/images/i386.img

- pero para el otro ThinClient le crearemos un chroot e imagen personalizados, identificándolo

por su MAC., en /opt/ltsp/i386-personalizado y la imagen /opt/ltsp/images/i386-
personalizado.img

La opción "root-path" indica un grupo de opciones en alguno de los ficheros de configuración

de /etc/nbd-server/conf.d/*.conf , donde se indica qué imagen debe suministrar el servidor
NBD. Lo veremos más adelante.

La opción "filename" indica la ruta (partiendo de /var/lib/tftpboot ) , donde está el bootloader

(pxelinux) , el kernel (vmlinuz con los ficheros adicionales necesarios) que el servicio TFTP
enviará a los ThinClients para el arranque, y el fichero de configuración del cliente "lts.conf"

En nuestro caso, a todos los clientes de 32bits le vamos a enviar el mismo kernel. Las
diferencias de configuración para cada cliente estarán en la imagen de chroot.

Y las configuraciones personalizadas para cada cliente las podemos configurar en el mismo
lts.conf, creando distintos grupos de opciones por MAC. Lo veremos más adelante.

Para el segundo ThinClient, la opción " hardware ethernet" debe indicar la MAC de ese cliente.

- Reiniciar servicio dhcp

sudo service isc-dhcp-server restart

Si se reinicia con "sudo /etc/init.d/isc-dhcp-server restart" , coge por defecto el fichero de

configuración /etc/dhcp/dhcpd.conf, con lo que no estará cogiendo la configuración correcta.

Para evitar problemas podríamos hacer

sudo rm /etc/dhcp/dhcpd.conf
sudo ln -s /etc/ltsp/dhcpd.conf /etc/dhcp/dhcpd.conf

- Actualizar claves ssh de LTSP para que el servidor ssh registre el cambio

sudo ltsp-update-sshkeys

Construir el primer entorno LTSP (chroot) y la imagen para el

cliente
Ahora ya podemos contruir el entorno chroot para los clientes. A partir de ese entorno chroot
se generará la imagen (squashfs) que el servicio NBD-server pondrá disponible a los clientes.

Es el sistema operativo Linux básico que ejecutaran los clientes.

El entorno chroot por defecto se crea en /opt/ltsp

/opt/ltsp/i386 : para clientes 32bits

/opt/ltsp/amd64 : para clientes 64 bits

/opt/ltsp/images : Las imágen comprimida que se enviara al cliente ( para NBD)

Si se utiliza NFS para servir la imagen al cliente, el cliente montará por NFS el chroot
directamente desde la carpeta /opt/lttsp/i386 (o amd64) , que previamente estará exportada
en el servidor.

En nuestro caso utilizamos NBD. El comando ltsp-build-client, después de construir el entorno

chroot, crea una imagen comprimida en "images", que es la que se monta desde el cliente a
través del servicio NBD.

sudo ltsp-build-client --arch i386

Si queremos construir un cliente 64bits, omitiremos la opción "--arch i386"

La construcción tardará un tiempo.

 En este punto se irá al repositorio Ubuntu en Internet, a buscar la imagen desde la que llenar el
repositorio del cliente (chroot)

Le puedo decir que coja la lista de repositorios de paquetes del propio servidor

ltsp-build-client --arch i386 --copy-sourceslist --accept-unsigned-packages

Pero aun así, los paquetes se los descarga de los repositorios de Internet.

Podría hacerlo desde un Mirror local, con la opción --mirror.

Por defecto , los pasos que da son :

- Actualizar sus repositorios de paquetes desde Internet

- Descargar todos los paquetes necesarios ( desde el mirror por defecto. Por defecto los
repositorios Ubuntu en Internet)

- Construir el sistema de ficheros para chroot (S.O. mínimo para el cliente)

- Crear la imagen comprimida

Comprobar los servicios del servidor

Comprobar que todos los servicios necesarios están configurados y activos en el servidor

DHCP, TFTP, NBD

sudo service isc-dhcp-server status

sudo service tftpd-hpa status (tiene que decir el número proceso asignado)
ps -fp $(pgrep nbd-server)

Probar a iniciar la VM del primer ThinClient

Arrancar la VM de un ThinClient

Al arrancar , al no tener S.O. en el disco local , intentará un arranque por red, con PXE.

El DHCP le enviará una IP y los datos para reclamar una imagen de arranque inicial, por TFTP
desde el servidor.

A partir de ahí ya podrá acceder a la imagen chroot (por NBD, o por NFS) , y arrancar el S.O.
básico en el Cliente.

En la configuración de LTSP, lo primero que hará el cliente es iniciar una sesión XDMCP en el
servidor.

Crear nuevo usuarios en el servidor linux LTSP

En el caso de que queramos crear usuarios que se validarán en el propio servidor LTSP.

sudo adduser curso1

Ir respondiendo a las preguntas

Más adelante veremos como implementar la validación de usuarios contra un servidor de

Dominio Active Directory.

Configurar otro chroot con aplicaciones locales

En este caso vamos a configurar otro chroot, para el segundo ThinClient, que permitirá que ese
ThinClient ejecute el Firefox en local.

Para hacer que una aplicación se ejecute automáticamente de forma local en el thinclient, en
lugar de correr directamente en el servidor, tendremos que hacer tres cambios en el chroot:

• Instalar la aplicación que queremos correr localmente en el chroot.

• Colocar los ficheros .desktop de las aplicaciones que vamos a ejecutar de forma local en
el directorio: /opt/ltsp/i386/usr/share/applications/

• Hacer que se sustituyan en el menú del thinclient los accesos directos de las aplicaciones
 del servidor por las aplicaciones que queremos correr de forma local, modificando lo
siguiente en el archivo /opt/ltsp/i386/etc/lts.conf:

LOCAL_APPS_MENU = True
LOCAL_APPS_MENU_ITEMS = iceweasel, google-chrome, firefox

Crear el nuevo chroot

Podríamos crear el nuevo chroot con

sudo ltsp-build-client --arch i386 --chroot i386-personalizado

En nuestro caso, para no terner que volver a descargar todos los paquetes , vamos a copiar el
chroot que ya tenemos

cd /opt/ltsp
sudo cp -rp i386 i386-personalizado

Instalar el Firefox en el nuevo chroot

sudo chroot /opt/ltsp/i386-personalizado
sudo apt-get install firefox
exit

Comprobar que está el fichero .desktop

ls -lt /opt/ltsp/i386-personalizado/usr/share/applications/firefox.desktop

Crear la nueva imagen NBD desde el nuevo chroot

sudo ltsp-update-image i386-personalizado

Este comando nos creará :

- La nueva imagen en /opt/ltsp/images/i386-personalizado.img

- Un nuevo entorno de arranque en : /var/lib/tftpboot/ltsp/i386-personalizado

- Una nueva configuración para NBD en : /etc/nbd-server/conf.d/ltsp_i386-personalizado.conf

Tendremos que ejecutar ltsp-update-sshkeys cuando en el cliente intentemos hacer login y

recibamos un error diciéndonos algo así como que "Este esquipo no está autorizado para
conectarse al servidor".

También habrá que hacerlo cuando, por lo que sea, cambiemos la IP del servidor de terminales.

Cuando tengamos que hacer un ltsp-update-sshkeys, primero ejecutemos un ltsp-update-

sshkeys y seguidamente hagamos un ltsp-update-image. Y no al revés.

Reiniciar servicio nbd

Ver la nueva configuración para NBD

sudo cat /etc/nbd-server/conf.d/ltsp_i386-personalizado.conf

Reiniciar servicio

sudo service nbd-server restart

Configurar el entorno del cliente

Vamos a habilitar el uso de apliaciones locales, solo para el cliente 2, haciendo referencia a su
MAC (también se puede hacer por IP).

Aunque el ltsp-update-image ha creado un nuevo entorno de arranaque en

/var/lib/tftpboot/ltsp/i386-personalizado, como la nueva imagen no ha realizado cambios en el
Kernel, nosotros vamos ha utilizar el mismo entorno de arranque para todos los clientes.

SI en la nueva imagen hemos hecho modificaciones o actualizaciones del Kernel, entonces

debería utilizar su propio entorno de arranque, configurandolo adecuadamente en la opción
"filename" del DHCP.

Para ello, configuraremos el fichero /var/lib/tftpboot/ltsp/i386/lts.conf . Si no existe, lo

creamos.

sudo vi /var/lib/tftpboot/ltsp/i386/lts.conf

lts.conf

[Default]
LOCAL_APPS = False
[A0:0C:29:0D:46:8B]
LOCAL_APPS = True
LOCAL_APPS_MENU = True
LOCAL_APPS_MENU_ITEMS = firefox

Con las dos últimas opciones, en el menú del cliente aparecerá el icono para lanzar el Firefox
local

Si quiero lanzar a mano una aplicación local desde el cliente :

ltsp-localapps xterm

En el cliente, ejecutar el Firefox. Comprobar que se ejecuta en local, no en el servidcor . Desde

el servidor hacer

ps -ef |grep xterm

y comprobar que no aparece el proceso, ya que se está ejecutando en el cliente.

Gracias a la configuración de routing en el servidor (ip_forwarding + NAT) que hemos

configurado anteriormente, el cliente Firefox podrá acceder a Internet

Arrancar el cliente como "Fatclient"

FatClient se refiere a cuando no sólo lanzamos algunas aplicaciones en local, teniendo la sesión
en el servidor, sino cuando toda la sesión gráfica se inicia en local.

Para ello debe haber instalado un entorno Desktop en el cliente local, y añadir en lts.conf

LTSP_FATCLIENT=True

Más configuraciones en lts.conf

Hay muchas más opciones con las que podemos configurar el cliente.

Opciones para activar/desactivar dispositivos locales, aisgnar parámetros de configuración de

red, definir puntos de montaje, arrancar distintos tipos de sesiones (por ejemlo en modo
Kiosko), etc

Ver en el servidor

man lts.conf

https://readme.phys.ethz.ch/documentation/setting_up_an_ltsp_server_for_diskless_clients/

* Ver tipos de sesiçón del Thin Client en

/opt/ltsp/i386/usr/share/ltsp/screen.d

* Probar el modo Kiosk

sudo ltsp-build-client --arch i386 --base /opt/ltsp/kiosko --kiosk

- En /var/lib/tftpboot/ltsp/i386/lts.conf

[SCREEN_07 = kiosk]

Integración con Active Directory

Vamos a preparar el servidor LTSP para que se integre en un dominio Actrive Directory, de
forma que los Clientes puedan validarse con usuarios del dominio AD.

Existen diversas maneras de configurar la integración del servidor en el dominio.

- Configuración manual
- Instalar y configurar módulos PAM
- Configurar /etc/nsswitch.conf
- Configurar Kerberos
- Con Samba (Samba/Kerberos, Winbind)
- Con utilidad específica : Power Broker Identity Services Open Edition

Vamos a utilizar este último método por simplicidad.

Configuración del servidor LTSP

Configurar la resolución DNS

Las máquinas implicadas ( el propio servidor, el AD) deben poder resolverse por nombre. Las
tendríamos que tener en nuestro servidor DNS.
De momento aquí, los vamos a incluir en nuestro /etc/hosts

En /etc/hosts, añadir

192.168.1.200 Ubuntu-Desktop-1 Ubuntu-Desktop-1.curso.local

192.168.1.135 Windows-Server Windows-Server.curso.local
192.168.1.135 curso.local

Añadir el DNS del servidor Windows

En la configuración de los interfaces de red.

De momento lo metemos en resolv.conf

En /etc/resolv.conf
nameserver 192.168.1.WWW
nameserver 192.168.128.151
search curso.local

El primer nameserver es el DNS del servidor Windows AD

Unir el servidor al dominio AD

Instalar Power Broker Identity Services Open Edition
Para Ubuntu , 64 bits. ( Para otras dsitribuciones buscar en
http://download1.beyondtrust.com/Technical-Support/Downloads/PowerBroker-Identity-
Services-Open-Edition/?Pass=True el paquete que corresponda)

sudo wget http://download.beyondtrust.com/PBISO/8.3/pbis-open-

8.3.0.3287.linux.x86_64.deb.sh

sudo chmod +x pbis-open-8.3.0.3287.linux.x86_64.deb.sh

sudo ./pbis-open-8.3.0.3287.linux.x86_64.deb.sh

sudo pam-auth-update –force

El paquete PBIS instala librerías y configuraciones para PAM y NSS. Hay que reiniciar el servidor
para que tome las nuevas librerías

sudo reboot
Por una incompatibilidad, hay que desinstalar el siguiente paquete

sudo apt-get remove avahi-daemon

Unir el servidor al dominio (domainjoin-cli join MYDOMAIN.COM MyJoinAccount)

sudo domainjoin-cli join curso.local Administrador

Contraseña : Curso.00

Activar servicio lwsmd en el arranque

sudo update-rc.d lwsmd enable

Es recomendable reiniciar el servidor para asegurar que las aplicaciones reconocen la nueva
configuración

sudo reboot

Alguna configuración adicional

sudo /opt/pbis/bin/config UserDomainPrefix CURSO
sudo /opt/pbis/bin/config AssumeDefaultDomain true
sudo /opt/pbis/bin/config LoginShellTemplate /bin/bash

### Esta de momento no : sudo /opt/pbis/bin/config RequireMembershipOf

"CURSO\\Users"

Ver toda la configuración

sudo /opt/pbis/bin/config --dump

Comprobar la integración
/opt/pbis/bin/get-dc-name curso.local
/opt/pbis/bin/enum-users
/opt/pbis/bin/enum-groups

Loguearse con usuario del dominio

ls -lt /home
su – curso3
Contraseña : XXXXX.00

ls -lta /home/local/CURSO/curso3

Montar carpetas compartidas del servidor

Windows
Configuración previa

Instalar compatibilidad con fs cifs

sudo apt-get install cifs-utils

Crear punto de montaje

sudo mkdir /media/windows

Montar carpeta remota compartida

Se podría montar permanentemente por el servidor , poniendo el montaje en /etc/fstab , como
cualquier otro montaje permanente en Linux

//WINDOWSSERVER/compartida /media/windows cifs

credentials=/home/ubuntuusername/.smbcredentials,iocharset=utf8,sec=ntlm 0 0

O utilizando el módulo libpam_mount

El módulo pam_mount ( el cual es instalado y puesto dentro de los módulos PAM por
PowerBroker) permite definir volúmenes (carpetas compartidas o unidades) de montaje
automático cuando el usuario inicia sesión.

Instalar libpam-mount:

sudo apt-get install libpam-mount

Editar /etc/security/pam_mount.conf.xml
Este fichero tiene la configuración principal de los volúmenes a montar con pam_mount.

Habilitamos para que podamos tener configuraciones de montaje distintas para cada usuario.
Para ello eliminamos las etiquetas (<!-- y -->) alrededor de la sección <luserconf
name=".pam_mount.conf.xml" />

Además, más adelante al definir el punto de montaje, vamos a necesitar definir las opciones
"user", "cruid" y "sec", por lo que las añadimos a "mntoptions", quedando así :

<mntoptions
allow="user,cruid,sec,nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,all
ow_other" />

Y crearemos el fichero .pam_mount.conf.xml en el HOME del usuario. Si logueamos con un

usuario del Active Directory, se nos creará la carpeta HOME de ese usuario automáticamente
en /home/local/DOMINIO/USUARIO

Por ejemplo, como usuario "curso3" ( el usuario/password que monta esta carpeta remota
debe tener privilegios de acceso a esa carpeta)

su - curso3
gedit ~/.pam_mount.conf.xml

Añadir

<?xml version="1.0" encoding="utf-8" ?>

<pam_mount>
<volume options="sec=krb5,cruid=%(USERUID),user=%(DOMAIN_USER),nodev,nosuid"
user="*" mountpoint="/media/windows" path="compartida" server="WIN-TVA40SA9S2L"
fstype="cifs" />
</pam_mount>

La opción "sec=krb5" es para que la autenticación del montaje se haga por Kerberos , no por
NTLM. Si no ponemos esta opción el montaje fallará , ya que la autenticación contra el
ActiveDirectory por defecto será NTLM, con lo que necesita pasarle el usuario/password. Y al ir
toda la sesión por el tunel SSH, y dado que SSH no acepta que se le paso el password como
parámetro, el Active Directoiry rechazará la autenticación.

Las opciones "cruid" y "user" son para que Kerberos encuentre correctamente el ticket
kerberos correspondiente.

Limitar recursos utilizados por los usuarios

Utilizando características estándar de Linux.

Limitar uso de RAM, CPU, MaxLogins, etc

/etc/security/limits.conf

/etc/security/limits.d

The limits in /etc/security/limits.conf are implemented using ulimit, which are *per process*.
So if you get a 10 MB limit, "ls" will probably run, but OOo and Firefox probably won't.

There's also nothing keeping a user from starting a bunch of processes, each individually under
the limits, but together impacting system performance.

Para un control más flexible habría que trabajarlo con Cgroups

Limitar uso de disco

Con quotas. Habría que montar el /home en un fs independiente, con la opción de quotas.

Y luego definir la cuota de espacio a utilizar por cada usuario en ese fs

Install quota tools using the following command

sudo apt-get install quota quotatool

On Linux, you can setup disk quota using one of the following methods:

•File system base disk quota allocation

•User or group based disk quota allocation

On the user or group based quota, following are three important factors to consider:

•Hard limit – For example, if you specify 2GB as hard limit, user will not be able to create
new files after 2GB

•Soft limit – For example, if you specify 1GB as soft limit, user will get a warning message
“disk quota exceeded”, once they reach 1GB limit. But, they’ll still be able to create new
files until they reach the hard limit

•Grace Period – For example, if you specify 10 days as a grace period, after user reach their
hard limit, they would be allowed additional 10 days to create new files. In that time period,
they should try to get back to the quota limit.
1. Enable quota check on filesystem
First, you should specify which filesystem are allowed for quota check.

Modify the /etc/fstab, and add the keyword usrquota and grpquota to the corresponding
filesystem that you would like to monitor.

The following example indicates that both user and group quota check is enabled on /home
filesystem

# cat /etc/fstab
LABEL=/home /home ext2 defaults,usrquota,grpquota 1 2

Reboot the server after the above change.

2. Initial quota check on Linux filesystem using quotacheck

Once you’ve enabled disk quota check on the filesystem, collect all quota information initially
as shown below.

# quotacheck -avug
quotacheck: Scanning /dev/sda3 [/home] done
quotacheck: Checked 5182 directories and 31566 files
quotacheck: Old file not found.
quotacheck: Old file not found.

In the above command:

•a: Check all quota-enabled filesystem

•v: Verbose mode
•u: Check for user disk quota
•g: Check for group disk quota
The above command will create a aquota file for user and group under the filesystem directory
as shown below.

# ls -l /home/
-rw------- 1 root root 11264 Jun 21 14:49 aquota.user
-rw------- 1 root root 11264 Jun 21 14:49 aquota.group

3. Assign disk quota to a user using edquota command

Use the edquota command as shown below, to edit the quota information for a specific user.

For example, to change the disk quota for user ‘ramesh’, use edquota command, which will
open the soft, hard limit values in an editor as shown below.

# edquota ramesh
Disk quotas for user ramesh (uid 500):
Filesystem blocks soft hard inodes soft
hard
/dev/sda3 1419352 0 0 1686 0
0

Once the edquota command opens the quota settings for the specific user in a editor, you can
set the following limits:

•soft and hard limit for disk quota size for the particular user.
•soft and hard limit for the total number of inodes that are allowed for the particular user.

4. Report the disk quota usage for users and group using repquota
Use the repquota command as shown below to report the disk quota usage for the users and
groups.

# repquota /home
*** Report for user quotas on device /dev/sda3
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 566488 0 0 5401 0 0
nobody -- 1448 0 0 30 0 0
ramesh -- 1419352 0 0 1686 0 0
john -- 26604 0 0 172 0 0

5. Add quotacheck to daily cron job

Add the quotacheck to the daily cron job. Create a quotacheck file as shown below under
the /etc/cron.daily directory, that will run the quotacheck command everyday. This will send the
output of the quotacheck command to root email address.

# cat /etc/cron.daily/quotacheck
quotacheck -avug

Linux Cgroups

The limits imposed by ulimit and limits.conf is per process

If you want to limit the total amount of memory or CPU a user uses you want to use cgroups.
https://en.wikipedia.org/wiki/Cgroups

Introducción a Cgroups : https://access.redhat.com/documentation/en-

US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html

http://frank2.net/cgroups-ubuntu-14-04/

Deps:

sudo apt-get install cgroup-bin cgroup-lite libcgroup1

cgconfigparser is the program that needs to run in order to set up the configuration put in
cgconfig.conf.

This program does not start at startup, but it should (create a init script or place in cgroup-lite config
script, a sample is located in this post)

cgroup-lite service needs to run for cgconfigparser to run correctly. cgroup-lite is responsible for
mounting the cgroups.

sudo service cgroup-lite start

In /etc/cgconfig.conf:

group memlimit {
memory {
memory.limit_in_bytes = 1G;
memory.memsw.limit_in_bytes = 1G;
}
}

This creates a cgroup that has a max memory limit of 1GB y adicional swap of 1GB

In /etc/cgrules.conf:

curso1 memory memlimit/

This will cause all processes run by curso1 to be run inside the memlimit cgroups created in
cgconfig.conf.

cgrulesengd needs to run in order to enforce cgroups policy, it is not started automatically.

Start cgrulesengd with debug log to /tmp/hei.log:

sudo cgrulesengd -d -f /tmp/hei.log &

tail -f /tmp/hei.log

Show information of a process

ps -o cgroup 13820

cat /proc/13820/cgroup

Reglas para el Firewall iptables

Firewall Rule: tftp

-A INPUT -p udp -m state --state NEW -m udp --dport 69 -j
ACCEPT

Code: testing tftpd

netstat -apn|grep ":69 "

Firewall Rule / Services

Code: Allow Remote Logging
iptables-save > /root/iptables.bak
vim /etc/services
vim /root/iptables.bak
iptables-restore /root/iptables.bak
File: /etc/services
syslog 5140/tcp
File: /root/iptables.bak
-A INPUT -p udp -m state --state NEW -m udp --dport syslog -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport syslog -j ACCEPT

Puerto para NBD

10809

Adicionales : 5051 y 5052