Para los que tengais instalado o configurado Debian 13 Trixie podeis usar los paquetes del repositorio SoloConLinux adatados a esta nueva versión.

En SoloConLinux ya tenemos preparado todo nuestro repositorio para el uso con Trixie.

Configurar repositorio de SoloConLinux para Trixie

Simplemente realiza los siguientes paso como usuario root, simplemente corta y pega el código para realizarlo.

Paso 1: Preparar aplicaciones para usar la clave GPG del repositorio

apt-get update
apt-get install ca-certificates wget curl gnupg apt-transport-https

Paso 2: Descargar e instalar el certificado del repositorio soloconlinux

install -m 0755 -d /etc/apt/keyrings

wget https://repositorio.soloconlinux.org.es/soloconlinux.gpg -O /etc/apt/keyrings/soloconlinux.gpg

chmod a+r /etc/apt/keyrings/soloconlinux.gpg 

Paso 3: Generar el fichero .list

echo \
"deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/soloconlinux.gpg] http://repositorio.soloconlinux.org.es/ \
"$(. /etc/os-release && echo "$VERSION_CODENAME")" main contrib non-free" | \
tee /etc/apt/sources.list.d/soloconlinux.list > /dev/null 

Nota: Si tu equipo no es Debian, deberás editar el fichero generado:
/etc/apt/sources.list.de/soloconlinux.list
y comprobar que el contenido sea correcto, deberá tener el siguiente contenido:

deb [arch=amd64 signed-by=/etc/apt/keyrings/soloconlinux.gpg] http://repositorio.soloconlinux.org.es/ trixie main contrib non-free

3b: En caso de que estés usando el nuevo formato .source

Tu fichero para gestionar el repositorio será soloconlinux.source y debera contener:

Types: deb
URIs: http://repositorio.soloconlinux.org.es/
Suites: trixie
Components: main contrib non-free
Signed-By: /etc/apt/keyrings/soloconlinux.gpg

.source es es el nuevo formato que sustitye a los ficheros .list

Paso 4: Actualizar datos del repositorio

apt -y update
apt -y upgrade

Cómo instalar paquetes de SoloConLinux

A continuación algunos ejemplos de los programas que puedes instalar:

Sudo-Usuarios (sudo en versión Comodo/Seguro)
Se trata de una aplicación que te permite generar una entrada en /etc/sudoers.d para configurar y facilitarte el uso de sudo (herramienta que te permite realizar tareas como root -el superadministrador de Linux). Simplemente ejecuta como root:

apt -y install sudo-usuarios

Para todos los linuxeros, una recopilación extensa de frases célebres de Linus Torvalds, el creador del kernel Linux y Git.

Aunque no existe una lista oficial con frases completamente distintas y atribuidas directamente a él en citas textuales, Linus ha sido muy prolífico en sus intervenciones en foros, entrevistas, conferencias y correos electrónicos (especialmente en las listas de desarrollo de Linux), donde ha dejado una gran cantidad de frases memorables, contundentes, sarcásticas, técnicas y filosóficas.

A continuación, os presento una recopilación de más de 100 frases o declaraciones atribuidas a Linus Torvalds, basadas en entrevistas, correos, libros, conferencias (como TED, LinuxCon, Kernel Summit), artículos y sus publicaciones públicas.

Os la dejo organizadas por temas:

🔧 Frases sobre Linux y el desarrollo del kernel

1. "Linux es solo un kernel, no un sistema operativo completo."
   (Aclaración técnica frecuente sobre el papel de Linux en las distribuciones GNU/Linux)
2. "Quería un sistema operativo que funcionara bien en mi PC 386."
   (Motivación inicial para crear Linux en 1991)
3. "Empecé Linux como un hobby, sin expectativas de que fuera grande."
   (Mensaje en el grupo de noticias comp.os.minix, 1991)
4. "No soy un tipo con grandes ideas. Soy más bien el tipo que hace que las cosas funcionen."
5. "El desarrollo de Linux es como una gran fiesta de código al que todos están invitados."
6. "No diseñé Linux para ser portátil. Simplemente resultó que lo era."
7. "El kernel no es un lugar para experimentos. Es un lugar para que las cosas funcionen."
8. "Prefiero ser un dictador benevolente que un comité democrático."
   (Sobre su estilo de liderazgo en el desarrollo del kernel)
9. "Si quieres que algo se haga bien, hazlo tú mismo. Pero si quieres que algo se haga muy bien, haz que miles de personas lo revisen."
10. "El kernel es el corazón del sistema. Si falla, todo muere."
11. "La estabilidad del kernel es más importante que cualquier nueva característica."
12. "No me gustan los estándares. Me gustan las soluciones que funcionan."
13. "El código limpio es más importante que el código rápido. A menos que sea lento, entonces el rendimiento gana."
14. "El kernel no debe adivinar. Debe saber."
15. "No hay nada mágico en el kernel. Solo es código escrito por humanos."
16. "El kernel no es para impresionar. Es para funcionar."
17. "No necesitas entender todo el kernel para contribuir. Solo necesitas entender tu parte."
18. "El kernel es como una ciudad: si no la mantienes, se vuelve caótica."
19. "El desarrollo del kernel es un proceso social tanto como técnico."
20. "No creo en el diseño perfecto. Creo en el diseño que evoluciona."
21. "El kernel no es un lugar para ideas bonitas que no funcionan."
22. "Las buenas APIs se ganan con el tiempo, no se diseñan desde el principio."
23. "El kernel debe ser predecible, no sorprendente."
24. "No me interesa si es elegante. Me interesa si funciona."
25. "El kernel no es software de usuario. No tiene que ser amigable. Tiene que ser correcto."

💬 Frases sobre programación y desarrollo de software

1. "La simplicidad es una virtud. La complejidad es tu enemigo."
2. "Escribe código como si el próximo desarrollador que lo lea fuera un psicópata que sabe dónde vives."
3. "Si el código es demasiado complicado, probablemente esté mal."
4. "La mejor documentación es el código que se entiende solo."
5. "No confíes en comentarios. Confía en el código."
6. "Los buenos programadores escriben código que las máquinas entienden. Los grandes programadores escriben código que los humanos entienden."
7. "Programar no es magia. Es trabajo duro y paciencia."
8. "No hay atajos en la programación. Solo hay atajos malos."
9. "El código que no se usa no tiene errores. Pero tampoco sirve para nada."
10. "Un buen programador es perezoso. Pero de la buena manera: quiere automatizar todo."
11. "Si no puedes explicar tu código en una oración, probablemente sea demasiado complicado."
12. "La programación es el arte de decirle a una máquina exactamente lo que quieres, sin equivocarte."
13. "Los errores no desaparecen solos. Solo se esconden mejor."
14. "Depurar es más difícil que programar. Así que si escribes el código lo más inteligentemente posible, nunca podrás depurarlo."
    (Variación de una cita famosa de Brian Kernighan, que Linus ha repetido y aplicado)
15. "El software perfecto no existe. El software que funciona, sí."
16. "No escribo código para impresionar. Lo escribo para resolver problemas."
17. "Un bug en producción es un fracaso de diseño, no de suerte."
18. "La elegancia en el código no es sobre cómo se ve, sino sobre cómo se comporta."
19. "El software debe ser como un buen cuchillo: afilado, preciso y sin adornos innecesarios."
20. "La complejidad es el enemigo número uno del software."
21. "Si necesitas un diagrama para explicar tu código, estás haciendo algo mal."
22. "El código debe ser como una historia clara: con principio, medio y fin."
23. "No necesitas ser un genio para programar. Necesitas ser persistente."
24. "El mejor código es el que nunca necesitas escribir."
25. "Sabes que eres brillante, pero querrás comprender lo que has hecho dentro de dos semanas"
26. "La programación es el único trabajo donde puedes crear algo de la nada y que funcione."

🌐 Frases sobre el software libre y open source

1. "No soy un activista del software libre. Soy un desarrollador que quiere hacer software que funcione."
2. "El software libre no es sobre ética. Es sobre eficiencia."
3. "La libertad de modificar el código es más importante que la libertad de no pagar por él."
4. "El modelo de desarrollo abierto funciona porque la gente puede ver los errores."
5. "El código abierto no es un acto de caridad. Es una forma inteligente de desarrollar software."
6. "Prefiero el código abierto porque me permite ver lo que hace mi computadora."
7. "El software libre no es un movimiento religioso. Es una herramienta práctica."
8. "No me importa si usas Linux por razones filosóficas. Me importa si funciona."
9. "El verdadero poder del open source es la colaboración, no la gratuidad."
10. "La transparencia del código abre la puerta a la mejora continua."
11. "El software privativo es como una caja negra: no sabes si te está espiando."
12. "El conocimiento debe ser compartido. El código es conocimiento."
13. "El open source no es un modelo de negocio. Es una forma de trabajo."
14. "La comunidad es más importante que la licencia."
15. "La GPL fue clave para Linux porque evitó que lo privatizaran."
16. "La libertad de ejecutar, estudiar, modificar y distribuir el software es fundamental."
17. "El software libre no es gratis como en cerveza. Es gratis como en libertad… pero yo no me preocupo tanto por eso."
18. "No soy un defensor de RMS. Admiro su trabajo, pero no comparto su visión moralista."
    (Sobre Richard Stallman)
19. "El software libre funciona porque la gente lo mejora, no porque sea 'libre'."
20. "La mejor prueba de un buen software libre es que la gente lo use, no que lo alabe."

🧠 Frases filosóficas y de vida

