Publicación de Ovidio Andrade

Os comparto mi pequeña y maravillosa aventura con mi pequeño server. Tengo un pequeño portatil con un opensuse actuando como mi servidor, en el tengo unas cuantas automatizaciones con cron y el otro día detecte que dejaba de funcionar. Tras investigar, descubrí que podía ajustar el servicio cron para evitar su terminación prematura mediante la configuración del OOM Score a -1000. Sin embargo, esto desencadenó una serie de problemas más complejos. El servidor comenzó a experimentar una latencia significativa y, tras un análisis detallado, identifiqué que el problema provenía de un comando grep dentro del crawler que procesaba un archivo masivo de URLs, consumiendo prácticamente todos los recursos disponibles. La situación se complicó cuando intenté reiniciar el sistema, ya que había configurado el script para ejecutarse automáticamente durante el arranque. Necesitaba acceder al sistema de archivos para modificar el cronjob, lo que me llevó a explorar diferentes soluciones: 1. Intenté bootear con Ubuntu Live (mediante Ventoy) 2. Ejecuté un memtest para verificar la integridad de la memoria 3. Probé con una ISO de Arch Linux 4. Intenté con Kali Linux Finalmente, la solución más simple resultó ser la más efectiva: utilizar el modo de recuperación de OpenSUSE, que me permitió acceder a los archivos y modificar la configuración problemática del cronjob. Aprendizajes clave de esta experiencia: 1. Las soluciones más simples suelen ser las más efectivas 2. Es crucial tener precaución con los cronjobs, especialmente los que se ejecutan durante el arranque 3. El comando grep en archivos extensos puede consumir recursos significativos al cargar el archivo en memoria 4. Es fundamental asegurarse de que el hardware puede manejar las tareas asignadas 5. La importancia de mantener copias de seguridad regulares Como resultado de esta experiencia, he decidido migrar a CentOS, una distribución más ligera y mejor adaptada a mis necesidades actuales, especialmente considerando que no requiero interfaz gráfica. #Linux #Debugging #SysAdmin #ServerManagement ¿Que habrían intentado vosotros?

𝗗𝗲𝗷𝗮 𝗱𝗲 𝗲𝗷𝗲𝗰𝘂𝘁𝗮𝗿 𝘁𝘂𝘀 𝘀𝗰𝗿𝗶𝗽𝘁𝘀 𝗲𝗻 𝗹𝗼𝗰𝗮𝗹. Si trabajas con software o datos, tarde o temprano acabarás utilizando un servidor. 🖥️ La razón es simple: no puedes ejecutar algo serio en local. ❌ Lo he hecho, y créeme, es una experiencia de risas. Imagina el dolor de tener que programar el schedule de un script en tu Windows/Mac local. Cada vez que algo falla, tienes que ir físicamente al ordenador, arreglarlo y debugearlo. El CI/CD que puedas implementar va a ser curioso. Lo peor es que, en algunas empresas serias, aún se usan programitas y scripts locales. Es horrible. 😖 Por eso, te recomiendo que empieces a aprender Linux. 🐧💡 Aquí te dejo unos comandos para que empiezes a jugar. #Linux #Server #AWS #SQL #Python #devops

💻 Siempre que hablo con personas que no están en el mundo de IT, me mencionan lo agotador que les parece programar, o que se les hace pesado lidiar con tantos problemas técnicos. 🤷 Y la verdad, no puedo contradecirles nada… ⚙️ Hace poco me enfrenté a un desafío con Oracle Linux 8.10 y la instalación de Oracle DB 23c. 📋 Tuve una serie de inconvenientes: ✔️ El hostname estaba mal escrito, ✔️ El DHCP estaba mal configurado, ✔️ Errores muy extraños en el archivo listener.ora, ✔️ El sistema me tiraba falso error tnslsnr, ✔️ No había relación entre los errores y los logs, ✔️ Y 10 más. ☕ Después de pasar dos horas frente a la pantalla, café y Redbull zero, y estar concentrado a full en resolverlo, logré configurarlo correctamente. El sistema quedó sin problemas y funcionando como se esperaba. No me tiró error alguno ni nada por el estilo. 💭 Al final todo esto me hizo reflexionar sobre algo importante: si no disfrutas lo que haces, cualquier tarea, por más pequeña que sea, se vuelve una pérdida de tiempo. 💡 Sígueme en LinkedIn para seguir leyendo más posts como este, ya que es uno más de una serie de posts, artículos y guías sobre proyectos, tecnologías y más. #IT #Tecnología #Programación #Desarrollo #Oracle #Linux #ProblemasTécnicos #DBA #Soluciones #AdministraciónDeSistemas #Reflexión #PasiónPorLaTecnología #Aprendizaje #ResoluciónDeProblemas #SysAdmin

