Hardware y software

HDA-SERV: Configuración

hda
hda #1 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

← HDA-NAS | ↑ HDA-SERV | HDA-DOCKER →

Buenas de nuevo, queridos mediavidensis,

Allá en febrero del 22 monté un hilo sobre la adquisición de un NAS para backup en casa. En aquel hilo caminé pormenorizadamente por el concepto de NAS, la selección del mismo, el hardware, y los discos duros. Terminaba aquel hilo indicando que sería el primero en una serie de tres: 1) Hardware, 2) Configuración del sistema, y 3) Microservicios. Pues bien, este que tenéis delante es el segundo hilo de la saga, el de la configuración del sistema.

La razón de la existencia de este hilo es que conforme iba instalando todo, también iba documentándolo. Así que mi propósito es adaptar un poco las notas que he ido tomando para compartirlas con vosotros. Seguro que muchos podrán aportar y recomendar diferentes cosas, ¡y agradecido de antemano quedo! He intentado mantener hipervínculos a las fuentes que he ido recorriendo, de tal guisa que no entro en la explicación de cada uno de los pasos a bajo nivel. Si queréis saber más sobre algo específico podéis acceder al hipervínculo asociado. Por último, esta instalación está hecha para mi caso de uso, mis necesidades y mi entorno. Lo bueno de los sistemas *nix es que son harto configurables, por lo que cada uno puede encontrar la solución que más se le ajuste y le guste.

Nota

Antes de continuar, tal como hice en el anterior hilo, debo comentar que no soy ningún experto a bajo nivel en la materia. Tengo nociones de linux porque hace tiempo que juego con él (de ahí mi nick), pero no soy profesional de sistemas o redes ni de coña. Mi trasfondo es de programador y de físico, pero siempre he sido entusiasta de la informática y desde pequeño me he dedicado a montar, desmontar y formatear mis ordenadores. Sin embargo, la parte del entendimiento tecnológico fundamental le corresponde a un ingeniero informático reglado, para mí todo esto es solo entretenimiento.

Varios de los pasos que comentaré en este y los otros hilos de la serie requieren de conocimientos de hardware, de administración de sistemas, de securización y de backend. Soy un novato en el asunto pero me gusta aprehender. Lo que quiero decir con esto es que lo que comparto puede estar errado. Por favor, si encontráis algún error de contenido o forma, hacédmelo saber. Este hilo es solo una guía de instalación y configuración de un ordenador con el objetivo de ser un homelab/servidor casero.

Algunas partes de la configuración son extensas, por ello se mostrarán bajo un spoiler, para no ocupar tanto en el scroll. Además, como esta configuración es integral, no me voy a detener en qué es cada una de las cosas que instalo/configuro. Si tenéis alguna duda respecto a algún paquete, servicio, configuración o plugin, simplemente preguntad en este hilo o buscar en la red para qué sirve.

1. - Índice

  1. Índice
  2. Preámbulo
    2.1 Motivación
    2.2 ¿Qué es un homelab?, ¿por qué un homelab?
    2.3 Hardware
  3. Primeros pasos
    3.1 Sources list
    3.2 Sudo
    3.3 SSH config
    3.4 Firewall
    3.5 Wake on lan
    3.6 Restos de la configuración básica
  4. Macroconfiguración de zsh
    4.1 Instalando el core
    4.2 oh-my-zsh plugins
    4.3 Configurando .zshrc
  5. Instalando CUDA drivers
  6. Instalando zfs
    6.1 Crear un pool de cero
    6.2 Montar un volumen
  7. Samba
    7.1 Configurando las opciones globales de Samba
    7.2 Creando directorios compartidos de Samba
    7.3 Creando Samba Share User y grupo
  8. Docker
    8.1 Instalación de Docker
    8.2 Docker rootless mode
    8.3 Nvidia docker toolkit
  9. Servidor DNS Pi-Hole
  10. Palabras finales
    10.1 Para el futuro
    10.2. ¡Continúa con la serie!

2. - Preámbulo ↑

2.1. - Motivación ↑

Tras casi dos años usando el NAS de synology se me ha quedado muy, muy corto. La razón es que empecé a exigirle bastante. Más allá de salirme de la caja de DSM (el OS privativo de synology) para configurar a mi gusto muchas cosas de *nix, resulta que le estaba exigiendo demasiado al pobre ordenador. En los últimos años me he convertido en un gran aficionado de docker, y el ds920+ simplemente no podía con los microservicios que yo le estaba exigiendo o quería exigirle.

Recientemente, he adquirido un nuevo ordenador para el trabajo, así que mi ordenador antiguo ha quedado libre de pecado. Por tanto, era un perfecto momento de reaprovecharlo un poco, transformándolo en mi homelab, y así trastear, montar microservicios y demás tonterías. Es decir, el segundo de esta trilogía de hilos no va sobre la configuración de un sistema DSM sino sobre la instalación y puesta a punto de un homelab casero. Usaré la última versión de Debian, Debian 12, sin interfaz gráfica (sin X11). En el tercer hilo hablaré sobre los microservicios que lanzo, dando justificación al hardware.

2.2. - ¿Qué es un homelab?, ¿por qué un homelab? ↑

Lo primero que debemos preguntarnos es ¿qué es un homelab y por qué debería interesarnos? Un homelab representa un espacio de laboratorio informático montado en casa, diseñado para experimentar con nuevas tecnologías y adquirir conocimientos sobre redes y gestión de sistemas. Algunas razones para montar de un homelab podrían ser:

  • Exploración de nuevas tecnologías: El homelab ofrece una vía excelente para adentrarse y poner a prueba distintas tecnologías en un entorno seguro. Esto implica la instalación de diversos sistemas operativos, experimentación con diversos servicios y el aprendizaje en la configuración y administración de distintos tipos de hardware.

  • Desarrollo de habilidades en gestión de sistemas: En un homelab puedes fortalecer y expandir tus habilidades en la gestión de sistemas. Aquí se pueden adquirir conocimientos en la configuración y administración de servidores, redes, almacenamiento y otros sistemas informáticos.

  • Economía: Mediante un homelab puedes, aprovechando el hardware que ya tengas por casa, montarte tu juguete que puede servir como alternativa para reducir costes asociados a servicios en la nube. Como instalamos y gestionamos nuestros propios servidores y servicios podemos acceder a ellos sin depender de plataformas externas.

2.3. - Hardware ↑

