Como, por ejemplo, dónde conserva las copias, cómo saber cuáles existen y cómo hacer una copia de ellas a su vez.
Etiqueta: Administración de sistemas
Copias de seguridad con BackupPC (comenzando)
¿ Otra vez cambiando de programa ? Pues sí, otra vez. Y tampoco estoy seguro de que ahora la cosa vaya a mejor.
Auto montaje de unidades bajo Samba
Entrada rápida para no olvidar que se podía hacer y cómo lo hice, que ya nos conocemos.
Han cambiado bastante las cosas en mi lugar de trabajo y ahora tengo a un puñado de máquinas Windows accediendo a un recurso de red para compartir documentos. Este recurso está bajo el control de Samba en un servidor Linux y anteriormente era un montaje vía NFS con equiparación de identificadores de usuario, permisos y grupos.
El acceso era automático empleando autofs que configuraba también de forma automática con un paquete Debian que instalaba en cada máquina.
La única instalación cliente que me queda, al margen de mi equipo para desarrollo, seguía utilizando dicho atajo a la carpeta de red. Pero ahora necesita estar en el mismo sitio que sus compañeros por lo que he tenido que hacer un pequeño cambio en la configuración.
El archivo /etc/auto.docs es el encargado de definir dónde y cómo se accede a estos recursos. Ahora tiene el siguiente aspecto:
#
# Mapa de montaje para documentos
#
#empresa -rw docs.empresa.net:/docs/empresa
empresa -fstype=cifs,rw,guest,uid=nobody,gid=Empresa,file_mode=0665,dir_mode=0775 ://docs.empresa.net/Compartidos
* -rw docs.empresa.net:/docs/&
He dejado la línea anterior que hacía referencia a la versión con NFS. La nueva indica que cuando se acceda a la carpeta /var/docs/empresa se efectúe el montaje vía CIFS con las siguientes opciones:
- Lectura/escritura: rw
- Acceso de invitado sin contraseña: guest
- Forzar el ID de usuario a nobody: uid=
- Forzar el grupo al que pertenecen todos (Empresa). gid=
- Definir los permisos de nuevos ficheros y directorios: file_mode= y dir_mode=.
Es necesario que exista un ejecutable mount.cifs así que es obligado instalar en el cliente el paquete cifs-utils.
Asimilando un router de fibra óptica de Movistar
La instalación de acceso a Internet en mi lugar de trabajo está en manos de Movistar desde hace muchos años. Los técnicos nos trajeron el par de dispositivos para conectar vía fibra óptica años atrás, dejando el ONT a la entrada de la nave principal y tendiendo un cable de red hasta la oficina de informática.
Nombres de impresoras en Debian Buster
En los sistemas de escritorio recién actualizados a Debian 10 (Buster) nos encontramos con detallitos que afectan a la cordura de nuestros homínidos.
Y mira, no, con el calor que hace es lo que les faltaba a los pobres. Y encima quejándose con motivos, ¿ dónde se ha visto eso ?
Cómo usar una Raspberry Pi como servidor de impresión …
… cuando ya lo has probado de varias formas y sólo quieres llorar en un rincón.
Apagando en lugar de reiniciando con Ctrl+Alt+Supr
Pequeño y absurdo detalle que me complica la vida cuando son mis homínidos los que deben apagar servidores.
msat-sb: útiles para backups
Tiempo atrás escribí una entrada explicando cómo hacer que un sistema usase cuentas de sistema espaciales para recibir datos de copias de seguridad.
Desde hace unos meses estoy perfeccionando, a ratos, un pequeño juego de utilidades para ayudarme en la configuración y uso de máquinas como receptores de copias de seguridad de terceros.
Dicho paquete se llama msat-sb y está incluido dentro de un proyecto mayor llamado msat; un acrónimo atrevido y original que viene a decir algo así como: My System Administration Tools y que puede verse en su propio repositorio: https://git.astillas.net/msat.
El paquete msat-sb (sb procede de secure backups) contiene dos scripts: el primero se llama sb-setup y el segundo sb-adduser. El primero nos sirve para retocar la configuración de varios ejecutables y para advertirnos de cómo deberían estar la de otros.
El segundo es un poco más complejo: solicita un nombre completo de usuario o cliente y con él crea un nombre abreviado que emplear para acceder al sistema. También crea los directorios de usuario, ajustando permisos, y se asegura de que existan al menos los imprescindibles para poder trabajar con el sistema.
El mayor escollo lo he encontrado en que el directorio jaula (chroot) que tiene que ser obligatoriamente propiedad de root así que, evitando trucos como los enlaces blandos dado que pretendemos que este mecanismo sea masivo, al final nos tenemos que conformar con que existan zonas específicas para guardar datos.
No queda tan elegante como sftp://usuario@servidor y tendremos que conformarnos con que exista un directorio llamado data donde poder escribir. Esto, por otra parte, es una oportunidad para añadir un directorio public_html para que publique cosas y otro .ssh para guardar claves de conexión.
El árbol entonces queda de la siguiente forma:
root@backups:/srv/backups# tree -puag .
└── [drwxrwxr-x root root ] sb_servidse
├── [drwxrwsr-x sb_servidse sb ] data
├── [drwxrwsr-x sb_servidse sb ] public_html
│ └── [-rw-rw-r-- sb_servidse sb ] README
├── [-rw-rw-r-- sb_servidse sb ] README
├── [drwxrwsr-x sb_servidse sb ] .ssh
│ └── [-rw-rw-r-- sb_servidse sb ] README
└── [-rw-rw---- sb_servidse sb ] .Xauthority
4 directories, 4 files
La configuración de servicios queda como en la entrada antes mencionada; la diferencia es que hay que emplear el programa sb-adduser como administrador para crear las cuentas.
Configuración de servidores
El programa sshd debe contener el siguiente párrafo:
override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server -u 0002
UsePAM yes
Match Group sb
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
Mientras que el programa rssh debe estar de la siguiente forma:
# Registro de eventos
logfacility = LOG_USER
# Ejecutables permitidos
allowscp
allowsftp
allowrsync
# Máscara de creación de archivos
umask = 002
# Y la siguiente línea deshabilitada porque el cambio de
# directorio ya lo realiza sshd
#chrootpath=/chroot
Wifi mediante usb en un equipo de sobremesa
Lo que hay que sufrir para estar guapo.