🔵 Cómo crear un volcado de procesos en GNU/Linux y buscar "leaks" de información Hacía tiempo que no pasaba por aquí para poder escribir sobre inquietudes tecnológicas o pequeñas pruebas de concepto que pueden surgir en el día a día. Todos conocemos diferentes herramientas de volcado de procesos de memoria. Por ejemplo, Volatility, que es una de mis favoritas por todo lo que ofrece y aporta en el análisis de un volcado de memoria. Volatility no es la única herramienta que se tiene, se tienen otras muchas que aportan en mayor o menor medida diferentes posibilidades, otra opción es gcore. Revisando un poco lo que ofrece /proc en los sistemas GNU/Linux se pueden sacar muchas cosas interesantes. Entre ellas, se puede leer directamente de la memoria de un proceso. Casi como si fuera un fichero. No exactamente como en un fichero, pero le estuve dando vueltas. Al final es una forma sencilla de poder leer qué información hay dentro de un proceso. Se sabe que, en un proceso, hay elementos que están compartidos con otros procesos. Se sabe que hay páginas de memoria que tienen ciertos permisos y otras otros. Aquí es donde hablamos de lectura, escritura, ejecución. Decidí revisar más sobre este tema y preparar una pequeña prueba de concepto con Bash (un ejemplo de lo que se puede hacer con este lenguaje en GNU/Linux). Gestión del memoria en sistemas GNU/Linux Antes de hablar de la prueba de concepto, vamos a pararos a estudiar un poco sobre /proc y lo que ofrece en términos de información sobre los procesos. Sabemos que /proc es un directorio especial, ya que almacena información sobre elementos volátiles (como es la memoria). Lo primero que nos puede llamar la atención es que si hago un ls sobre el directorio podremos visualizar un montón de “carpetas” con números. Estas carpetas son el ID de los procesos que hay en ejecución en la máquina. ¿Qué información se puede sacar de la memoria de un proceso? Cualquier cosa que esté ahí y no esté protegida (y mucha no lo estará). Para esta pequeña prueba de concepto vamos a abrir un mousepad (el bloc de notas al uso en GNU/Linux) y vamos a introducir algo de texto. Todo lo que se escribe debe estar en memoria. De eso no hay duda. Hay que recordar que la memoria es un elemento volátil, por lo que puede pasar que esté, pero con el tiempo no lo esté. En este caso, el proceso del mousepad recibe el PID 2477 por parte del sistema operativo. Vamos a acceder al directorio de /proc/2477, que es el que corresponde al proceso que hemos ejecutado. Aquí encontramos bastante información interesante sobre el proceso, que nos daría para otro artículo, pero vamos a centrarnos en mem y en maps. El fichero mem nos dará acceso directo a la lectura del proceso en memoria, en crudo. 👇 https://lnkd.in/dhWvgnHk

systemd presenta run0, un «clon» de sudo para reemplazar a sudo. controvertido debido a que es capaz de implementar una gran variedad de componentes de distinto tipo. Una de las cosas que vendrán en el próximo lanzamiento mayor del framework es run0, que es en base un clon de sudo para systemd. run0 ha sido anunciado por Lennart Poettering, creador de systemd y actual empleado de Microsoft, en un hilo que ha publicado en la red social Mastodon. El desarrollador reconoce la utilidad del actual sudo que se encuentra en la mayoría de las distribuciones Linux, pero que “tiene serios problemas. Es un binario SUID relativamente grande, es decir, un código privilegiado que los usuarios sin privilegios pueden invocar desde su propio contexto. Tiene un lenguaje de configuración complicado, complementos cargables (¡ldap!), coincidencias de nombres de host, etc”. A todo eso se suman otros factores como una superficie de ataque grande. https://lnkd.in/e5zqU2UE