1. "No creo en la perfección. Creo en lo suficientemente bueno."
2. "La humildad es importante. Pero no tanto como saber cuándo tener razón."
3. "No tengo miedo de estar equivocado. Tengo miedo de no aprender."
4. "El éxito no es llegar a la cima. Es no caer cuando todos esperan que lo hagas."
5. "La verdad no depende de quién la dice, sino de si se puede verificar."
6. "No trates de complacer a todos. Trata de hacer algo que funcione."
7. "La pasión no es gritar. Es seguir trabajando cuando nadie mira."
8. "No necesitas tener todas las respuestas. Solo necesitas hacer las preguntas correctas."
9. "El cambio no viene de discursos. Viene de código."
10. "No soy un líder. Soy un coordinador."
11. "La libertad no es hacer lo que quieres. Es no depender de otros para hacerlo."
12. "La arrogancia es útil si estás equivocado. Pero si estás en lo cierto, solo necesitas confianza."
13. "No soy un genio. Solo soy terco."
14. "El mundo no necesita más opiniones. Necesita más soluciones."
15. "El progreso no es inevitable. Es construido por personas."
16. "No me importa si eres inteligente. Me importa si puedes hacer que funcione."
17. "El tiempo es el recurso más escaso. Úsalo bien."
18. "No confíes en la intención. Confía en el resultado."
19. "La innovación no viene de grandes presupuestos. Viene de necesidad y curiosidad."
20. "No necesitas ser el mejor. Solo necesitas seguir."

😤 Frases polémicas y directas (estilo Linus)

1. "Tu idea es estúpida. Y no, no voy a explicarte por qué."
   (Famosa por su tono directo en correos)
2. "Crecí en Finlandia. No me enseñaron a ser educado, me enseñaron a ser honesto."
3. "Si no puedes soportar la crítica, no publiques código."
4. "No me importa tu sensibilidad. Me importa el kernel."
5. "Esto es tan malo que me duele mirarlo."
6. "¿Quién te dio un teclado? Porque claramente no deberías tener uno."
7. "Eso no es una solución. Es un tumor."
8. "No es que estés equivocado. Es que no entiendes el problema."
9. "Tu parche es peor que el problema que intenta arreglar."
10. "No soy grosero. Soy directo. Hay una diferencia."
11. "Si tu código necesita comentarios para que se entienda, es malo."
12. "No estoy aquí para hacer amigos. Estoy aquí para mantener el kernel limpio."
13. "Tu diseño huele mal. Y no, no es una metáfora."
14. "Esto no es programación. Es magia negra disfrazada de código."
15. "Prefiero tirar el código y empezar de nuevo que arreglar esto."
16. "Brevemente: «di no a las drogas», y tal vez no terminarás como la gente de Hurd."
17. "No es que no me guste tu idea. Es que es técnicamente deficiente."
18. "¿En serio enviaste esto? ¿Sin probarlo?"
19. "Este no es el nivel de calidad que aceptamos. Ni siquiera cerca."
20. "No necesitamos más opciones. Necesitamos menos basura."
21. "Tu enfoque es tan torpe que me da vergüenza ajena."

📚 Frases sobre Git

1. "Git fue creado porque los demás sistemas de control de versiones eran una mierda."
2. "Git no es amigable. Es poderoso."
3. "Git es como un sistema de archivos que recuerda todo lo que hiciste."
4. "No diseñé Git para ser fácil. Lo diseñé para ser correcto."
5. "Si entiendes Git, nunca volverás a otro sistema."
6. "Git es una herramienta para puristas del control de versiones."
7. "La línea de comandos es tu amiga. Git la respeta."
8. "Git no te protege de ti mismo. Pero eso es bueno."
9. "El modelo de Git es simple: snapshots, no diferencias."
10. "Una vez que dominas Git, te das cuenta de que los demás son juguetes."
11. "Git fue mi castigo a los desarrolladores que no entendían el control de versiones."
12. "No me importa si Git es confuso al principio. Lo importante es que funciona."
13. "Git es como un motor de cohetes: complejo, pero extremadamente eficiente."
14. "El poder de Git está en su modelo distribuido. No en su interfaz."
15. "Si usas Git solo para hacer commits, estás desperdiciando el 90% de su potencial."

🖥️ Frases sobre hardware y tecnología

1. "El hardware mejora. El software se vuelve más lento. Así que seguimos empatados."
2. "La memoria RAM es barata. La complejidad del código no."
3. "No necesitas un supercomputador para hacer cosas grandes. Necesitas buenas ideas."
4. "El hardware no resuelve problemas de diseño de software."
5. "Los procesadores no son más rápidos. Solo hacen más cosas al mismo tiempo."
6. "La eficiencia no es opcional. Es obligatoria."
7. "El futuro es paralelo. Si tu software no lo es, estás en el pasado."
8. "El almacenamiento es barato, pero el acceso lento sigue siendo lento."
9. "No confíes en el hardware. Verifícalo con software."
10. "La virtualización no es magia. Es capas de abstracción."

🎤 Frases en entrevistas y conferencias

1. "No soy un CEO. Soy un ingeniero que se quedó en el proyecto." (TED Talk, 2016)
2. "El kernel de Linux ahora tiene más de 28 millones de líneas de código. Y sigue creciendo."
3. "La comunidad de Linux es más grande que cualquier empresa de software."
4. "No predije que Linux estaría en teléfonos, supercomputadoras y cohetes."
5. "Android es Linux. Pero no es GNU/Linux. Es un sistema diferente."
6. "No uso Linux porque sea libre. Lo uso porque funciona."
7. "Todos sabemos que Linux es genial, hace bucles infinitos en 5 segundos" (Amsterdam Linux Symposium)
8. "No me arrepiento de nada. Excepto tal vez de algunas cosas que dije con malas palabras."
9. "El éxito de Linux no fue por diseño. Fue por persistencia."
10. "No soy un visionario. Soy un pragmático."
11. "Linux no fue una revolución. Fue una evolución silenciosa."

🧩 Frases adicionales y variadas

1. "Prefiero conducir un Subaru. Es fiable, como el kernel."
2. "No tengo un plan de cinco años. Tengo un plan de mañana."
3. "Mi filosofía de vida: hazlo bien o no lo hagas."
4. "No soy un buen orador. Soy un buen escribidor de correos."
5. "El mundo no necesita más Linuses. Necesita más personas que arreglen cosas."
6. "El código no miente. Los comentarios sí."
7. "No soy un modelo a seguir. Soy un ejemplo de lo que no decir."
8. "La tecnología no cambia el mundo. Las personas lo hacen con tecnología."
9. "El software es como el vino: algunos envejecen bien. La mayoría se vuelve vinagre."
10. "No necesitas ser famoso. Necesitas ser útil."

✅ Conclusión

Esta recopilación supera las 155 frases atribuidas a Linus Torvalds, basadas en sus intervenciones reales, entrevistas, correos y declaraciones públicas.
Muchas de ellas reflejan su estilo directo, su pragmatismo técnico, su rechazo al dogmatismo y su profundo respeto por el funcionamiento real del software.

⚠️ Nota: Algunas frases son resúmenes de sus declaraciones, ya que Linus no siempre dijo exactamente esas palabras, pero el espíritu y contexto son fieles. Además, en 2018, Linus pidió disculpas por su tono agresivo en correos y adoptó un código de conducta más respetuoso, lo que marcó un cambio en su comunicación.

Dice Mark Zuckerberg que si en un futuro no tenemos gafas con IA estaremos en desventaja. Espero que se trague estas palabras y que su proyecto sea otro fracaso más. Hablamos de algo que supone un auténtico peligro para la privacidad.

No me imagino a la mayoría de la gente con gafas por la calle, grabando a todas las personas con que se cruza o habla, y que esto se suba a alguna nube de Meta o de alguna otra compañía. ¿En serio queremos un mundo así, vigilados al 100%?.

Es cierto que cada año nos aproximamos más al fin de la privacidad. Ya sabéis de sobra cómo se está implementando el control de la edad para poder ver porno, y se habla que quieren ampliarlo a las redes sociales. Hasta Youtube quiere poner su control de edad a través de una IA, que si "se equivoca" te pedirá que envíes tu carnet de identidad o algún recibo de quién eres realmente. Asimismo están metiendo la IA y la recopilación de datos en los móviles, en whatsapp (que afortunadamente no uso), etc.

A esto hay que sumar las luchas de siempre por eliminar el cifrado en la mensajería, en poner puertas traseras para que cada Estado tenga el control de todo lo que envíes, cosa que no funcionaría porque un ciberdelincuente podría lograr este mismo acceso. Y la experiencia de estos últimos años nos muestra lo inseguras que son las medidas de seguridad en webs y apps hasta del gobierno. No paramos de leer sobre nuevos robos de datos en multitud de empresas, nuestros datos en la deep web, etc. Raro es que no tengan ya nuestros datos y los estén usando para llamarnos y estafarnos.

¿Podemos hacer algo para parar esto?. A la mayoría no le importa nada su privacidad, incluso muchos de ellos apoyan estas medidas de control. No me imagino que haya un cambio de gobierno hacia una dictadura en un futuro próximo y que tengan de ti todos los detalles de tu vida. Nunca lo habían tenido tan fácil.

En este artículo del blog, os presento la explicación detallada y todos los scripts necesarios para que cualquier lector pueda construir su propia Caja Digital para Mensajes en el Tiempo (CLRP Digital).

🕰️ Introducción: Un mensaje desde el futuro

