HDA-SERV: Configuración

Si quieres trastear, te recomiendo que le metas node-red (nativo, no sobre Docker). Nativo porque de otra forma no vas a poder ejecutar scripts sobre el server sin hacer alguna ñapa con tuberías de entrada/salida entre tu contenedor Docker y el host.

Yo lo tengo para definir las cron de forma visual, un bot de telegram con algunos comandos y para notificaciones del server. Es muy cómodo, y ya antes de ponerme a picar ningún script tiro directamente por node-red. Además que para copias de seguridad es bastante simple: te copias los flows.json y a tirar millas.

Un ejemplillo chorra para reproducir canciones de navidad estos días en el salón automáticamente

#64 jaja, buena esa. Pero ya sabes, cuanto más sabes más consciente eres de lo poco que sabes. Hay peña que controla muchísimo en lo salvaje. De hecho, al final estamos limitados por lo que conocemos. El mundo de la informática es tan amplio, tan grande, que hay caminos de los que desconozco su existencia. Porque si al menos sabes qué no sabes, puedes informarte sobre ello. Pero si no sabes qué no sabes... para uno aquello no existe.

Por ejemplo, gracias a #16 me he estado informando y valorando mucho si migrar a podman. En este caso podman me sonaba pero nunca me puse a leer sobre ello.
Otro ejemplo, gracias a #9 he conocido wireward. Que ni sabía de su existencia (y seguro que es algo básico para alguien que controle). Lo más probable es que meta wireward en este servidor.
O... #51, que habla en turcosueco para mí (a excepción de kubernetes y grafana xD)

Hey, #59, revisando los comentarios me he dado cuenta de que me he saltado el tuyo, disculpa. Desde que estoy en la asociación de homelabs, que es algo reciente, he conocido proxmox y esxi, porque esos tíos sí controlan un montón y los usan. Como estaban todo el día hablando de ello busqué un poco de info. Hasta donde sé, para lo que pretendo con mi homelab, sus servicios y jugueteos, se me escapa un poco montar un entorno de virtualización. No veo el caso de uso para mí. Pero sí molaría montarlo por montarlo. Solo que ahora tengo otras prioridades.

#68 rsync es sin duda una gran herramienta.

A raíz de tu comentario me ha dado por investigar un poco y me he topado con https://www.psc.edu/hpn-ssh-home pinta interesante.
Además, he visto un estudio de Google sobre TCP: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36640.pdf . Respecto a este tema no me queda claro si linux ya aplica un valor de 10 por defecto a 'initcwnd'... pero según la documentación de "ip-route" se están usando los valores propuestos en el RFC2414: https://www.rfc-editor.org/rfc/rfc2414 . Donde se dice claramente "A study involving simulations of a large number of HTTP transactions over hybrid fiber coax (HFC) indicates that the use of larger initial windows decreases the time required to load WWW pages".

Un tema interesante al que darle un vistazo en profundidad!

** Si, ya por defecto se usa 10 desde hace tiempo.

#70

• Para el tema de la configuración de ssh puedes echar un ojo aquí: https://www.ssh.com/academy/ssh/sshd_config
• journalctl es el demonio de logging de systemd ... puedes engancharlo con otro tipo de software y/o usarlo directamente con sus múltiples opciones de filtrado. Es algo que te ayuda a ver que ha pasado cuando algo sale mal.
• El tema de logrotate te lo recomienda el mismo proyecto de traefik, ellos delegan en que usarás dicha herramienta... sino eso, lo que obtienes es un archivo de 'access.log' que va creciendo sin control... y te puedes encontrar un día con gigas de datos consumidos por el archivo xD (todo depende del traqueteo que tenga el servidor claro...)
• scp es eso, 'cp' por ssh... rsync es más potente... por ejemplo, solo mueve contenido nuevo y en caso de mover muchos archivos pequeños también tiene ventaja, entre otras cosejas que permite hacer. Por poder puedes levantar un servicio rsync y usar su propio protocolo.

De nada! espero que te sea de ayuda y de paso yo también aprender algo nuevo si cae igual tu ves algo a raíz de lo que yo te pueda comentar que nos termine siendo útil a ambos.

#72 Yo tampoco lo encuentro... la nota que tengo apuntada es de hace 13 meses. Recuerdo que el dato se presentaba en un 'powerpoint' mientras el tipo comentaba un poco el asunto. Se que es de cisco porque en otro archivo lo tengo en el comentario... pero no enlacé el vídeo :/
Yo lo que tengo en mis notas (trilium, un servicio que recomiendo levantar):

• Ampliar el tamaño de la 'Virtual Memory Area':
  vm.max_map_count=262144
  El kernel utiliza áreas de memoria virtual para mantener un registro de las asignaciones de memoria de los procesos
  Info Adicional: https://www.suse.com/support/kb/doc/?id=000016692

• Kernel virtual memory accounting mode (1 = always overcommit, never check)
  vm.overcommit_memory=1
  En este modo cuando un proceso utiliza, por ejemplo, malloc, no se comprobará por parte del sistema operativo si tiene espacio... lo que terminará en un crasheo

Entender vm.overcommit_memory:

Setting overcommit_ratio to 80 is likely not the right action. Setting the value to anything less than 100 is almost always incorrect.

The reason for this is that linux applications allocate more than they really need. Say they allocate 8kb to store a couple character string of text. Well thats several KB unused right there. Applications do this a lot, and this is what overcommit is designed for.

So basically with overcommit at 100, the kernel will not allow applications to allocate any more memory than you have (swap + ram). Setting it at less than 100 means that you will never use all your memory. If you are going to set this setting, you should set it higher than 100 because of the fore-mentioned scenario, which is quite common.
However, while setting it greater than 100 is almost always the correct answer, there are some use cases where setting it less than 100 is correct. As mentioned, by doing so you wont be able to use all your memory. However the kernel still can. So you can effectively use this to reserve some memory for the kernel (e.g. the page cache).

Now, as for your issue with the OOM killer triggering, manually setting overcommit will not likely fix this. The default setting (heuristic determination) is fairly intelligent.

If you wish to see if this is really the cause of the issue, look at /proc/meminfo when the OOM killer runs. If you see that Committed_AS is close to CommitLimit, but free is still showing free memory available, then yes you can manually adjust the overcommit for your scenario. Setting this value too low will cause the OOM killer to start killing applications when you still have plenty of memory free. Setting it too high can cause random applications to die when they try to use memory they were allocated, but isnt actually available (when all the memory does actually get used up).