Lo que haré será reaprovechar mi ordenador antiguo intentando gastar poco en su puesta a punto. Empecé haciendo una limpieza integral de la caja. Cambié dos de los ventiladores antiguos que tras casi siete años ya traqueteaban un poco. También cambié la pasta térmica del procesador. De pura suerte, tras hacer esto, la AIO del CPU murió, así que compré un disipador bien valorado actualmente (Thermalright Assasin 120E) y sustituí la AIO estropeada. También adquirí dos discos duros EXOS x18 Enterprise de 18 Tb. Lo último que compré fue una tarjeta de red de 10 Gb TP-Link TX401.

A continuación listaré pero no entraré en las especificaciones técnicas del hardware final, como sí hiciera en el hilo anterior.

Especificaciones técnicas

OS: Debian 12
CPU: Intel i7 7700 k
GPU: Gigabyte AORUS GeForce RTX 3080 MASTER (Rev.1.0) 10GB GDDR6
MOBO: Asus ROG STRIX Z270E GAMING
PSU: Corsair RMX750 80 Plus Gold 750W
RAM: 4 × 8 Gb (32 Gb) KFA2 HOF Hall Of Fame 3600MHz (PC4-28800) CL17
HDD M.2: 2 × 1000 Gb (2 Tb) Samsung SSD 970 EVO Plus + Crucial CT1000P1SSD8
* HDD SATA: 2 × 18 Tb (36 Tb) EXOS x18 Enterprise
* NIC: 1 × TP-Link TX401 (10 Gb RJ45)

* Quitando los ventiladores y el disipador, por manteminiento, esto es lo único que he comprado para metamorfosear mi antigua battlestation en un servidor.

Sobre la red

Recientemente, he actualizado mi LAN y mi WAN a 10 Gb, razón por la que le he metido este NIC al servidor. Mi PC de trabajo va con un NIC 10G integrado, y al NAS le puse un NIC de 5 Gb por usb 3.0 (QNAP QNA-UC5G1T). Estos dispositivos van a un HUB tonto de 10G (TL-X105), que conecta al único puerto 10G que monta el router (ZTE F8648P) de mi ISP (DIGI). Como varios de los servicios que pretendo consumen ancho de banda, para mí era relevante actualizar la LAN y la WAN. Mi intención es que el servidor gestione todas las conexiones de mis dispositivos a través de openVPN. Es decir, toda navegación, desde los vídeos en los móviles hasta las películas en netflix 4k, sin olvidar los backups diarios hacia el NAS, pasarán por el servidor, pudiendo haber concurrencia. También es importante para temas de torrent/seedbox, así como para Plex y algún servidor de juegos que pretendo.

3. - Primeros pasos ↑

Esta guía parte de una instalación fresca de Debian 12. Para ello, se ha montado un pendrive y se ha hecho una instalación regular sin marcar el entorno gráfico en la instalación. Este ha sido el único momento en el que conectaremos un teclado y una pantalla al ordenador. A partir de aquí, todo el servidor será manejado en entorno consola mediante una conexión SSH (configurada durante la instalación).

Así que nos conectamos al servidor mediante ssh y... ¡empezamos!:

3.1. - Sources list ↑

Como hemos instalado Debian 12 desde usb debemos comentar la línea en sources list pues, si no, tendremos error con el apt dado que intentará acceder al usb cada vez. Así que, como root:

nano /etc/apt/sources.list

Comentamos las líneas referentes al cdrom (la "#" antes de la línea)

#deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD Binary-1 with firmware 20231007-10:29]/ bookworm main non-free-firmware

3.2. - Sudo ↑

Para mayor comodidad instalaremos "sudo", de modo que podamos ejecutar comandos de root desde nuestro usuario, previa identificación. Actualizamos apt-get e instalamos sudo

sudo apt update -y && sudo apt full-upgrade -y && sudo apt autoremove -y && sudo apt clean -y && sudo apt autoclean -y
apt-get install sudo

Con esto lo tenemos instalado, solo falta que añadamos nuestro usuario a sudoers (mi usuario es "hda", cámbialo por el tuyo):

usermod -aG sudo hda

3.3. - SSH Config ↑

3.3.1. - Keys

Procedemos configurando el ssh para loguear con ssh key y no con contraseña. Esto hace la autentificación más segura y sencilla.

  1. Creamos (si no tenemos ya) la clave en el ordenador local: ssh-keygen
  2. Copiamos nuestra clave pública en el servidor
    Desde Linux al Servidor
    ssh-copy-id hda@HDA-SERV
    Desde Windows al Servidor
    # primero creamos al carpeta .ssh/ en nuestra home del servidor
mkdir ~/hda/.ssh

# luego en consola de windows desde la carpeta ssh donde creamos previamente las claves, la copiamos al servidor:
scp id_ed25519.pub hda@HDA-SERV:/home/hda/.ssh/authorized_keys
    Configuración de permisos
    Aplicamos los permisos correctos a nuestra carpeta .ssh 
    chmod 700 /home/hda/.ssh && chmod 600 /home/hda/.ssh/authorized_keys
chown -R hda:hda /home/hda/.ssh

    3.3.2. - [opcional] Configuración SSH

    Ahora configuraremos el servidor SSH a nuestro gusto, partiendo del siguiente archivo podemos cambiar varias cosas: 
    sudo nano /etc/ssh/sshd_config
    Podemos cambiar las siguientes cosas: 
    Port 4444 #Cambio de puerto SSH
PasswordAuthentication no #Deshabilitar el login por contraseña
PermitRootLogin no #Deshabilitar el Root login
    Por último reiniciamos el servicio: 
    sudo systemctl restart ssh
    Y con esto tenemos el ssh configurado por completo.

    3.4. - Firewall↑

    El siguiente paso será instalar un firewall en el sistema. Usaremos Uncomplicated Firewall. Y lo configuraremos de tal modo que por defecto prohiba toda conexión entrante, pero permita la saliente. Además, añadiremos la regla para que acepte conexiones ssh (del paso anterior). Todo esto es fácil con los siguientes pasos: 
    sudo apt-get -y install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 4444 #Add rules on ssh port
sudo ufw enable
sudo reboot

    3.5. - Wake on Lan ↑

    ¡Es importante que el servidor se pueda levantar mediante Wake on Lan! Si por alguna razón se encuentra en estado apagado (Estado S5), necesitamos poder encenderlo remotamente. Para ello, la tarjeta de red debe ser compatible (la g en la siguiente imagen): 
    sudo apt-get -y install ethtool