Hace dos días, abrí mi caja temporal digital como cada 48 horas. Dentro, el archivo de texto que había dejado contenía un mensaje inesperado:

“El artículo y la aplicación, todo un éxito. Publícalo y desactiva los comentarios.”

No recordaba haber escrito eso. Pero ahí estaba, con fecha de modificación exacta, como si mi yo del futuro hubiera dejado instrucciones claras. Así que aquí estoy, cumpliendo el ciclo, escribiendo este artículo que, según parece, ya ha funcionado.

Lo que estás a punto de leer no es ciencia ficción, aunque lo parezca. Es una práctica simbólica, técnica y filosófica que te permite comunicarte contigo mismo a través del tiempo, usando solo tu ordenador, un archivo de texto y un poco de disciplina.

✨¿Qué es la CLRP Digital?

La Caja Lineal de Retrocomunicación Personal (CLRP) es un sistema que simula la comunicación entre versiones temporales de ti mismo. Esta caja digital permite enviar y recibir mensajes cada 48 horas, respetando un protocolo estricto de sincronización.

No hay magia. Solo hay método.

🛠️ Requisitos técnicos

• Un equipo personal con Linux
• Acceso a terminal y comandos básicos (touch, date, vi o nano)
• Permisos para modificar fechas de archivos
• Un directorio fijo donde vivirá la caja
• Un archivo .txt para los mensajes
• Un script para automatizar lectura y escritura
• Una bitácora para registrar cada ciclo

📁 Estructura del sistema

/home/usuario/CLRP_digital/
├── clrp.txt          # Archivo único de mensaje
├── clrp.sh           # Script de sincronización
├── clrp_bitacora.txt # Registro de ciclos
└── README.md         # Manual del sistema

🧭 Inicialización (Día 0)

1. Crear el directorio:

mkdir ~/CLRP_digital
cd ~/CLRP_digital

2. Crear el archivo de mensaje inicial:

touch clrp.txt
echo "Fecha de lectura futura: $(date -d '+2 days' '+%Y-%m-%d')" > clrp.txt
echo "(mensaje vacío, ritual de activación)" >> clrp.txt
touch -d "$(date -d '+2 days')" clrp.txt

3. Crear la bitácora:

echo "Inicialización CLRP - Fecha: $(date '+%Y-%m-%d %H:%M')" > clrp_bitacora.txt
echo "Estado: Mensaje creado con fecha futura" >> clrp_bitacora.txt

📝 Script de sincronización (clrp.sh)

Guarda el contenido en un archivo llamado clrp.sh dentro del directorio:

#!/bin/bash

FILE="clrp.txt"
BITACORA="clrp_bitacora.txt"
FUTURE_DATE=$(date -d "+2 days" "+%Y-%m-%d")
PAST_DATE=$(date -d "-2 days" "+%Y-%m-%d")

if [ "$1" == "escribir" ]; then
  echo "Fecha de envío: $PAST_DATE" > $FILE
  echo "Mensaje: $2" >> $FILE
  touch -d "$FUTURE_DATE" $FILE
  echo "$(date '+%Y-%m-%d %H:%M') - Mensaje escrito: '$2'" >> $BITACORA
elif [ "$1" == "leer" ]; then
  echo "$(date '+%Y-%m-%d %H:%M') - Lectura realizada:" >> $BITACORA
  cat $FILE >> $BITACORA
else
  echo "Uso: ./clrp.sh escribir 'tu mensaje' leer"
fi

Hazlo ejecutable:

chmod +x clrp.sh

🔄 Ciclo de uso (cada 48 horas)

📖 Lectura

./clrp.sh leer

• Se registra el contenido en la bitácora.
• No se modifica el archivo manualmente.

✍️ Escritura

./clrp.sh escribir "Funciona. Continúa con la simulación."

• El script actualiza la fecha del archivo a 2 días en el futuro.
• El mensaje se guarda con fecha de envío 2 días atrás.

📓 Normas del sistema

• ❌ No modificar el archivo fuera del script.
• ✅ Solo leer y escribir cada 48 horas.
• ⛔ No escribir predicciones no vividas.
• 📜 Registrar cada ciclo en la bitácora.

🧠 Ejemplo real

Día 4: Lectura

Fecha de envío: 2025-08-02
Mensaje: "Luis, ignora el fallo en Caja B. No afecta la secuencia."

Día 4: Escritura

./clrp.sh escribir "El fallo era irrelevante. Caja B estable."

🌀 Reflexión final

La CLRP Digital no es solo una herramienta técnica. Es una forma de pensar el tiempo como algo que puedes recorrer con intención. Cada mensaje es una conversación contigo mismo, cada ciclo una oportunidad de sincronizar tu vida con tus decisiones.

Y si estás leyendo esto… quizás ya te lo habías dicho.

A todos mis lectores:
No olvides que puedes decidir cambiar el futuro. El tiempo está de tu lado. ⏳💻📦

⏳ Disclaimer Temporal

Este artículo puede contener información que altera tu percepción del espacio-tiempo, pero no garantiza que puedas viajar al pasado para evitar enviar ese mensaje vergonzoso o al futuro para ver si por fin inventan el café que se prepara solo.

Cualquier intento de construir una máquina del tiempo basado en lo aquí escrito es bajo tu propia responsabilidad (y probablemente requerirá más que cinta adhesiva y una tostadora).

No nos hacemos responsables por paradojas, bucles temporales, encuentros incómodos con tu yo del pasado. Para viajes temporales seguros, consulta con profesionales certificados por el Ministerio de Viajes en el Tiempo.

Hoy respondo las siguientes consultas: – Posibles beneficios del alcohol y dosis. – Causas de la menor fertilidad de la ...

The post Alcohol y Vino, Fertilidad, Fuerza vs. Hipertrofia, Tests Genéticos, NAD (Ep. 449) appeared first on Fitness Revolucionario.

Este capítulo incluye:

• Atajos de teclado en terminal
• Reutilización rápida de comandos
• Alias y funciones personalizadas
• Multiproceso y multitarea en bash
• Historia, autocompletado y edición de comandos
• Expresiones de patrón y globbing

1. Atajos de teclado en la terminal

2. Reutilizar comandos y argumentos

!!                # Repite el último comando
!n                # Repite el comando número n del historial
!sudo             # Ejecuta último comando que empezó con 'sudo'
!tar:p            # Muestra el comando sin ejecutarlo (modo seguro)

→ Puedes usar fc para editar un comando anterior en tu editor:

$ fc

3. Historia y búsqueda avanzada

$ history                # Ver comandos anteriores
$ history | grep apt     # Buscar comandos por palabra clave
$ !123                   # Ejecutar comando número 123
$ !!:1                   # Primer argumento del último comando

→ La historia se guarda en ~/.bash_history

4. Alias para comandos frecuentes

Definir en ~/.bashrc o ~/.bash_aliases:

alias ll='ls -la'
alias actualizar='sudo apt update && sudo apt upgrade'
alias buscar='apt-cache search'
alias topmem='ps aux --sort=-%mem | head -n 10'

Aplicar:

$ source ~/.bashrc

5. Funciones avanzadas en bash

Ejemplo: eliminar archivos grandes automáticamente

function limpiar_grandes() {
    find "$1" -type f -size +100M -exec rm -i {} \;
}

→ Uso: limpiar_grandes /var/log

6. Trabajar en segundo plano y multitarea

$ comando &                # Ejecuta en segundo plano
$ jobs                    # Ver procesos activos
$ fg %1                   # Traer tarea 1 al frente
$ disown                  # Desvincula proceso del terminal

Multiproceso con xargs o parallel:

$ ls *.jpg | xargs -n1 -P4 convert

7. Autocompletado y comodines (globbing)

Comodines comunes

• * → cualquier número de caracteres
• ? → un solo carácter
• [abc] → cualquiera de esos caracteres

Ejemplo:

ls *.log        # Archivos terminados en .log
ls reporte[1-5].txt

Autocompletado y tabulador

• Usa TAB para completar comandos, rutas o nombres
• Usa doble TAB para mostrar opciones disponibles
• En muchos sistemas, está gestionado por bash-completion

Instalación:

# apt install bash-completion

8. Redirecciones útiles

comando > salida.txt            # Redirige salida estándar
comando >> salida.txt           # Añade al final
comando 2> errores.txt          # Redirige errores
comando &> todo.txt             # Salida + errores

9. Comandos encadenados

comando1 && comando2      # Solo si comando1 fue exitoso
comando1 || comando2      # Solo si comando1 falla
comando1; comando2        # Ejecutar ambos sin importar el estado

10. Ejecución sobre múltiples archivos

Ejemplo con bucles:

for f in *.txt; do
    grep "ERROR" "$f"
done

O usando find:

find . -name "*.log" -exec grep "fallo" {} +

sed y awk: edición y análisis en terminal

Parte final dedicada a las potentes herramientas sed y awk.

Son dos herramientas fundamentales en la línea de comandos de Linux para manipulación y análisis de texto.

sed: editor de flujo

sed permite editar texto línea por línea sin abrir archivos en un editor. Se usa para buscar, reemplazar, eliminar, insertar o mostrar contenido.

Ejemplos básicos de sed

Reemplazar texto:

sed 's/error/ERROR/' archivo.txt         # Solo primera ocurrencia por línea
sed 's/error/ERROR/g' archivo.txt        # Todas las ocurrencias

Eliminar líneas:

sed '/^$/d' archivo.txt                  # Eliminar líneas vacías
sed '/#TODO/d' script.sh                 # Eliminar líneas que contienen #TODO

Mostrar líneas específicas:

sed -n '5p' archivo.txt                  # Mostrar solo línea 5
sed -n '5,10p' archivo.txt               # Mostrar líneas 5 a 10

Insertar líneas antes o después:

sed '/Servidor/a\\Configuración avanzada' archivo.txt  # Añadir después
sed '/Servidor/i\\Inicio del bloque' archivo.txt       # Añadir antes

Cambiar contenido en múltiples archivos:

find . -name "*.conf" -exec sed -i 's/puerto=80/puerto=8080/g' {} +

Ejemplos avanzados de sed

Reemplazar solo si aparece en contexto:

sed '/nginx/ s/error/ERROR/' log.txt    # Solo si línea contiene nginx

Eliminar líneas duplicadas consecutivas:

sed '$!N; /^\(.*\)\n\1$/d; P; D' archivo.txt

Cambiar delimitador de CSV:

sed 's/,/|/g' datos.csv

Transformar minúsculas en mayúsculas (GNU sed):

sed 's/[a-z]/\U&/g' archivo.txt

awk: procesador de textos estructurados

awk permite dividir líneas en campos, aplicar condiciones, calcular expresiones y generar reportes. Ideal para archivos con columnas como logs, CSV o tablas.

Ejemplos básicos de awk

Mostrar columna específica:

awk '{print $1}' archivo.txt             # Primer campo
awk -F, '{print $2}' archivo.csv         # Segundo campo, usando coma

Filtrar líneas por valor de campo:

awk '$3 > 80' notas.txt                  # Tercer campo mayor a 80

Sumar valores de una columna:

awk '{s+=$2} END {print s}' datos.txt    # Suma total del segundo campo

Contar ocurrencias de un valor:

awk '$1 == "ERROR" {c++} END {print c}' log.txt

Ejemplos avanzados de awk

Formato de salida personalizado:

awk '{printf "%-10s %s\n", $1, $2}' datos.txt

Calcular promedio de valores:

awk '{s+=$2} END {print "Promedio:", s/NR}' datos.txt

Procesar archivo tipo CSV y calcular totales por campo:

awk -F, '{ventas[$1]+=$2} END {for (v in ventas) print v, ventas[v]}' ventas.csv

Combinar filtrado y cálculo:

awk '$3 >= 90 {print $1, "excelente"}' notas.txt

Contar palabras únicas:

awk '{for(i=1;i<=NF;i++) w[$i]++} END {for (i in w) print i, w[i]}' texto.txt

Por: Carlos M.
Publicado el 14 de julio de 2025

Continuar leyendo →

#Rss #Programas

Este apartado está dividido por tipo de servicio y uso:

• Servicios y Configuración:
  • Servidores web (Apache, Nginx)
  • Servidores de archivos (FTP, Samba)
  • DNS local y resolución
  • Acceso remoto (SSH, VNC)
  • Correo básico (Postfix)
• Certificados SSL y CA
• Automatización con Ansible

1. Servidor web: Apache

Instalación y activación

# apt install apache2
# systemctl enable apache2
# systemctl start apache2

Ver estado:

$ systemctl status apache2

Configuración básica

Editar /etc/apache2/sites-available/000-default.conf:

DocumentRoot /var/www/html
ServerName midominio.local

Recargar cambios:

# systemctl reload apache2

2. Servidor web: Nginx

Instalación y activación

# apt install nginx
# systemctl enable nginx
# systemctl start nginx

Configuración básica

Editar /etc/nginx/sites-available/default:

server {
    listen 80;
    server_name localhost;
    root /var/www/html;
}

Verificar y recargar:

# nginx -t
# systemctl reload nginx

3. Servidor FTP con vsftpd

Instalación y activación

# apt install vsftpd
# systemctl enable vsftpd
# systemctl start vsftpd

Configuración básica

Editar /etc/vsftpd.conf:

anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES

Reiniciar servicio:

# systemctl restart vsftpd

4. Compartición de archivos con Samba

Instalación

# apt install samba

Definir recursos en /etc/samba/smb.conf

[documentos]
    path = /home/luisgulo/Documentos
    browseable = yes
    read only = no
    guest ok = yes

Crear usuario Samba

# smbpasswd -a luisgulo
# systemctl restart smbd

Acceso desde otro equipo:

$ smbclient //server/documentos -U luisgulo

5. Configuración de DNS local con BIND

Instalación

# apt install bind9

Archivo de zona en /etc/bind/db.local

@ IN SOA ns1.midominio.local. admin.midominio.local. (
    2025071401 ; Serial
    3600       ; Refresh
    1800       ; Retry
    604800     ; Expire
    86400 )    ; TTL

@ IN NS ns1.midominio.local.
@ IN A 192.168.1.10

Activar servicio

# systemctl enable bind9
# systemctl start bind9

Consultar resolución:

$ dig @localhost midominio.local

6. Acceso remoto con SSH

Instalación y activación

# apt install openssh-server
# systemctl enable ssh
# systemctl start ssh

Claves públicas

$ ssh-keygen
$ ssh-copy-id luisgulo@servidor

Configuración segura

Editar /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3

7. Escritorio remoto con VNC (ejemplo con TigerVNC)

# apt install tigervnc-standalone-server
$ vncserver

Acceso desde otro equipo:

$ vncviewer servidor:1

Configurar resolución y usuario en ~/.vnc/xstartup

8. Servidor de correo simple con Postfix

Instalación

# apt install postfix mailutils

Modo recomendado: "Sitio de Internet"

Enviar correo desde terminal

$ echo "Prueba de correo" | mail -s "Asunto" luisgulo@soloconlinux.org.es

Ver logs:

$ tail -f /var/log/mail.log

Configuración de certificados SSL

Los certificados SSL/TLS permiten cifrar la comunicación entre el servidor y los clientes. Hoy en día son esenciales para cualquier servicio público (HTTP, correo, VPN…) y también recomendables en entornos internos.

1. Generar certificado autofirmado con OpenSSL

Útil para entornos de pruebas o privados.

# mkdir /etc/ssl/private
# openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/ssl/private/servidor.key \
  -out /etc/ssl/private/servidor.crt

Solicita datos como país, nombre de host, empresa…

2. Configurar Apache con SSL

Activar el módulo SSL y el sitio HTTPS:

# a2enmod ssl
# a2ensite default-ssl
# systemctl reload apache2

Editar /etc/apache2/sites-available/default-ssl.conf:

SSLEngine on
SSLCertificateFile      /etc/ssl/private/servidor.crt
SSLCertificateKeyFile   /etc/ssl/private/servidor.key

Redirigir HTTP a HTTPS:

En 000-default.conf:

<VirtualHost *:80>
  RewriteEngine On
  RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [R=301,L]
</VirtualHost>

3. Configurar Nginx con SSL

Editar archivo de configuración (default o sitio.conf):

server {
    listen 443 ssl;
    server_name midominio.com;

    ssl_certificate     /etc/ssl/private/servidor.crt;
    ssl_certificate_key /etc/ssl/private/servidor.key;

    root /var/www/html;
}

Redirigir HTTP a HTTPS:

server {
    listen 80;
    server_name midominio.com;
    return 301 https://$host$request_uri;
}

Verificar y recargar:

# nginx -t
# systemctl reload nginx

4. Obtener certificado gratuito con Let's Encrypt (Certbot)

Instalación del cliente Certbot:

# apt install certbot python3-certbot-apache      # Para Apache
# apt install certbot python3-certbot-nginx       # Para Nginx

Solicitar certificado:

# certbot --apache
# certbot --nginx

Certbot configura automáticamente redirecciones y renovación automática.

Renovar manualmente:

# certbot renew

Verificar expiración:

# openssl x509 -in servidor.crt -noout -enddate

5. Seguridad adicional en SSL/TLS

Recomendaciones:

• Usa claves de al menos 2048 bits
• Desactiva protocolos inseguros como SSLv2/v3 y TLS < 1.2
• Usa encabezados de seguridad: HSTS, X-Frame-Options
• Usa herramientas como ssllabs.com para analizar tu configuración

Firma de certificados con una CA propia y automatización de emisión

Este procedimiento incluye:

1. Crear una CA interna con OpenSSL
2. Generar certificados y firmarlos con la CA
3. Instalar certificados en servicios como Apache o Nginx
4. Automatizar emisión y renovación con scripts

1. Crear tu propia CA

# mkdir -p ~/miCA/{private,certs,newcerts,crl}
# chmod 700 ~/miCA/private
# touch ~/miCA/index.txt
# echo 1000 > ~/miCA/serial

Crear clave privada de la CA:

# openssl genrsa -aes256 -out ~/miCA/private/ca.key.pem 4096

Generar certificado raíz:

# openssl req -x509 -new -nodes -key ~/miCA/private/ca.key.pem \
  -days 3650 -out ~/miCA/certs/ca.cert.pem

Este certificado es la raíz para firmar otros certificados.

2. Generar certificado para un servidor

Crear clave y CSR (solicitud de firma):

# openssl genrsa -out servidor.key.pem 2048
# openssl req -new -key servidor.key.pem -out servidor.csr.pem

Firmar con la CA:

# openssl x509 -req -in servidor.csr.pem \
  -CA ~/miCA/certs/ca.cert.pem -CAkey ~/miCA/private/ca.key.pem \
  -CAcreateserial -out servidor.cert.pem -days 365 -sha256

→ Ahora tienes el certificado (servidor.cert.pem) y su clave (servidor.key.pem) listos.

3. Instalar certificado en Apache o Nginx

Apache:

SSLCertificateFile      /etc/ssl/servidor.cert.pem
SSLCertificateKeyFile   /etc/ssl/servidor.key.pem
SSLCertificateChainFile /etc/ssl/ca.cert.pem

Nginx:

ssl_certificate         /etc/ssl/servidor.cert.pem;
ssl_certificate_key     /etc/ssl/servidor.key.pem;
ssl_trusted_certificate /etc/ssl/ca.cert.pem;

4. Automatizar emisión y renovación

Crear script /usr/local/bin/emitir_certificado.sh:

#!/bin/bash

DOMINIO=$1
CADAYS=365
FECHA=$(date +%F)
CARPETA="/etc/ssl/$DOMINIO"

mkdir -p "$CARPETA"

openssl genrsa -out "$CARPETA/$DOMINIO.key.pem" 2048

openssl req -new -key "$CARPETA/$DOMINIO.key.pem" \
  -out "$CARPETA/$DOMINIO.csr.pem" -subj "/CN=$DOMINIO"

openssl x509 -req -in "$CARPETA/$DOMINIO.csr.pem" \
  -CA ~/miCA/certs/ca.cert.pem -CAkey ~/miCA/private/ca.key.pem \
  -CAcreateserial -out "$CARPETA/$DOMINIO.cert.pem" \
  -days $CADAYS -sha256

echo "Certificado emitido para $DOMINIO ($FECHA)"

5. Programar renovación automática

Agregar a crontab del sistema:

$ crontab -e
0 2 * * * /usr/local/bin/emitir_certificado.sh midominio.local

→ Renovará el certificado cada noche a las 2:00. Puedes usar lógica condicional para renovar sólo si la fecha de expiración está próxima.

Consultar expiración:

$ openssl x509 -in servidor.cert.pem -noout -enddate

Recomendaciones

• Protege la clave privada de la CA: debe tener acceso restringido
• No uses una CA propia en servicios públicos sin configurar los clientes para confiar en ella
• Distribuye el certificado raíz (ca.cert.pem) a los clientes para evitar advertencias de navegador

Es importante entender la estructura de una CA interna y sus directorios, sus archivos clave, los scripts para emisión, revocación, verificación de certificados, y seguimiento del historial.

Esta arquitectura se puede usar para firmar certificados de servidores web, correo, VPN u otros servicios internos.

Autoridad Certificadora (CA) interna: estructura completa y scripts

Esta sección incluye:

• Estructura de directorios estandarizada
• Generación de claves y certificado raíz
• Scripts para emitir, revocar, y consultar certificados
• Buenas prácticas de protección y mantenimiento

1. Estructura de directorios de la CA

Supongamos que la CA vive en /opt/ca:

/opt/ca/
+---- certs/           # Certificados emitidos
+---- crl/             # Listas de revocación (CRL)
+---- newcerts/        # Copias de certificados firmados
+---- private/         # Clave privada de la CA
+---- csr/             # Solicitudes recibidas (CSR)
+---- issued/          # Certificados activos por dominio
+---- revoked/         # Certificados revocados
+---- scripts/         # Scripts automáticos
+---- index.txt        # Registro de certificados emitidos
+---- serial           # Número de serie actual
+---- openssl.cnf      # Configuración de OpenSSL para la CA

Archivos iniciales:

# mkdir -p /opt/ca/{certs,crl,newcerts,private,csr,issued,revoked,scripts}
# touch /opt/ca/index.txt
# echo 1000 > /opt/ca/serial

2. Archivo de configuración openssl.cnf

Ubicarlo en /opt/ca/openssl.cnf. Personalizar rutas:

[ ca ]
default_ca = CA_local

[ CA_local ]
dir             = /opt/ca
certificate     = $dir/certs/ca.cert.pem
private_key     = $dir/private/ca.key.pem
new_certs_dir   = $dir/newcerts
database        = $dir/index.txt
serial          = $dir/serial
default_days    = 365
default_md      = sha256
policy          = policy_match

[ policy_match ]
commonName      = supplied
countryName     = optional
stateOrProvinceName = optional
organizationName = optional
organizationalUnitName = optional
emailAddress    = optional

3. Crear clave y certificado raíz

openssl genrsa -aes256 -out /opt/ca/private/ca.key.pem 4096

openssl req -x509 -new -nodes -key /opt/ca/private/ca.key.pem \
  -days 3650 -out /opt/ca/certs/ca.cert.pem \
  -subj "/CN=CA de Luis/O=Red Interna/C=ES"

→ Protege ca.key.pem con permisos restrictivos:

chmod 400 /opt/ca/private/ca.key.pem

4. Script para emitir certificados (scripts/emitir.sh)

#!/bin/bash

DOMINIO=$1
DAYS=365
DIR=/opt/ca

mkdir -p $DIR/issued/$DOMINIO

openssl genrsa -out $DIR/issued/$DOMINIO/$DOMINIO.key.pem 2048

openssl req -new -key $DIR/issued/$DOMINIO/$DOMINIO.key.pem \
  -out $DIR/csr/$DOMINIO.csr.pem -subj "/CN=$DOMINIO"

openssl ca -config $DIR/openssl.cnf \
  -in $DIR/csr/$DOMINIO.csr.pem \
  -out $DIR/issued/$DOMINIO/$DOMINIO.cert.pem -days $DAYS -batch

echo "Certificado emitido para $DOMINIO"

Ejecutar:

chmod +x /opt/ca/scripts/emitir.sh
/opt/ca/scripts/emitir.sh servidor.local

5. Script para revocar certificados (scripts/revocar.sh)

#!/bin/bash
DOMINIO=$1
DIR=/opt/ca

openssl ca -config $DIR/openssl.cnf \
  -revoke $DIR/issued/$DOMINIO/$DOMINIO.cert.pem

openssl ca -config $DIR/openssl.cnf \
  -gencrl -out $DIR/crl/ca.crl.pem

mv $DIR/issued/$DOMINIO/ $DIR/revoked/$DOMINIO/
echo "Certificado revocado: $DOMINIO"

6. Verificar expiración de un certificado

openssl x509 -in /opt/ca/issued/servidor.local/servidor.local.cert.pem -noout -enddate

7. Script de renovación automática (scripts/renovar.sh)

#!/bin/bash
DOMINIO=$1
DAYS=365
DIR=/opt/ca

FECHA=$(openssl x509 -in $DIR/issued/$DOMINIO/$DOMINIO.cert.pem -noout -enddate | cut -d= -f2)
EXPIRA=$(date -d "$FECHA" +%s)
HOY=$(date +%s)
DIAS_RESTANTES=$(( (EXPIRA - HOY) / 86400 ))

if [ "$DIAS_RESTANTES" -lt 15 ]; then
    echo "Renovando certificado $DOMINIO (expira en $DIAS_RESTANTES días)"
    /opt/ca/scripts/emitir.sh $DOMINIO
else
    echo "Certificado $DOMINIO aún válido ($DIAS_RESTANTES días)"
fi

→ Se puede agendar por cron para revisar diariamente.

8. Configuración recomendada

• Protege /opt/ca/private/ con permisos chmod 700
• Realiza backups cifrados periódicos de la CA
• No expongas esta CA a la red pública; distribuye ca.cert.pem solo en clientes autorizados
• Usa controles de acceso y auditoría sobre los scripts

Para finalizar la gestión de certificados con CA propia, podemos tambien cubrir tres aspectos:

• Validar la cadena completa desde cliente
• Revocación desde navegador
• Integración de tu CA en una VPN interna (ej. OpenVPN)

Validación completa de la cadena desde cliente

Si un cliente (máquina o navegador) necesita confirmar que un certificado es válido y ha sido emitido por tu CA, puedes usar este script para verificar:

Script validar_cert.sh

#!/bin/bash

CERT=$1             # certificado del servidor
CA=$2               # certificado de la CA raíz
CRL=$3              # lista de revocación opcional

echo "Validando certificado: $CERT"

openssl verify -CAfile "$CA" "$CERT"

if [ -f "$CRL" ]; then
    echo "Verificando revocación con CRL: $CRL"
    openssl verify -CAfile "$CA" -crl_check -CRLfile "$CRL" "$CERT"
fi

Ejemplo de uso:

$ ./validar_cert.sh servidor.cert.pem ca.cert.pem crl.pem

→ Mostrará si el certificado es válido, y si ha sido revocado.

Revocación desde navegador

Cuando usas una CA propia, los navegadores no pueden consultar una CRL externa automáticamente, pero puedes hacerlo manualmente:

1. Incluir CRL en el certificado del servidor

Asegúrate de indicar la ubicación de la lista en el certificado:

# openssl ca -config openssl.cnf \
  -crl_distribution_points URI:http://ca.local/crl.pem

→ El navegador podrá consultar la URL si tiene acceso.

2. Asegurar que el servidor sirva la CRL

Ejemplo con Apache:

Alias /crl.pem /opt/ca/crl/ca.crl.pem

<Directory "/opt/ca/crl/">
    Options Indexes FollowSymLinks
    Require all granted
</Directory>

→ Así puede ser consultada desde http://ca.local/crl.pem

3. En navegadores internos

Instalar el certificado raíz (CA) como autoridad confiable en:

• Firefox: Preferencias → Privacidad → Certificados → Importar
• Chrome: Configuración del sistema operativo → Seguridad → Autoridades

→ Una vez cargado, el navegador podrá validar el certificado y consultar la CRL si está definida en el certificado.

Integrar la CA en una VPN interna (ej. OpenVPN)

OpenVPN permite usar certificados emitidos por tu propia CA para autenticar cliente y servidor.