Zabbix es una de las herramientas más poderosas y versátiles para el monitoreo de infraestructuras, redes, aplicaciones y sistemas en tiempo real. Este artículo te guiará en la instalación de Zabbix en Ubuntu... #Zabbix #Infraestructura #Redes #NOC #Monitoreo #Alertas

𝗘𝗿𝗿𝗼𝗿 𝗮𝗹 𝗲𝘅𝘁𝗿𝗮𝗲𝗿 𝘂𝗻 𝗮𝗿𝗰𝗵𝗶𝘃𝗼 .𝗥𝗔𝗥 𝗱𝗲𝘀𝗱𝗲 𝗣𝗹𝗲𝘀𝗸 Buenas Wecindario, si alguna vez has intentado extraer un archivo RAR desde el administrador de archivos de Plesk y te has encontrado con el siguiente mensaje de error: Unable to extract /httpdocs/File.rar: To extract RAR archives, install UnRAR, no estás solo. Este error ocurre cuando la herramienta UnRAR no está instalada en el servidor. 🔗 https://lnkd.in/dEY-8rdH . .⁣⁣ .⁣⁣ ⁣⁣ #hoswedaje #hosting #web #servidores #vpn #webmasters #blog #wp #wordpress #wordpressdesign #Plesk #MySQL #proteccion #MySQLTunner #web #usuarios

🔵 systemd presenta run0, un «clon» de sudo para reemplazar a sudo. 🐧 systemd se ha convertido en el marco estándar empleado por la mayoría de las grandes distribuciones y también se ha consolidado como un software controvertido debido a que es capaz de implementar una gran variedad de componentes de distinto tipo. Una de las cosas que vendrán en el próximo lanzamiento mayor del framework es run0, que es en base un clon de sudo para systemd. run0 ha sido anunciado por Lennart Poettering, creador de systemd y actual empleado de Microsoft, en un hilo que ha publicado en la red social Mastodon. El desarrollador reconoce la utilidad del actual sudo que se encuentra en la mayoría de las distribuciones Linux, pero que “tiene serios problemas. Es un binario SUID relativamente grande, es decir, un código privilegiado que los usuarios sin privilegios pueden invocar desde su propio contexto. Tiene un lenguaje de configuración complicado, complementos cargables (¡ldap!), coincidencias de nombres de host, etc”. A todo eso se suman otros factores como una superficie de ataque grande. La presunta complejidad de sudo ha hecho que algunos hayan decidido desarrollar alternativas, de entre las que destaca doas, que tiene su origen en OpenBSD y destaca por simplificar mucho la herramienta y reducir la superficie de ataque a la vez que no dejar de ser un binario SUID. Con el fin de evitar o al menos minimizar los presuntos inconvenientes de sudo, Lennart Poettering ha anunciado run0 de la siguiente manera: “Hay una nueva herramienta en systemd llamada ‘run0’. De hecho, no es una herramienta nueva, sino que es la herramienta ‘systemd-run’ que existe desde hace mucho tiempo, pero cuando se invoca con el nombre ‘run0’ (a través de un enlace simbólico) se comporta de manera muy parecida a un clon de sudo con una diferencia clave: ‘no’ es SUID. En lugar de eso, simplemente le pide al administrador de servicios que invoque un comando o shell bajo el UID del usuario objetivo. Asigna un nuevo PTY para eso y luego transfiere datos de un lado a otro del TTY de origen y este PTY.” “En otras palabras: el comando de destino se invoca en un contexto de ejecución aislado, recién bifurcado del PID 1, sin heredar ningún contexto del cliente (bueno, es cierto que ‘propagamos’ $TERM, pero esa es una excepción explícita, es decir, está en la lista de permitidos en lugar de en la lista de denegados). Se podría decir que ‘run0’ está más cerca del comportamiento de ‘ssh’ que de ‘sudo’ en muchos sentidos. Excepto que no se preocupa por el cifrado o la autenticación criptográfica, la administración de claves y demás, sino que depende de los mecanismos de identificación locales del kernel.” “Al aislar los contextos y los recursos del cliente y el objetivo, eliminamos por completo otras clases de ataques. La herramienta también es mucho más divertida de usar que sudo.