ip link show # listamos los interfaces
sudo ethtool enp3s0 #chequeamos el interfaz objetivo


    Imagen 1. Captura de pantalla con la información WOL del NIC.

    En el caso de que lo sea, lo activamos con: 
    sudo ethtool -s enp3s0 wol g
sudo reboot

    3.6. - Restos de la configuración básica↑

    Aprovechando este enlace y el feedback del compañero @carracho vamos a configurar un par de cosas más

    Unatended upgrades

    El propósito de UnattendedUpgrades es mantener la máquina con los últimos updates de seguridad, así que se lo metemos al servidor y lo configuramos. 
    sudo apt-get -y install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

    Timezone

    Podemos listar los timezones mediante: 
    timedatectl list-timezones
    y a continuación establecemos el que deseemos: 
    sudo timedatectl set-timezone Europe/Madrid

    Network Time Protocol

    Ahora instalamos ntp, Network Time Protocol, sirve para sincronizar el reloj del ordenador con servidores de sincronización. Hacer esto es una buena práctrica para mantener los logs del servidor ajustados. 
    apt-get -y install ntp
sudo /etc/init.d/ntpsec start
    Con esto ya tenemos configurado el tiempo del ordenador.

    Set Hostname

    Ponerle nombre a la máquina. Podemos ponerle un FQDN o un identificador, lo que más nos convenga 
    sudo hostnamectl set-hostname HDA-SERV
    Podemos editar hosts para añadir este nombre: 
    sudo nano /etc/hosts
    Y añadimos la línea 
    127.0.0.1    localhost HDA-SERV
    Este paso de hosts, relacionando la IP del servidor con un nombre, habría que repetirlo en los ordenadores de la lan para que el servidor sea reconocible por nombre (y no necesariamente por IP). Otra opción es configurarlo en el router si vas con DHCP. Existen varias alternativas para conseguir esto.

    Reducir GRUB timeout

    El GRUB es programa que carga el kernel del OS elegido. Una cosilla sencilla que podemos hacer para que el boot sea más rápido es cambiar el timeout del GRUB a uno más corto. Editamos ese tiempo en el siguiente archivo: 
    sudo nano /etc/default/grub
    y después lo actualizamos: 
    sudo update-grub

    Tuneamos neofetch

    Entre los varios paquetes que hemos instalado previamente, uno de ellos fue neofetch. Este es un programa que nos da la info del sistema. En esta configuración esta info la dará automáticamente al loguear por ssh. Para adaptar neofetch al gusto editamos el archivo: 
    nano ~/.config/neofetch/config.conf
    y, para mi gusto,
    añadimos:
    También cambiamos la siguiente línea de modo que de la temperatura en centígrados: 
    cpu_temp="C"

    Activamos logrotate

    Mediante logrotate tendremos mejores logs para las aplicaciones que gustemos. Dejamos en avance configurado logrotate para traefik, contenedor que veremos en el siguiente hilo de la serie. Para ello creamos el siguiente archivo: 
    sudo nano /etc/logrotate.d/traefik
    y lo llenamos con 
    /opt/traefik/logs/*.log {
  daily
  rotate 30
  missingok
  notifempty
  compress
  dateext
  dateformat .%Y-%m-%d
  create 0644 root root
  postrotate
  docker kill --signal="USR1" $(docker ps | grep '\btraefik\b' | awk '{print $1}')
  endscript
}
    Nota: el contenedor ha de llamarse traefik y deberá tener montado este volumen: 
    volumes:
  - /opt/traefik/logs:/logs

    4. - Macroconfiguración de zsh ↑

    4.1. - Instalando el core ↑

    Ahora instalaremos una shell hipervitaminada a nuestro usuario. En concreto zsh+ohmyzsh+powerlevel. Lo haremos bastante del tirón. Hemos de tener en cuenta que la siguiente configuración es la que a mí me gusta, para otros podría ser diferente.
    sudo apt-get -y install zsh git fonts-powerline exa fzf neofetch bat
sh -c "$(wget -O- https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
    Reiniciamos la consola, debería cargarnos directamente zsh. Ahí podremos instalar powerlevel 10k: 
    git clone https://github.com/romkatv/powerlevel10k.git $ZSH_CUSTOM/themes/powerlevel10k
    En el .zshrc cambiamos el ZSH_THEME a p10k: 
    #ZSH_THEME="robbyrussell" #comentamos el theme anterior
ZSH_THEME="powerlevel10k/powerlevel10k" #e indicamos el p10k theme
    Reiniciamos la consola y procedemos con la configuración de powerlevel.

    4.2. - oh-my-zsh plugins ↑

    Reentramos en la consola y debería cargarnos directamente zsh. Lo siguiente será descargar los plugins de oh-my-zsh que nos interesen. La siguiente es una colección con los instaladores de plugins que yo uso.
    Plugins oh-my-zsh

    4.3. - Configurando .zshrc ↑

    Lo siguiente que toca es poner al gusto la zsh, para ello editamos el archivo mediante: 
    nano .zshrc

    4.3.1. - Preámbulos

    Añadimos a la parte superior del archivo todo lo siguiente: 
    neofetch

# AUTOCOMPLETION

# initialize autocompletion
autoload -U compinit && compinit

# history setup
setopt SHARE_HISTORY
HISTFILE=$HOME/.zhistory
SAVEHIST=3000
HISTSIZE=2999
setopt HIST_EXPIRE_DUPS_FIRST
    Podemos cambiar la forma en la que se nos presentan las fechas cambiando la siguiente línea: 
    HIST_STAMPS="dd/mm/yyyy"

    4.3.2. - Activamos los plugins

    En la parte de plugins activamos los que hayamos descargado, para ello ponemos: 
    plugins=(
        fast-syntax-highlighting
        git
        alias-finder
        zsh-autosuggestions
        zsh-completions
        zsh-fzf-history-search
        zsh-history-substring-search
        zsh-shift-select
        you-should-use
)
    Añadimos la siguiente línea encima de "source $ZSH/oh-my-zsh.sh" 
    fpath+=${ZSH_CUSTOM:-${ZSH:-~/.oh-my-zsh}/custom}/plugins/zsh-completions/src

    4.3.3. - Añadimos los alias y ending

    Los alias son atajos de consola que simplifican mucho la vida. Yo uso unos cuantos, además de que he fusilado muchos para el futuro manejo de docker. Para añadir los alias, en el .zshrc, bajo "Example aliases" ponemos lo
    siguiente:
    Con el alias aptup pondrás al día el apt, descuida por el error de pihole, que instalaremos más adelante. Además de los alias también incluye control para poder seleccionar y navegar con el teclado entre palabras más fácilmente, además de información sobre nvidia CUDA necesaria para el siguiente paso.

    5. - Instalando CUDA drivers ↑

    En mi caso, además de la gráfica integrada del procesador, me interesa que el sistema reconozca la GPU de nvidia con los drivers propietarios para hacer uso de CUDA. Para ello debemos instalar los drivers de la gráfica. Cabe destacar que, además de instalar los prerrequisitos y configurar los drivers, es necesario desactivar los drivers nvidia Nouveau, no propietarios, que integra debian por defecto.
    Instalamos los siguientes paquetes
    sudo apt-get -y install gcc make chafa exiftool software-properties-common
    Desactivamos Nouveau
    Desactivar nouveau, creamos el siguiente archivo: 
    sudo nano /etc/modprobe.d/blacklist-nouveau.conf
    Y lo llenamos con: 
    blacklist nouveau
options nouveau modeset=0
    Después regeneramos el kernel initramfs y reiniciamos: 
    sudo update-initramfs -u
sudo apt-get install linux-headers-$(uname -r)
sudo add-apt-repository contrib
sudo apt-key del 7fa2af80
sudo reboot
    Luego descargamos el cuda-keyring package, actualizamos apt, instalamos y reiniciamos: 
    wget https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get -y install cuda
sudo reboot

    6. - Instalando zfs ↑

    Una de las cosas que me propuse con este servidor es jugar con el sistema de archivos zfs. Este es un sistema de archivos muy utilizado, tipo BTFRS. En el siguiente enlace podéis leer sobre sus ventajas. En mi caso crearé dos pools de datos. 1) un único disco M.2, para aplicaciones y volúmenes de docker. 2) dos discos mecánicos de 18 Tb, en espejo; es decir, con la información redundada.

    Cabe señalar que estableceré una copia de seguridad diaria del servidor en el NAS, pero solo del disco del sistema y de 1). No copiaré 2) porque será un disco de descargas y por tanto de información transitoria que no pretendo conservar más allá de tener la redundancia en espejo que comento.

    Para instalar zfs: 
    sudo apt-get -y install gdisk linux-headers-amd64 zfsutils-linux zfs-dkms zfs-zed
sudo reboot

    6.1. - [opcional] Crear un pool de cero ↑

    Si necesitamos crear los volúmenes desde cero haremos lo siguiente

    Borrar los discos

    ¡Peligro, esto te elimina completamente la información de los discos! He puesto "DISCO1" hasta "DISCON" para que tengas que cambiarlo activamente. Ojo que perderás todo. 
    sudo sgdisk --zap-all /dev/DISCO1
sudo sgdisk --zap-all /dev/DISCON

    Crear un volumen

    Con los discos listos ya puedes crear un volumen (o pool). En la siguiente línea lo hacemos. Fíjate en el final de la línea. Al volúmen le llamaré "SERV-DATA", será una pool en espejo (básicamente una RAID 1) con los discos sda y sdb. 
    sudo zpool create -f -d -o ashift=12 -O atime=off -o feature@lz4_compress=enabled SERV-DATA mirror /dev/sda /dev/sdb

    6.2. - Montar un volumen ↑

    Y por último montamos los volúmenes que haya.

    6.2.1. - [opcional] Buscar los pools creados

    Si, independientemente de que hayas creado pools en el paso anterior, tienes pools creados previamente puedes listarlos mediante. 
    sudo zpool import


    Imagen 2. Captura de pantalla con el listado de los pools zfs del sistema.

    6.2.2. - Cargar los pools creados

    Solo queda cargar los pools creados. Una vez sabiendo su nombre haces (en mi caso mis pools son SERV-PROG y SERV-DATA): 
    sudo zpool import -f SERV-PROG
sudo zpool import -f SERV-DATA
    Ahora puedes ver el status: 
    sudo zpool status


    Imagen 3. Captura de pantalla con el estado de los pools zfs del sistema.

    7. - Samba ↑

    Para poder comunicarnos con facilidad en el entorno de red, instalaremos y configuraremos el protocolo samba: 
    sudo apt-get -y install samba smbclient cifs-utils

    7.1. - Configurando las opciones globales de samba ↑

    En el archivo 
    sudo nano /etc/samba/smb.conf
    ponemos el work group correcto (yo uso desde hace años CLANDESTINE) 
    workgroup = CLANDESTINE

    7.2. - Creando directorios compartidos Samba ↑

    Crearemos un par de directorios, uno público y otro privado, dentro del pool de data: 
    sudo mkdir /SERV-DATA/public && sudo mkdir /SERV-DATA/private
    En el archivo 
    sudo nano /etc/samba/smb.conf
    Al final del archivo configuramos estos directorios que hemos creado 
    [public]
   comment = Public Folder
   path = /SERV-DATA/public
   writable = yes
   guest ok = yes
   guest only = yes
   force create mode = 775
   force directory mode = 775
[private]
   comment = Private Folder
   path = /SERV-DATA/private
   writable = yes
   guest ok = no
   valid users = @smbshare
   force create mode = 770
   force directory mode = 770
   inherit permissions = yes

    7.3. - Creando Samba share user y grupo ↑

    Necesitamos un share user group para acceder a lo privado compartido, así que creamos el grupo y añadimos las carpetas previas a este grupo, dándoles los permisos adecuados 
    sudo groupadd smbshare
sudo chgrp -R smbshare /SERV-DATA/private/
sudo chgrp -R smbshare /SERV-DATA/public/
sudo chmod 2770 /SERV-DATA/private/
sudo chmod 2775 /SERV-DATA/public/
    Lo siguiente es crear un user local sin login para acceder a la carpeta privada y lo añadimos al grupo que creamos antes. 
    sudo useradd -M -s /sbin/nologin sambauser
sudo usermod -aG smbshare sambauser
    Ahora creamos una contraseña para el usuario y lo activamos 
    sudo smbpasswd -a sambauser
sudo smbpasswd -e sambauser
    Y, por último, añadimos la regla al firewall y reiniciamos el servicio 
    sudo ufw allow from 192.168.1.0/24 to any app Samba
sudo systemctl restart nmbd

    8. - Docker ↑

    El último paso de esta guía es instalar docker. Como podéis ver, lo que hemos recorrido hasta ahora ha sido la configuración funcional del servidor, para poder trabajar con él. Docker será nuestro gestor de servicios. Es decir, todo lo que excede los servicios que hemos ido creando hasta ahora serán instanciados mediante docker. Esta configuración de docker comprende el tercer y último hilo de esta trilogía. Por lo pronto, instalemos y configuremos docker.

    8.1. - Instalación de Docker ↑

    Vamos a continuación a instalar Docker y Docker-Compose.

    8.1.1. - GPG key

    Lo primero que necesitamos es instalar el GPG key 
    # Add Docker's official GPG key:
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

    8.1.2. - Docker package y test

    sudo apt-get -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    Con esto ya debería estar funcionando, podemos hacer un test mediante la línea 
    sudo docker run hello-world


    Imagen 4. Captura de pantalla con la prueba de funcionamiento de docker.

    Este no es mal momento para incrementar la memoria virtual disponible para los contenedores. Para ello añadimos la línea vm.max_map_count=262144 en /etc/sysctl.conf y reiniciamos: 
    sudo echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
sudo reboot

    8.2. - Docker rootless mode ↑

    Uno de los objetivos de esta guía es hacer las cosas seguras (configuración de ssh, firewall, etc.). Como la mayoría de los microservicios los correremos a través de docker, y docker por defecto corre sobre root, desde hace un par de años existe la posibilidad de correr docker sin root, es decir docker rootless mode. Esto puede complicar el funcionamiento de algunas imágenes docker, pero es mucho más seguro. Si un microservicio se ve comprometido, complica mucho al atacante la escalada de privilegios en el host.

    Para proceder con docker rootles, instalamos los siguientes paquetes 
    sudo apt-get install -y dbus-user-session fuse-overlayfs slirp4netns uidmap
    Luego desactivamos el demonio de docker: 
    sudo systemctl disable --now docker.service docker.socket
    A continuación instalamos docker rootless: 
    sudo apt-get install -y docker-ce-rootless-extras
/usr/bin/dockerd-rootless-setuptool.sh install
    Una cosa interesante que podemos hacer es establecer que la gestión de logs la lleve el sistema, para ello: 
    mkdir ~/.config/docker && echo '{\n  "log-driver": "journald"\n}' | tee -a ~/.config/docker/daemon.json
    Es opcional, entonces, permitir que los puertos menores a 1024 puedan ser establecidos sin privilegios: 
    sudo setcap cap_net_bind_service=ep $(which rootlesskit)
systemctl --user restart docker
    Para deshacer esto último: 
    sudo setcap cap_net_bind_service=-ep $(which rootlesskit)
systemctl --user restart docker
    ¡Con esto tenemos docker corriendo rootless! Fíjate en la siguiente captura, no necesitamos "sudo" para desplegar el hello-world. Nótese que no hemos añadido el usuario a un docker group o similar (cosa que puede crear brechas de seguridad).


    Imagen 5. Captura de pantalla con la prueba de funcionamiento de rootless docker.

    8.3. - Nvidia docker toolkit ↑

    Ahora instalaremos la caja de herramientas de nvidia que permite comunicarse con docker. Configuramos el repositorio: 
    curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list \
  && \
    sudo apt-get update
    Y luego instalamos la herramienta 
    sudo apt-get install -y nvidia-container-toolkit
    A continuación permitimos la ejecución rootless de nvidia, configuramos el runtime y reiniciamos el servicio docker 
    sudo sed -i 's/^#no-cgroups = false/no-cgroups = true/;' /etc/nvidia-container-runtime/config.toml
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
    Con esto deberíamos tener la gráfica funcionando en docker. Testea con: 
    docker run --rm --gpus all debian nvidia-smi


    Imagen 6. Captura de pantalla con la ejecución de nvidia-smi desde rootless docker.

    9. Servidor DNS Pi-Hole ↑

    Lo siguiente será instalar Pi-Hole, básicamente es un servidor DNS al que apuntarán nuestros dispositivos. De este modo podremos filtrar las peticiones a webs a nivel de red. Esto tiene efectos muy positivos, como que todas las peticiones contra la publicidad será bloqueada incluso antes de realizarse, por ejemplo

    Instalar Pi-Hole es sencillo. Pipeamos a bash el script de instalación y seguimos los pasos: 
    curl -sSL https://install.pi-hole.net | sudo bash


    Imagen 7. Captura de pantalla con la ejecución del instalador de pi-hole.

    Sigue los pasos de instalación al gusto y continuamos configurando. Una vez que esté instalado, lo que debemos hacer es que las DNS del servidor se apunten a sí mismo. Esto lo logramos editando el siguiente archivo: 
    sudo nano /etc/resolv.conf
    Y cambiamos las ip que ahí aparecen a 127.0.0.1
    Por último, el servicio DNS corre en el puerto 53, así que lo añadimos al firewall: 
    sudo ufw allow 53
    Con esto ya tienes el servidor dando la configuración básica de DNS. Si quieres hacer cosas más chulas, como reglas y grupos de reglas a según qué usuario, deberás meterte más en profundidad. Esta es una buena fuente.

    10. - Palabras finales ↑

    ¡Felicidades, ya tienes el servidor configurado! Muchas gracias por acompañarme hasta aquí. Tras la instalación del sistema, en este hilo hemos recorrido la configuración básica de un sistema operativo y sus dependencias para montar un homelab/servidor casero. Hemos preparado la configuración básica del sistema, luego una shell actual y cómoda, hemos instalado los drivers de nvidia para poder hacer funcionar cuda. Hemos instalado el sistema de archivos zfs y samba. Y, por último, hemos instalado docker de una forma segura. Mediante este hilo podéis seguir el discurso de pensamiento y acción que he llevado a la composición de mi homelab/servidor casero. Espero que os haya sido entretenido.


    Imagen 8. Captura de pantalla con la entrada en el servidor una vez ya configurado.

    10.1. - Para el futuro ↑

    Ahora que ya tengo el servidor montado y estoy contento, tengo muchas ganas de hincharlo a microservicios. Lo cierto es que no pretendo hacer datahoarding y que los 18Tb en espejo debieran ser suficientes por lo pronto; pero no estaría mal proyectar cómo upgradear el juguete. Llevo ya un tiempo pensándolo y creo que mi siguiente paso sería adquirir un pequeño rack e ir montando todos los juguetes en él. Ahora el "barebone" NAS y su SAI, el SAI de mi ordenador de trabajo/servidor junto con el servidor en sí (que va en una ATX), y el hub, ocupan mucho espacio. Cuánto mejor montarlo todo ordenadito en rack, bien ventilado y con posibilidad de expandir con caddies para meter más discos duros, jeje.

    10.2. - ¡Continúa con la serie! ↑

    1. El primer hilo trata sobre el hardware que he montado y por qué.
    2. (este) El segundo hilo trata sobre la configuración básica del sistema.
    3. El tercer hilo sobre microservicios personales para proyectos y jugueteos que me gustaría hacer.

    Versión 1.0R1 (12/12/2023)

    Changelog



    Esta obra está bajo una licencia Reconocimiento-No comercial 4.0 de Creative Commons. Para ver una copia de esta licencia, visite https://creativecommons.org/licenses/by-nc/4.0/deed.es o envíe una carta a Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.
62
hda
hda #2 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

No puedo dejar de insistir en que si veis algún error, por favor, hacédmelo saber. Como he dicho, para mí todo esto es solo un hobby y estoy convencido de que cometo mil meteduras de pata. Así que, de antemano, ¡muchas gracias!

Si tenéis alguna duda en alguna de las partes de esta guía, no dejéis de comentar en el hilo (¡o de buscar en inet!).

Abrazos.

6
pantocreitor
pantocreitor #3 4 Dic

spoiler

EDIT: duda con el tema CUDA, ¿instalando los drivers oficiales de nvidia (apt install nvidia-driver-xxx) no funciona como debe? ¿O son drivers específicos para usar CUDA para ML y demás?

2 respuestas
hda
hda #4 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#3 jaja, sí, ha salido grandote. ¡He tenido la delicadeza de añadir un ancla (↑) al índice en cada uno de los epígrafes!

hda
hda #5 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#3 para que rule CUDA necesitas instalar los drivers oficiales, propietarios de nvidia. Para hacer eso, debes desactivar los drivers no propietarios, los noeveu.

Zireael
Zireael #6 4 Dic

Pillo sitio para luego
Alguien tiró de conjunta xd

1 respuesta
hda
hda #7 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#6 jeje, sí. Me vino al pelo, porque ya estaba montando el servidor. De hecho, tanto es así, que me hice socio numerario de la asociación que monta esas conjuntas. Buena gente (y controlan un montón).

Subiré esta guía y la anterior a la web de la asociación.

1
draz1c
draz1c #8 4 Dic

Muy interesante, gran hilo!

Me han surgido un par de dudas:

  • Para ejecutar rootles Docker configuras que los puertos menores a 1024 puedan ser establecidos sin privilegios, pero eso no es como solucionar un problema de seguridad añadiendo otro, o como harían en Los Simpsons: desatar una plaga de serpientes aguja chinas para acabar con los lagartos?

  • Para que sirve los drivers de CUDA? Quiero decir, no son para tarjetas gráficas especiales tipo Quadro y cosas asi? Si por contra son compatibles con tarjetas "gaming" normales que uso le vas a dar en tu servidor/homelab?

Como te gustan estas cosas te lanzo un reto por si en algún momento futuro te animas a ello: Automatizar los pasos descritos en la guia en, por ejemplo, Ansible para poder desplegar tu configuración en cualquier servidor de manera casi instantánea. Tanto para tí por si necesitas montar un servidor de backup/testing como para si cualquier otra persona desea tener la misma configuración sin tener que introducir comando a comando manualmente.

1 respuesta
preguntitas
preguntitas #9 4 Dic Cofrade

Por que usas openvpn y no wireguard?

Me encanta el material que nos das

2 2 respuestas
hda
hda #10 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#8 Hey, ¡mil gracias!

1) sí podría ser un agujero de seguridad. En mi caso, menores de 1024, solo estarán expuestos el 80 y el 443 a internet. El resto lo haré todo con proxy inverso y a las conexiones virtuales de docker. Posiblemente, lo ideal es levantar todo por encima de 1024 y luego enrutar en las reglas del router.

2) Necesito los drivers privativos de Nvidia para hacer uso de los cores CUDA. La 3080 monta 8704 de estos. Estos núcleos son óptimos para computación, siendo ampliamente utilizados para deep learning. Es habitual usar gráficas gaming para entorno de trabajo. Por ejemplo, mi PC de trabajo monta 2 × 4090, en vez de una H100. Sale más económico, tengo la misma VRAM y además me permite viciar XD

En mi homelab pretendo desplegar algunos modelos de deep learning. En especial whisper, entre otros. Whisper permite hacer transcripciones de audio a texto de una calidad increíble. Puedes usar whisper contra los servidores de openai, pagando. Pero es open source, así que te lo puedes montar tú mismo.

Un juguete que monté hace no mucho fue una pipeline que partía de un audio a un bot personal de Telegram, transcribía ese audio, lo analizaba y sintetizaba, y componía un markdown con la transcripción, resumen, ideas accionables, contraargumentos, etc, de vuelta al usuario que mandó el audio al bot (el objetivo era crear una nota bien estructurada para obsidian).

Pues bien, si monto Whisper en mi servidor, eso que me ahorro. También puedo montar un servicio de stable diffusion para sacar imágenes mediante prompt ya sea mediante gui o mediante api (para integrar en otras pipelines).

¡Las posibilidades son muchas!

Respecto a lo último que comentas, no tengo ni la más remota idea. ¡Pero suena muy interesante! Dame info :D

#9 ¡Gracias! Pues por nada específico. Llevo tiempo usando openVPN y muy contento con él hasta ahora. Yo teletrabajo desde casa, pero cuando teletrabajo desde fuera de casa me debo conectar a mi ordenador de casa (que es el del trabajo). Todo esto lo tengo montado mediante openVPN y rdp. Adicionalmente, tengo acceso para hacer los backups contra el NAS, que también está en la VPN. De hecho, hasta ahora, ha sido el propio NAS el servidor VPN.

¿Alguna razón para primar wireguard frente a openVPN?

1 2 respuestas
arnaupool
arnaupool #11 4 Dic

Joder hda, vaya curro. Te admiro muchísimo

1 respuesta
hda
hda #12 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#11 ¡gracias, señor! Realmente me ha llevado un par de semanas de configuración. Voy y vengo:

La primera vez que me puse a instalar no recuerdo dónde la cagué. Fue un día. Al día siguiente formateé y volví a empezar.

La segunda vez que me puse con ello fui tomando algunas notas y guardando algunos enlaces. Llegué hasta el final. Ocurrió que, configurando los permisos de un certificado ACME en un microservicio de docker escribí:

sudo chmod 600 /

en vez de

sudo chmod 600 .

Cargándome, literalmente, el servidor. El puto trabajo de las últimas dos semanas.

La tercera vez que me puse con él, esta, ya tenía bastantes notas y fresco el camino, así que fui documentando más y mejor todo el proceso. Esta vez me llevó solo dos días, y lo iba haciendo entre partida y partida de Counter Strike 2 (por alguna razón, desde la última actualización, por fin dan un montón de elo al ganar; no era cuestión de dejar pasar la oportunidad XD).

Como me habían quedado unas buenas notas y yo sabía que me había comprometido con el segundo hilo para el foro... ¡salió esto!

Me gustaría pensar que pudiera resultarle útil a alguien :)

1 1 respuesta
Soltrac
Soltrac #13 4 Dic MV Wizard

Mis servidores se avergüenzan del tuyo xDD.

Lo único, comentarte que yo con ese router de digi, en el momento que tenía varios servidores con cientos de conexiones (te lo digo por el seedbox q pretendes montar), internet se me moría. En mi caso, eran nodos de chains de cryptos, pero supongo que con torrent me hubiera pasado lo mismo. Tuve que cambiar a un router profesional.

1 respuesta
hda
hda #14 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#13 Tomo nota y si empieza a cascar la conexión chequearé eso primero. También puede petar por el hub tonto, es muy nuevo en el mercado y no sé cómo se comportará bajo estrés. Con las pruebas IPERF3 no ha habido problemas, pero una cosa es ancho de vanda y otra conexiones, como dices.

¡Gracias por el cumplido! Aunque estoy convencido de que tus máquinas están dpm. A mí me prima mucho la seguridad. Es cierto que desde este lado, más blueish, la perspectiva es muy diferente. Cuando juegas como red team siempre terminas echando pestes de quien hubiese configurado, pero es que desde este lado la cantidad de cosas que puedes estar configurando de forma insegura... ¡son un quintal! ¡Y sin contar con CVEs!

1
draz1c
draz1c #15 4 Dic
#10hda:

Respecto a lo último que comentas, no tengo ni la más remota idea. ¡Pero suena muy interesante! Dame info

Lo de Ansible ya lo he tocado un poco por encima en mi hilo de DevOps (sección 3.1 - Ansible).

Básicamente defines un archivo con los pasos a ejecutar y un archivo de inventario con una o múltiples máquinas. Y al ejecutar el playbook se ejecuta en todas las máquinas que tengas en el inventario.

Te pongo un ejemplo de como serían los 3 primeros pasos de la guía:

- name: "HDA's server"
  hosts: all
  become: true

  tasks:

    - name: Disable USB/CD-ROM from sources.list file
    lineinfile:
      path: /etc/apt/sources.list
      regexp: '^deb cdrom'
      line: '#deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD Binary-1 with firmware 20231007-10:29]/ bookworm main non-free-firmware'

  - name: Install Sudo
    package:
      update_cache: true
      name: sudo
      state: present

  - name: Add hda user to sudo group
    user:
      name: hda
      groups: sudo
      append: yes

Tras ejecutar este playbook, cualquier persona que lo ejecutase tendría exactamente la misma configuración. Con lo que solo tendrias que guardar este archivo de texto y su archivo de inventario en un repositorio de GitHub por ejemplo, y podrias desplegar la configuración de tu servidor en cuestión de segundos en cualquier parte del mundo y poder por lo tanto replicar tu configuración en caso de formateo todas las veces que quieras sin perder apenas tiempo.

Si te interesa aprender más de Ansible tienes la playlist de Ansible 101 de Jeff Geerling. Yo me compré su libro en Amazon pero lo tienes para descargar en pdf gratis. Parece que estoy un poco obsesionadete con el tío este porque no dejo pasar cualquier oportunidad que tengo para meter la cuñita y hablar de él, pero esque me cae genial y me ha enseñado muchísimo.

#10hda:

¿Alguna razón para primar wireguard frente a openVPN?

Yo en casa tambien uso OpenVPN porque para el uso que le doy no necesito más, pero dicen que Wireguard funciona mejor.

Gráficas como esta hay muchas en internet y en todas sale perdiendo ovpn contra wg.

2 1 respuesta
FlameThrower
FlameThrower #16 4 Dic

No me lo he leído completo.

¿Por qué no has usado Nix? :v

¿Por qué Rootless Docker y no Podman? (ésta si es en serio).

Yo estoy en una tesitura similar a la tuya, aunque la verdad no le he sacado tanto partido porque tengo una Rpi4 y con eso he ido metiendo los pocos servicios que uso (PiHole, Bases de datos, probar Nextcloud, etc.) pero se me está quedando pequeño y no sé si simplemente meterle más discos o tirarme por montar algo, que es lo que realmente quiero pero en este momento no puedo hacerlo. Gracias por el curro de la guía, seguramente le de un vistazo más adelante.

P.D: Yo le hubiera puesto Tailscale y tira millas... te quitas de muchos problemas.

2 respuestas
arnaupool
arnaupool #17 4 Dic

#12 Lo es!! Como a una persona que ha intentado tres veces hacerse su propia nube personal con una rpi y fallando estrepitosamente en el proceso, esto inspira mucho

1
hda
hda #18 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#15 ostrás, parece muy potente Ansible. Se asemeja a montar una imagen docker, jaja. Muchas gracias por acercármelo, nunca lo he tocado. Supongo que para archivos de configuración (como el .zshrc) podrás tener un repositorio para copypastear el documento. La verdad es que pinta bien. No entra en mis prioridades por el esfuerzo que supondría, pero me lo apunto. De hecho, entiendo que con esta propia guía traducir a ansible debiera ser más o menos sencillo.

Respecto a wireward, lo estudiaré en profundidad. Parece muy prometedor.

Por cierto, pedazo de hilo. Recuerdo haberlo leído cuando lo montaste.

#16FlameThrower:

¿Por qué Rootless Docker y no Podman?

Pues, realmente, porque no me he puesto nunca con podman. Siempre he trabajado con docker-compose (ahora docker compose) y no sé cuán complicada es la migración de uno a otro. Como ya está en stable rootless docker, he pensado oportuno trabajar con ello en vez de con docker a secas, que es como vengo trabajando los últimos dos años. ¿Tanto merece la pena el cambio?

Por cierto, ¿tu rpi te mueve bien nextcloud? Cuando lo intenté montar en el NAS el pobre no daba más de sí xD

Respecto a tailscale... ¿estás recomendado esa solución para montar un entorno VPN? ¿Pero es de pago, no? Si es así y puedo, prefiero montar mi propia red VPN desde mi servidor.

1 1 respuesta
FlameThrower
FlameThrower #19 4 Dic

#18 Es de pago si tienes más de 100 dispositivos o si quieres trabajar con más de un usuario (esta parte no estoy seguro al 100% porque hay formas de estar en el free tier y dar acceso a otros usuarios). Que también tiene opciones self-host como Nebula. Otra opción es Zerotier.

Lo de Podman lo digo porque es rootless por defecto, no hay mucha diferencia con Docker, puedes usar Docker compose pero si tiene algunos temas que son un poco diferentes y hay que adaptar los compose (en algunos casos).

1
Zireael
Zireael #20 4 Dic

Muy muy chulo, enhorabuena por el currazo.

No es el hilo más adecuado porque creo que este iría mejor en slguiente, el de los microservicios pero bueno.

Como ya te han dicho, yo cambiaría a wireguard, es un protocolo más moderno y, sobretodo, más rápido que openvpn. Instalarlo es ultra fácil con wg-easy

Luego, yo instalaría portainer, que para uso casero, puedes pedir la licencia business que te da 3 nodos gratuitos (antes eran 5), así puedes manejar rápidamente los contenedores.

Para la documentación yo utilizo bookstack, si tienes que compartir conocimiento con varias personas viene muy bien, o incluso, para no olvidarse uno mismo de cómo ha configurado algo.

1 respuesta
bLaKnI
bLaKnI #21 4 Dic Inocente

Joder... no deja de asomarme el porque hacéis esto... Quiero decir, ¿os da la vida? Y si os da, ¿es con eso con lo que queréis invertir el tiempo personal?
Y una vez lo tienes montado y piensas "olé yo!", ¿que?
¿Qué microservicios tienes montados en casa y en pro de que? ¿Hay algo "lucrativo" detrás mas allá del hobby?
¿Cómo le dedicas pasión y no procrastinas al ponerte ha hacer estas cosas?

1 respuesta
hda
hda #22 4 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#20 ¡Hey! Mil gracias por tu comentario. Definitivamente exploraré wireward. Doy por hecho que lo puedo desplegar por docker. En verdad me pica la curiosidad. Además, si meto wireward en el servidor lo que haré será montar openvpn en el NAS (como hasta ahora) de tal guisa que tenga un backup para lanzar paquete mágico si se apaga el servidor.

Levanto portainer, pero no despliego a través de portainer, sino de docker compose. Estuve haciendo pruebas para levantar un stack de solo el portainer y un watchtower. Luego desde portainer levantar todos los demás stacks. Pero, por lo visto, no es lo más aconsejable. Parece que lo ideal es tal como yo lo tenía, desplegar fuera de portainer y, limitadamente, manejar los dockers con pornatiner. Cuando hablas de 3 nodos gratuitos... ¿te refieres a 3 stacks?

bookstack mola. La verdad es que hay una cantidad de microservicios en lo salvaje que... es la leche. Mi intención es montarme un excel con los diferentes stacks "temáticos" y luego ver cuáles necesitan estar expuestos a inet y cuales van solo en la lan (en la vpn), porque quiero limitar los vectores de ataque. Cosas como prowlar o transmission realmente no necesito que estén a internet, con que rulen en local a través de vpn va dpm, por ejemplo.

#21 como todo... cuando algo es un hobby disfrutas el tiempo que le inviertes. A mí me gusta mucho cacharrear, llevo toda la vida haciéndolo. Y aunque mi formación no tiene que ver con OS o con redes, sí que soy un tecnófilo. Como comento por ahí arriba, el server lo fui montando entre partida y partida de counter. Y luego alguna noche quedándome hasta tarde. Pero es que es algo que me gusta. Entro en "flow", y se me pasa el tiempo volando. Me pasa con muchas cosas, eso de levantarse con ganas de seguir haciendo aquello o aquello otro.

Sobre microservicios será el siguiente hilo. Es todo un mundo.

1 respuesta
Zireael
Zireael #23 4 Dic

#22 Wireguard lo puedes instalar con docker, en el enlace que te he dicho tienes toda la info (Obviamente teniendo ya el SDK instalado pero obvio que tú versión de OS ya lo trae preinstalado.

Yo levanto a través de portainer y 0 problemas, la verdad. Por nodos me refiero a servidores, puedes gestionar 3 de forma gratuita en una sola instancia de portainer.

1
FlameThrower
FlameThrower #24 5 Dic

No entiendo lo de Portainer, totalmente innecesario. Es más un estorbo que una ayuda, pero 🤷‍♂️

P.D: NextCloud en la Rpi4 va medianamente bien, lo malo es que algunas de las extensiones no son compatibles con arm.

1 respuesta
carracho
carracho #25 5 Dic

Respecto a UFW... ojito, un detalle a tener en cuenta es que el enrutamiento de docker se bifurca antes (por decirlo rápido y mal) por eso es necesario esto: https://github.com/chaifeng/ufw-docker

1 respuesta
preguntitas
preguntitas #26 5 Dic Cofrade

#10 más ligero, más moderno y más seguro. Por lo que tengo entendido. E incluido en el kernel

1 respuesta
hda
hda #27 5 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#25 gracias por el call. Lo tendré en cuenta si fallan las cosas. ¿No estará solucionado? Nunca he tenido que encargarme de eso en la últimos dos años, y los servicios ven y se ven en internet sin problemas. Es más, el stack básico de prueba que he puesto en este servidor ha rulado bien.

#26 definitivamente le echaré una ojeada.

1 respuesta
carracho
carracho #28 5 Dic

#27 La prueba más que ver que se pueden comunicar desde el exterior... es la de bloquear un puerto expuesto por docker y ver si no puedes conectar.

1 respuesta
hda
hda #29 5 Dic Agujeros negros ( ͡° ͜ʖ ͡°)

#28 Sí, sin problema. Por defecto tengo deny all, y para poder conectar con algunos microservicios he tenido que abrirlos manualmente.

1 respuesta
Urien
Urien #30 5 Dic Gatillazo

Muy interesante!

Yo he trabajado siempre con OpenVPN con unos resultados estupendos y 0 desconexiones. Ahora que trabajo con FortiClient es una cosa que valoro bastante porque el muy cabrón te pega 2 o 3 cortes en una jornada laboral y si mis operadores suben ficheros... mal.
Debo de decir que no conocía WireGuard pero si necesito una VPN en un firewall que no sea de Forti le voy a dar un try a esto.

Una pregunteja ¿se lo podrías chutar a un Pfsense sin mayor drama, no?

1 2 respuestas

Usuarios habituales

  • hda
  • Zireael
  • carracho
  • FlameThrower
  • Urien
  • preguntitas
  • Hipnos

Tags