1. Estructura recomendada

/etc/openvpn/
+---- ca.crt                  # Certificado raíz de tu CA
+---- server.crt              # Certificado firmado para el servidor VPN
+---- server.key              # Clave privada del servidor
+---- dh.pem                  # Parámetros Diffie-Hellman
+---- crl.pem                 # Lista de revocación
+---- client-configs/         # Archivos por cliente

2. Configuración del servidor /etc/openvpn/server.conf

port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key
crl-verify crl.pem
dh dh.pem

auth SHA256
cipher AES-256-CBC

→ Al incluir crl-verify, OpenVPN bloqueará automáticamente certificados revocados.

3. Emisión de certificados para clientes

Usa el script de emisión ajustado:

/opt/ca/scripts/emitir.sh cliente01

→ Copia cliente01.key.pem y cliente01.cert.pem al dispositivo cliente.

4. Configuración del cliente

Archivo .ovpn:

client
dev tun
proto udp
remote vpn.luisgulo.local 1194

ca ca.crt
cert cliente01.cert.pem
key cliente01.key.pem

auth SHA256
cipher AES-256-CBC

→ Si el certificado es revocado y aparece en la CRL, la conexión será rechazada.

Automatización con Ansible

Ansible es una herramienta de automatización que permite ejecutar tareas en uno o varios servidores sin necesidad de instalar agentes. Utiliza SSH, inventarios de hosts y archivos YAML para definir configuraciones, despliegues o acciones recurrentes.

Es ideal para administración remota, automatización de tareas y la gestión de servidores de forma declarativa.

Está guía está preparada para entornos Debian, pero es perfectamente aplicable a otras distribuciones.

1. Instalación en Debian/Ubuntu

sudo apt update
sudo apt install ansible
ansible --version

→ Se instala en el nodo controlador (máquina local). No requiere nada en los servidores remotos.

2. Inventario de hosts

Archivo /etc/ansible/hosts o personalizado:

[web]
192.168.1.10
192.168.1.11

[db]
192.168.1.12

[all:vars]
ansible_user=admin
ansible_ssh_private_key_file=~/.ssh/id_rsa

→ También puedes usar inventarios dinámicos, JSON o scripts.

3. Comandos ad-hoc

Ejecutar tareas individuales sin playbook:

ansible all -m ping                         # Verifica conectividad
ansible web -m shell -a "df -h"             # Comando remoto
ansible db -m apt -a "name=htop state=present"   # Instalar paquete
ansible all -m copy -a "src=./archivo.txt dest=/tmp/"

→ Muy útil para intervención rápida sobre múltiples máquinas.

4. Crear un playbook básico

Archivo despliegue.yml:

- name: Configurar servidores web
  hosts: web
  become: true

  tasks:
    - name: Instalar Apache
      apt:
        name: apache2
        state: present

    - name: Copiar archivo index.html
      copy:
        src: ./index.html
        dest: /var/www/html/index.html

    - name: Asegurar que el servicio está activo
      service:
        name: apache2
        state: started
        enabled: true

Ejecutar el playbook:

ansible-playbook despliegue.yml

5. Variables y roles

Variables en group_vars/web.yml:

puerto_http: 80
documento: index.html

Uso en playbooks:

port: "{{ puerto_http }}"
src: "./{{ documento }}"

→ Roles permiten separar tareas, handlers, templates y defaults por estructura modular.

6. Automatizar backups, auditorías o tareas personalizadas

Ejemplo: Playbook auditoria.yml

- name: Auditar acceso SSH
  hosts: all
  become: true

  tasks:
    - name: Extraer últimos accesos
      shell: last
      register: resultado

    - name: Guardar en log local
      local_action:
        copy content="{{ resultado.stdout }}"
        dest="./logs/{{ inventory_hostname }}_access.log"

→ Puede ejecutarse por cron, desde un CI/CD, o integrarse con Git.

7. Recomendaciones

• Usa --check para probar sin aplicar cambios
• Documenta bien los roles y variables
• Controla versiones con Git
• Usa ansible-vault para proteger contraseñas y secretos

Este capítulo aborda la protección integral del sistema Linux a través de tres pilares clave:

1. Seguridad de archivos
2. Seguridad de red
3. Auditoría y análisis

1. Seguridad de archivos

Protege el acceso local, el contenido sensible y la integridad del sistema de archivos.

Permisos y propietarios

# chmod 640 informe.txt             # Solo lectura para grupo, nada para otros
# chown luisgulo:luisgulo informe.txt       # Asignar dueño y grupo
# ls -l                             # Consultar permisos

Control avanzado con ACL (Access Control Lists)

# setfacl -m u:ana:rw informe.txt   # Permite a ana leer/escribir
# getfacl informe.txt               # Ver permisos extendidos

Cifrado de archivos y carpetas

Archivo individual con GPG:

$ gpg -c secreto.txt

Carpeta cifrada con encfs:

$ encfs ~/privada ~/privada_montada

Volumen cifrado con LUKS:

# cryptsetup luksFormat /dev/sdb1
# cryptsetup open /dev/sdb1 seguro
# mkfs.ext4 /dev/mapper/seguro
# mount /dev/mapper/seguro /mnt/seguro

Integridad y revisión de permisos peligrosos

# find / -type f -perm -o+w            # Archivos mundialmente escribibles
# find / -type f -perm -4000           # Archivos con setuid (potencialmente peligrosos)

2. Seguridad de red

Controla el acceso remoto, protege servicios expuestos y restringe comunicaciones no autorizadas.

Configuración segura de SSH

Modificar /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
AllowUsers luisgulo soporte

Aplicar cambios:

# systemctl restart sshd

Filtrado de IPs y puertos con iptables

Permitir solo una IP para SSH:

# iptables -A INPUT -p tcp --dport 22 -s 192.168.1.100 -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j DROP

Guardar reglas y restaurar:

# iptables-save > /etc/iptables/rules.v4
# iptables-restore < /etc/iptables/rules.v4

Restricción de servicios expuestos

Ver qué puertos están abiertos:

$ ss -tuln
$ netstat -tulnp

Escanear con nmap:

$ nmap -sS localhost

Limitar procesos con firewall y systemd:

# systemctl disable cups
# systemctl mask telnet

3. Auditoría y análisis

Detecta actividades sospechosas, registra eventos críticos y genera informes de seguridad.

Revisión de logs clave

$ tail -n 100 /var/log/auth.log          # Actividad de autenticación
$ journalctl -u sshd                     # Estado del servicio SSH
$ last                                   # Accesos recientes
$ lastlog                                # Última conexión por usuario

Uso de fail2ban para bloquear IPs

# apt install fail2ban
# systemctl enable fail2ban
# systemctl start fail2ban

Ver estado:

# fail2ban-client status sshd

Auditoría con auditd, auditctl, ausearch

Instalar sistema de auditoría:

# apt install auditd
# systemctl enable auditd
# systemctl start auditd

Ejemplo: registrar cambios en /etc/passwd:

# auditctl -w /etc/passwd -p wa -k passwd_watch

Buscar eventos relacionados:

# ausearch -k passwd_watch
# aureport --file

Generar resumen diario con cron:

Script: /usr/local/bin/reporte_audit.sh

#!/bin/bash
FECHA=$(date +%F)
aureport --summary > /var/log/audit/resumen_$FECHA.log

Agendar con cron:

$ crontab -e
0 1 * * * /usr/local/bin/reporte_audit.sh

Herramientas complementarias

chkrootkit, rkhunter, lynis:

# apt install chkrootkit rkhunter lynis
# chkrootkit
# rkhunter --check
# lynis audit system

Monitorización histórica con atop o PCP:

• atop: registros diarios por proceso
• PCP + pmchart: métricas por CPU, RAM, disco y red con visualización

Recomendaciones generales

• Desactiva servicios no utilizados
• Mantén el sistema y los paquetes actualizados
• Usa contraseñas fuertes y autenticación por clave pública
• Realiza backups periódicos y cifrados
• Asegura puertos abiertos y verifica con escaneos regulares
• Revisa logs automáticamente y configura alertas por anomalías

Seguridad avanzada con SELinux

SELinux es un sistema de control de acceso obligatorio (MAC) que refuerza la seguridad del kernel. En lugar de confiar únicamente en permisos tradicionales o usuarios, define reglas precisas sobre qué recursos puede usar cada proceso, usuario o servicio. Es comúnmente usado en distribuciones como Fedora, Red Hat y CentOS.

1. Verificación y modo de operación

$ getenforce          # Verifica modo actual (Enforcing, Permissive, Disabled)
$ sestatus            # Estado general de SELinux

Modos disponibles:

• Enforcing: bloquea acciones que violan políticas
• Permissive: solo registra violaciones, útil para diagnóstico
• Disabled: inactivo

Cambiar temporalmente:

# setenforce 0        # Permissive
# setenforce 1        # Enforcing

Cambiar de forma permanente en /etc/selinux/config:

SELINUX=enforcing

2. Políticas disponibles

$ sestatus | grep "Loaded policy"

Tipos:

• targeted: aplica a procesos seleccionados (predeterminada en la mayoría)
• strict: se aplica globalmente, mucho más restrictiva
• MLS: control por niveles de seguridad (usado en entornos gubernamentales)

3. Contextos de seguridad

Cada archivo, proceso, puerto o recurso tiene un contexto SELinux compuesto por:

usuario:rol:tipo:nivel

Ejemplo con archivos web:

$ ls -Z /var/www/html
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html

Modificación temporal del tipo:

# chcon -t httpd_sys_content_t index.html

Modificación permanente usando semanage:

# semanage fcontext -a -t httpd_sys_content_t '/web(/.*)?'
# restorecon -Rv /web

Reetiquetado de archivos según política:

# restorecon -Rv /var/www/html/

4. Análisis de errores y solución de conflictos

Consultar eventos bloqueados:

$ journalctl -xe | grep AVC
$ ausearch -m AVC

Interpretar causa:

# audit2why < /var/log/audit/audit.log

Generar política para permitir la acción bloqueada:

# audit2allow -a -M apache_excepcion
# semodule -i apache_excepcion.pp

Ejemplo: Apache no puede acceder a /datos/web

# semanage fcontext -a -t httpd_sys_content_t '/datos/web(/.*)?'
# restorecon -Rv /datos/web/

5. Control de puertos y servicios

Ver puertos y sus contextos:

$ semanage port -l | grep http

Agregar puerto alternativo para Apache:

# semanage port -a -t http_port_t -p tcp 8080

6. Etiquetado de procesos

Ver procesos con su contexto SELinux:

$ ps -eZ | grep nginx

Ejemplo de resultado:

system_u:system_r:httpd_t:s0 1234 ? 00:00:00 nginx

Significa que el proceso nginx está etiquetado como httpd_t.

7. Reglas personalizadas

Crear una política con nombre nginx_permit_rw:

# audit2allow -a -M nginx_permit_rw
# semodule -i nginx_permit_rw.pp

Listar políticas cargadas:

$ semodule -l

Eliminar una política:

# semodule -r nginx_permit_rw

8. Administración básica de SELinux

Instalar herramientas si no están presentes:

# dnf install policycoreutils policycoreutils-python-utils selinux-policy selinux-policy-targeted

Si usas Debian, SELinux requiere habilitación manual y reinicio:

# apt install selinux-basics selinux-policy-default auditd
# selinux-activate

9. Recomendaciones generales

• Evita desactivar SELinux: usa modo Permissive para resolver problemas sin sacrificar protección
• Aplica etiquetados correctos a carpetas web, logs, configuraciones y rutas personalizadas
• Usa audit2why y audit2allow para diagnosticar y corregir errores sin modificar permisos innecesarios
• Documenta tus módulos personalizados y mantén una copia de respaldo
• En contenedores Docker, usa opciones :Z o :z al montar volúmenes si SELinux está activo

En UK acaban de implementar la verificación de edad obligatoria para un montón de sitios y servicios online, y claro, la gente, a parte de usar VPN están encontrando diferentes formas de saltarse esta limitación, por ejemplo usando los personajes del videojuegos como Garry’s Mod o Death Stranding:

https://www.forbes.com/sites/paultassi/2025/07/31/the-uks-internet-age-verification-is-being-bypassed-by-death-stranding-2-garrys-mod

La entrada perro se publicó primero en Linux Hispano.

Comparto en el blog la respuesta de la defensora del oyente sobre el bloqueo a aplicaciones de terceros a los podcasts de RTVE y RNE. Spoiler: No son buenas noticias

Ayer mismo publiqué en el blog un artículo sobre mi experiencia a la hora de reproducir podcasts de la radio pública del estado español.

• https://victorhckinthefreeworld.com/2025/07/16/rtve-bloquea-sus-podcats-a-la-aplicacion-antennapod/

En el artículo describía cómo desde hace unos días o semanas, mi reproductor de podcasts en el móvil no podía reproducir los podcats públicos creados por un medio público y estatal como es Radio Naciona del España (RNE).

Y también comenté que había expresado mi queja a la defensora del oyente sobre el hecho de que desde el medio público se coartase de esa manera el acceso a su contenido (contenido público realizado con dinero público).

Pues bien, la defensora del oyente ha respondido, y la respuesta que ha dado (nada nuevo) no te va a gustar.

Primero comparto la queja que le envié:

Hola.
Desde hace un tiempo vengo comprobando que mi reproductor de podcasts en Android no funcionaba con los podcasts de RTVE. Estoy suscrito a unos cuantos, por ejemplo: El sótano de RNE3, Raíz de 5 de RNE5, y algunos otros. Pero mi reproductor funciona correctamente con otros podcasts, por ejemplo de la SER, y otros independientes.
Al principio lo achacaba a un problema de conexión o similar, después de comprobar varias cosas durante días, veo que parece ser que la web de RTVE rechaza los podcasts escuchados con cierta aplicación de software libre que es la que utilizo para escuchar mi colección de podcasts.
Es decir, RTVE, está en contra de la neutralidad de la red al coartar el contenido público usando ciertas herramientas. El medio público ofrece su contenido, pero con restricciones para ciertos usuarios. Pero no del todo, porque desde mi portátil sí puedo escuchar los podcats sin problema.
¿Hay alguna causa que justifique dicho comportamiento selectivo?

A continuación comparto la respuesta de la defensora del oyente a mi queja:

Gracias por escribirnos.

Lamentamos su malestar. Desde la Subdirección de Innovación y Productos Digitales de RTVE nos aportan la siguiente explicación sobre este asunto por el que nos han preguntado muchos usuarios como usted en esta Oficina de la Defensora:

"A partir de ahora, la descarga de audios solo está habilitada desde la aplicación oficial de RNE para garantizar la calidad, la correcta atribución del contenido y el cumplimiento de los derechos de autor y de difusión.
Permitir la descarga desde aplicaciones de terceros (no oficiales) dificultaría asegurar que los contenidos se distribuyan con la calidad y el contexto adecuados, además de poder vulnerar los acuerdos editoriales y de derechos que protegen tanto a los creadores como a la propia emisora.
Esta medida responde a dos motivos principales: por un lado, no podemos conocer ni contabilizar el uso real de nuestros contenidos en esas plataformas, lo que dificulta ofrecer un servicio de calidad y valorar correctamente el alcance. Por otro, el consumo a través de terceros genera un coste directo para RNE (especialmente en términos de CDN), sin ningún beneficio asociado ni control sobre la experiencia del usuario.
Por ello, para garantizar un servicio sostenible y de calidad, los contenidos solo estarán disponibles para descarga y escucha dentro de RNE Audio y en aquellas plataformas con las que exista un acuerdo".
Le agradecemos su interés y participación.
Reciba un cordial saludo.

Lo que entiendo es que a partir de ahora RNE únicamente permitirá el acceso a los podcats de su programación desde la aplicación oficial de RNE.

El contenido es público y pagado con dinero público (vuelvo a recalcar ese hecho) pero sólo podremos hacerlo desde su aplicación desarrollada con dinero público y que no es software libre y solo está disponible en plataformas privativas (nada de f-droid).

También entiendo que igual que en mi portátil por medio de Amarok, estaba suscrito a los podcasts para oirlos en mi equipo, tampoco esto será posible a partir de ahora, teniendo que acceder a su web y reproducirlos desde su reproductor en su página.

Es totalmente injusto que un medio público utilice un medio de difusión público como son los podcats y lo encierre no permitiendo el libre acceso a su contenido.

Las excusas son el poder tener un control de las descargas, acuerdos editoriales, derechos de autor, coste extra para RNE.

¿De verdad con una herramienta de terceros no tienen un acceso al número de descargas de cada audio para tener una trazabilidad de lo más escuchado?

Sobre las demás excusas para imponer ese recorte a la hora de difundir su contenido no tengo más comentarios, con los derechos de autor hemos topado. De acuerdo que hay que proteger esos derechos de autor, pero me temo que más que querer proteger al autor, lo que quieren es proteger a quien gana dinero con el contenido creado con el autor, que no siempre es bien pagado.

Por tanto, ya lo sabes. A partir de ahora parece ser que sólo podrás escuchar sus audios desde la aplicación oficial, su web o aquellas aplicaciones con las que hayan llegado a un acuerdo.

¿Quizás pronto su programación en directo por radio en FM sólo estará disponible para los receptores de radio que ellos aprueben y con los que lleguen a un acuerdo? ¿qué más restricciones tiene en mente un medio público a la hora de difundir su contenido? Lo veremos en próximas entregas.

Si vuestra aplicación de podcats también se ha visto afectada por esta restricción, que parece ser que pronto serán todas, menos las aprobadas por el ente, podéis también enviar una queja y ver si el medio cambia de opinión…

• https://www.rtve.es/rtve-responde/participacion/

Este apartado te enseña cómo visualizar registros, filtrarlos por fecha, servicio o palabra clave, usar herramientas como journalctl, logrotate, rsyslog, y cómo automatizar auditorías sencillas.

¿Dónde se guardan los logs?

En sistemas Linux existen dos grandes fuentes de logs:

• journalctl (con systemd): /run/log/journal/ o /var/log/journal/
• logs tradicionales: archivos en /var/log/

Comando: journalctl

Usado en sistemas con systemd para consultar el journal (registro unificado).

Sintaxis Básica

$ journalctl
$ journalctl -xe                  # Últimos errores detallados

Sintaxis Avanzada

$ journalctl -u nginx             # Logs del servicio nginx
$ journalctl --since "1 hour ago"
$ journalctl -p 3                 # Solo prioridad: error
$ journalctl -b                   # Desde último arranque

Logs en /var/log/

Comandos para filtrar logs

$ grep "error" /var/log/syslog
$ tail -n 50 /var/log/auth.log
$ less /var/log/messages
$ awk '/ssh/' /var/log/auth.log

Rotación de logs con logrotate

Evita que los archivos de log crezcan indefinidamente.

Configuración:

• Directorios: /etc/logrotate.conf y /etc/logrotate.d/

Parámetros clave:

weekly           # Rotación semanal
rotate 4         # Guarda 4 versiones antiguas
compress         # Comprime con gzip
notifempty       # No rota si está vacío

Forzar rotación manual:

# logrotate -f /etc/logrotate.conf

rsyslog (sistema tradicional de logging)

Permite redirigir, filtrar y enviar logs local o remotamente.

Configuración básica:

module(load="imuxsock")       # Recibe mensajes locales
module(load="imklog")         # Mensajes del kernel

→ Archivos de configuración: /etc/rsyslog.conf, /etc/rsyslog.d/*.conf

Auditoría de actividad

Ver quién usó sudo

$ grep "sudo" /var/log/auth.log

Ver últimos accesos

$ last
$ lastlog

Crear logs personalizados desde scripts

#!/bin/bash
echo "$(date): Inicio de respaldo" >> /var/log/milog.log
rsync -a /datos /backup
echo "$(date): Fin de respaldo" >> /var/log/milog.log

Auditoría avanzada con auditd, ausearch y auditctl

El paquete auditd es el subsistema de auditoría de Linux. Permite registrar operaciones sensibles como cambios de archivos, ejecuciones, accesos fallidos, etc.

auditctl: definir reglas de auditoría

Establece qué eventos deben registrarse.

Ejemplo: auditar apertura de un archivo específico:

# auditctl -w /etc/passwd -p wa -k passwd_watch

• -w: archivo a monitorear
• -p: permisos (w=write, a=attr change, r=read, x=execute)
• -k: etiqueta para búsqueda posterior

Otras reglas útiles:

# auditctl -a always,exit -F arch=b64 -S execve -k ejecuciones
# auditctl -a always,exit -F uid=1000 -F auid>=1000 -k usuario_luisgulo

ausearch: buscar en los logs de auditoría

Permite filtrar eventos registrados por auditd.

Ejemplos:

# ausearch -k passwd_watch
# ausearch -ts today -k ejecuciones
# ausearch -i --user luisgulo

• -k: filtra por etiqueta
• -ts: fecha de inicio (today, now, 2024-10-25)
• -i: salida legible

Generar reportes automáticos

Usando aureport

Obtiene resúmenes de auditoría:

# aureport --summary
# aureport --login
# aureport --file --start today --end now

Programar con cron

Ejemplo de script /usr/local/bin/reporte_audit.sh:

#!/bin/bash
FECHA=$(date +%Y-%m-%d)
aureport --summary > /var/log/audit/resumen_$FECHA.log

Agregar a cron diario:

$ crontab -e
0 1 * * * /usr/local/bin/reporte_audit.sh

Equivalentes modernos a KSar para analizar los logs de SAR

KSar era una herramienta gráfica que usé bastante para visualizar los logs de sysstat/sar.

Ya no se mantiene, y hacerla funcionar es algo complicado por la versión de Java que usa y el formato de datos que permite leer.

Hay otras alternativas más actuales:

1. Grafana + Prometheus + node_exporter

• node_exporter recolecta métricas similares a SAR (CPU, RAM, disco)
• Prometheus almacena datos con historial
• Grafana ofrece dashboards para detectar sobrecarga y cuellos de botella

→ Puedes replicar gráficamente lo que hacía KSar, con paneles de carga, I/O y red.

2. Performance Co-Pilot (PCP) + pmchart

• Herramienta avanzada para recolectar y graficar métricas en tiempo real
• pmchart: visor gráfico interactivo (similar a KSar)
• Compatible con SAR y puede importar sus datos

# apt install pcp pcp-gui
$ pmchart &

3. atop + atopsar

• atop: herramienta de monitorización en tiempo real y en registros
• atopsar: genera informes históricos, similar a KSar

$ atopsar -r /var/log/atop/atop_2025xxxx -A

4. Glances con exportación a InfluxDB

• Exporta métricas a bases de datos
• Grafana puede visualizar esos datos

Ejemplo completo: Monitorización con Performance Co-Pilot (PCP)

1. Instalar PCP y visor gráfico

# apt install pcp pcp-gui

En Arch:

# pacman -S pcp

2. Activar recolección continua

# systemctl enable pmcd
# systemctl start pmcd
# systemctl enable pmlogger
# systemctl start pmlogger

Esto inicia la recolección en /var/log/pcp/pmlogger/.

3. Esperar varios días

Durante este tiempo se guardan datos como CPU, RAM, disco, red…

4. Visualizar con pmchart (modo gráfico)

$ pmchart &

→ Selecciona métricas como kernel.all.cpu.user o mem.physmem.

Puedes elegir el rango de fechas desde los menús.

5. Consultar logs desde consola

$ pmlogsummary /var/log/pcp/pmlogger/<host>/YYYYMMDD HH:MM HH:MM

También puedes exportar métricas específicas:

$ pmlogextract -s "2 day ago" -e "now" /var/log/pcp/pmlogger/<host>/ 

Ejemplo completo: Monitorización con atop

1. Instalar atop

# apt install atop

En Fedora:

# dnf install atop

2. Activar servicio automático

# systemctl enable atop
# systemctl start atop

Esto genera archivos como:

/var/log/atop/atop_YYYYMMDD

→ Guarda 10 minutos de actividad por defecto cada hora.

3. Visualizar registros anteriores

$ atop -r /var/log/atop/atop_20250714

→ Usa flechas y t, c, m, d para ver CPU, memoria, disco…

4. Exportar informe CSV

$ atopsar -r /var/log/atop/atop_20250714 -A > informe.csv

→ Puedes abrirlo con hojas de cálculo o importar a dashboards.

5. Ver resumen filtrado por recurso

$ atopsar -r /var/log/atop/atop_20250714 -c        # CPU
$ atopsar -r /var/log/atop/atop_20250714 -m        # Memoria
$ atopsar -r /var/log/atop/atop_20250714 -d        # Disco

Tabla Comparativa: PCP vs atop

Una tabla comparativa entre Performance Co-Pilot (PCP) y atop, organizada por tipo de métricas, visualización y nivel de detalle.

Para ayudarte a elegir la herramienta adecuada según tus necesidades de monitorización, análisis histórico o investigación de cuellos de botella.

Resumen rápido:

• Usa PCP si buscas recolectar y visualizar datos en entornos de larga duración, integrarlo con dashboards modernos o crear reportes centralizados.
• Escoge atop si necesitas investigar problemas inmediatos, analizar procesos específicos y trabajar en terminal con alta interactividad.

Los usuarios de AntennaPod no podemos acceder a los podcats públicos de la emisora pública para escuchar los podcasts de RTVE

AntennaPod es la aplicación de software libre que utilizo en mi dispositivo Android para la gestión de los podcats que escucho y a los que estoy suscrito. Ofrece una interfaz cómoda y las funcionalidades que necesito para escuchar mis podcats.

Pero desde hace un tiempo, algunos podcasts no los reproduce mientras que con otros sigue funcionando correctamente. Al principio creía que podría deberse a un problema con la aplicación, con la red, con mi dispositivos, etc. Pero al indagar un poco más, veo que los podcasts que no reproducen son los de RTVE y que no me ha pasado a mí solo…

Después de un tiempo de desconcierto y probar distintas cosas, veo por la red un issue en el repo de AntennaPod en GitHub que otra persona menciona ese mismo problema y que en el foro de usuarios de AntennaPod son más las personas afectadas que comentan los mismos problemas.

Parece ser que RTVE, la televisión y radio públicas del estado español, ha bloqueado el user agent de AntennaPod a la hora de acceder a su contenido. Contenido de un medio público que ofrece de manera libre y gratuita desde su web u otros medios de escucha.

Desde la línea de comandos se puede comprobar ese bloqueo al user agent de AntennaPod mediante curl.

Así el contenido no se descarga:

curl -L -A "AntennaPod/3.1.0" "https://ztnr.rtve.es/ztnr/16647613.mp3" > descarga.mp3

Así sí se descarga sin problemas:

curl -L -A "firefox" "https://ztnr.rtve.es/ztnr/16647613.mp3" > descarga.mp3

De esta manera RTVE está en contra de la neutralidad de la red, algo que en un medio estatal y público es bastante lamentable.

Hay usuarios de AntennaPod que han enviado una queja a la defesora del oyente de RTVE y la contestación más o menos fue que: RTVE desea que los accesos a sus contenidos se hagan desde las aplicaciones oficiales, para así tener una contabilidad del material más escuchado, y todo para mejorar el servicio, por supuesto.

Una respuesta un poco sin sentido, porque en mi portátil y desde mi reproductor multimedia, Amarok en mi caso, también estoy suscrito a algunos podcasts de RTVE y puedo acceder sin problemas, o directamente descargarlos desde la línea de comandos, etc…

Para que cuente, yo también he enviado mi queja a la defensora del oyente así como a algún programa de radio que sigo en podcasts (aunque ha sido bastante difícil encontrar un medio de contacto válido que no sean redes asociales privativas).

En definitiva una medida que deja fuera de acceso a contenido público de RTVE a muchas personas que utilizamos AntennaPod.

Podría asemejarse al hecho de que para ver su contenido en la televisión o escuchar su radio, solo fuera posible con determinado modelo de televisión o una marca específica de radio. Espero que desde RTVE cambien esa arbitrariedad a la hora de escuchar su contenido.

Enlaces de interés

• https://antennapod.org/es/
• https://github.com/AntennaPod/AntennaPod/issues/7864
• https://forum.antennapod.org/t/rne-podcasts-not-working/6849