{"id":1389,"date":"2026-08-27T12:24:45","date_gmt":"2026-08-27T18:24:45","guid":{"rendered":"https:\/\/folken-it.com\/?p=1389"},"modified":"2026-08-27T12:29:27","modified_gmt":"2026-08-27T18:29:27","slug":"25-comandos-linux-esenciales-para-soporte-de-aplicaciones","status":"publish","type":"post","link":"https:\/\/folken-it.com\/?p=1389","title":{"rendered":"25 comandos Linux esenciales para Soporte de Aplicaciones"},"content":{"rendered":"\n

Cuando trabajas como Application Support Engineer<\/strong>, Linux se convierte en una de las herramientas m\u00e1s importantes para investigar incidentes en producci\u00f3n ya que aqu\u00ed es donde la magia se crea.<\/p>\n\n\n\n

Un problema puede comenzar con un mensaje tan sencillo como:<\/p>\n\n\n\n

\n

“La aplicaci\u00f3n est\u00e1 lenta.”<\/em><\/p>\n<\/blockquote>\n\n\n\n

Pero detr\u00e1s de esa alerta puede existir un filesystem lleno, falta de memoria, un proceso Java consumiendo CPU, problemas de conectividad, errores en logs, certificados vencidos o simplemente un servicio que dej\u00f3 de responder.<\/p>\n\n\n\n

Por eso, estos son algunos de los comandos Linux que considero m\u00e1s \u00fatiles en la operaci\u00f3n diaria de soporte L3<\/strong>.<\/p>\n\n\n\n

\n\n\n\n

1. Verificar el espacio disponible: df<\/code><\/h2>\n\n\n\n

Uno de los primeros comandos que utilizo cuando existe una alerta de filesystem es:<\/p>\n\n\n\n

df -h<\/code><\/pre>\n\n\n\n
Permite identificar r\u00e1pidamente particiones con poco espacio disponible.<\/p>\n\n\n\n
Tambi\u00e9n puedes revisar un filesystem espec\u00edfico:<\/p>\n\n\n\n
df -h \/opt\ndf -h \/var\ndf -h \/tmp<\/code><\/pre>\n\n\n\n
Una partici\u00f3n al 100% puede provocar que una aplicaci\u00f3n no pueda generar logs, archivos temporales o incluso iniciar correctamente.<\/p>\n\n\n\n
\n\n\n\n
2. Encontrar qu\u00e9 directorios consumen m\u00e1s espacio: du<\/code><\/h2>\n\n\n\n
Despu\u00e9s de encontrar un filesystem lleno, necesitamos saber qu\u00e9 est\u00e1 consumiendo el espacio<\/strong>.<\/p>\n\n\n\n
du -sh *<\/code><\/pre>\n\n\n\n
Para ordenar los directorios por tama\u00f1o:<\/p>\n\n\n\n
du -sh * | sort -h<\/code><\/pre>\n\n\n\n
Otra opci\u00f3n muy \u00fatil:<\/p>\n\n\n\n
du -x \/var | sort -n | tail -20<\/code><\/pre>\n\n\n\n
Esto ayuda a localizar logs, dumps, temporales o archivos antiguos que est\u00e1n consumiendo almacenamiento.<\/p>\n\n\n\n
\n\n\n\n
3. Encontrar archivos: find<\/code><\/h2>\n\n\n\n
find<\/code> es indispensable para investigar servidores.<\/p>\n\n\n\n
Buscar archivos .log<\/code>:<\/p>\n\n\n\n
find \/opt -type f -name \"*.log\"<\/code><\/pre>\n\n\n\n
Buscar archivos mayores a 1 GB:<\/p>\n\n\n\n
find \/ -type f -size +1G 2>\/dev\/null<\/code><\/pre>\n\n\n\n
Buscar archivos modificados durante las \u00faltimas 24 horas:<\/p>\n\n\n\n
find \/opt\/app -type f -mtime -1<\/code><\/pre>\n\n\n\n
Buscar archivos modificados durante los \u00faltimos 30 minutos:<\/p>\n\n\n\n
find \/opt\/app -type f -mmin -30<\/code><\/pre>\n\n\n\n
\n\n\n\n
4. Investigar logs con grep<\/code><\/h2>\n\n\n\n
Probablemente uno de los comandos m\u00e1s utilizados en soporte de aplicaciones.<\/p>\n\n\n\n
Buscar errores:<\/p>\n\n\n\n
grep -i \"error\" application.log<\/code><\/pre>\n\n\n\n
Buscar excepciones Java:<\/p>\n\n\n\n
grep -i \"exception\" application.log<\/code><\/pre>\n\n\n\n
Buscar m\u00faltiples patrones:<\/p>\n\n\n\n
grep -Ei \"error|exception|failed|critical\" application.log<\/code><\/pre>\n\n\n\n
Mostrar el n\u00famero de l\u00ednea:<\/p>\n\n\n\n
grep -in \"error\" application.log<\/code><\/pre>\n\n\n\n
\n\n\n\n
5. Analizar archivos con less<\/code><\/h2>\n\n\n\n
Cuando un log tiene cientos de MB o varios GB, abrirlo con un editor no siempre es buena idea.<\/p>\n\n\n\n
less application.log<\/code><\/pre>\n\n\n\n
Dentro de less<\/code> podemos buscar:<\/p>\n\n\n\n
\/error<\/code><\/pre>\n\n\n\n
Siguiente coincidencia:<\/p>\n\n\n\n
n<\/code><\/pre>\n\n\n\n
Coincidencia anterior:<\/p>\n\n\n\n
N<\/code><\/pre>\n\n\n\n
Salir:<\/p>\n\n\n\n
q<\/code><\/pre>\n\n\n\n
\n\n\n\n
6. Monitorear logs en tiempo real con tail<\/code><\/h2>\n\n\n\n
Para observar lo que est\u00e1 haciendo una aplicaci\u00f3n:<\/p>\n\n\n\n
tail -f application.log<\/code><\/pre>\n\n\n\n
Mostrar las \u00faltimas 100 l\u00edneas:<\/p>\n\n\n\n
tail -100 application.log<\/code><\/pre>\n\n\n\n
Combinarlo con grep<\/code>:<\/p>\n\n\n\n
tail -f application.log | grep -i error<\/code><\/pre>\n\n\n\n
Este comando resulta especialmente \u00fatil durante deployments, restarts y troubleshooting en producci\u00f3n<\/strong>.<\/p>\n\n\n\n
\n\n\n\n
7. Revisar procesos con ps<\/code><\/h2>\n\n\n\n
Para verificar si una aplicaci\u00f3n Java est\u00e1 ejecut\u00e1ndose:<\/p>\n\n\n\n
ps -ef | grep java<\/code><\/pre>\n\n\n\n
Buscar WebLogic:<\/p>\n\n\n\n
ps -ef | grep -i weblogic<\/code><\/pre>\n\n\n\n
Buscar Tomcat:<\/p>\n\n\n\n
ps -ef | grep -i tomcat<\/code><\/pre>\n\n\n\n
Una combinaci\u00f3n que utilizo frecuentemente es:<\/p>\n\n\n\n
ps -ef | grep java | grep -v grep<\/code><\/pre>\n\n\n\n
\n\n\n\n
8. Analizar CPU y memoria con top<\/code><\/h2>\n\n\n\n
Cuando recibimos un incidente indicando que “la aplicaci\u00f3n est\u00e1 lenta”<\/em>, uno de los primeros pasos es revisar los recursos del servidor.<\/p>\n\n\n\n
top<\/code><\/pre>\n\n\n\n
Aqu\u00ed podemos observar:<\/p>\n\n\n\n
    \n
  • CPU utilizada<\/li>\n\n\n\n
  • memoria<\/li>\n\n\n\n
  • load average<\/li>\n\n\n\n
  • procesos<\/li>\n\n\n\n
  • PID<\/li>\n\n\n\n
  • tiempo de CPU<\/li>\n<\/ul>\n\n\n\n
    Tambi\u00e9n podemos analizar un proceso espec\u00edfico:<\/p>\n\n\n\n
    top -p PID<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    9. Revisar memoria con free<\/code><\/h2>\n\n\n\n
    Para verificar r\u00e1pidamente la memoria del servidor:<\/p>\n\n\n\n
    free -h<\/code><\/pre>\n\n\n\n
    Nos permite revisar memoria total, utilizada, disponible y swap.<\/p>\n\n\n\n
    Es particularmente \u00fatil cuando investigamos problemas relacionados con aplicaciones Java.<\/p>\n\n\n\n
    \n\n\n\n
    10. Identificar puertos abiertos con ss<\/code><\/h2>\n\n\n\n
    Una aplicaci\u00f3n puede estar ejecut\u00e1ndose pero no estar escuchando en el puerto esperado.<\/p>\n\n\n\n
    ss -lntp<\/code><\/pre>\n\n\n\n
    Buscar un puerto espec\u00edfico:<\/p>\n\n\n\n
    ss -lntp | grep 7001<\/code><\/pre>\n\n\n\n
    Por ejemplo, si esperamos que WebLogic escuche en el puerto 7001<\/code>, este comando permite comprobarlo r\u00e1pidamente.<\/p>\n\n\n\n
    En servidores antiguos tambi\u00e9n podemos encontrar:<\/p>\n\n\n\n
    netstat -lntp<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    11. Probar conectividad con curl<\/code><\/h2>\n\n\n\n
    En soporte de aplicaciones modernas, curl<\/code> es indispensable para probar APIs y servicios HTTP.<\/p>\n\n\n\n
    curl https:\/\/server\/application<\/code><\/pre>\n\n\n\n
    Mostrar headers:<\/p>\n\n\n\n
    curl -I https:\/\/server\/application<\/code><\/pre>\n\n\n\n
    Mostrar informaci\u00f3n detallada de la conexi\u00f3n:<\/p>\n\n\n\n
    curl -v https:\/\/server\/application<\/code><\/pre>\n\n\n\n
    Probar una API:<\/p>\n\n\n\n
    curl -X GET https:\/\/api.example.com\/status<\/code><\/pre>\n\n\n\n
    Adem\u00e1s de HTTP, curl -v<\/code> puede proporcionar informaci\u00f3n muy valiosa durante troubleshooting de TLS, certificados, proxies y APIs REST<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    12. Probar DNS con nslookup<\/code> y dig<\/code><\/h2>\n\n\n\n
    Muchos problemas aparentemente relacionados con aplicaciones terminan siendo problemas de resoluci\u00f3n DNS.<\/p>\n\n\n\n
    nslookup server.example.com<\/code><\/pre>\n\n\n\n
    Tambi\u00e9n podemos utilizar:<\/p>\n\n\n\n
    dig server.example.com<\/code><\/pre>\n\n\n\n
    Una prueba r\u00e1pida:<\/p>\n\n\n\n
    dig +short server.example.com<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    13. Probar conectividad hacia un puerto<\/h2>\n\n\n\n
    Para verificar si un servidor remoto acepta conexiones:<\/p>\n\n\n\n
    nc -vz server.example.com 443<\/code><\/pre>\n\n\n\n
    Otro ejemplo:<\/p>\n\n\n\n
    nc -vz database.example.com 1521<\/code><\/pre>\n\n\n\n
    Esto ayuda a diferenciar r\u00e1pidamente entre un problema de aplicaci\u00f3n y uno de red, firewall o conectividad<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    14. Revisar archivos abiertos con lsof<\/code><\/h2>\n\n\n\n
    Para saber qu\u00e9 proceso est\u00e1 utilizando un puerto:<\/p>\n\n\n\n
    lsof -i :8080<\/code><\/pre>\n\n\n\n
    Tambi\u00e9n podemos revisar archivos abiertos por un proceso:<\/p>\n\n\n\n
    lsof -p PID<\/code><\/pre>\n\n\n\n
    O encontrar procesos utilizando determinado archivo:<\/p>\n\n\n\n
    lsof \/path\/application.log<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    15. Revisar informaci\u00f3n de un proceso en \/proc<\/code><\/h2>\n\n\n\n
    Una de las ventajas de Linux es que podemos investigar directamente informaci\u00f3n del proceso.<\/p>\n\n\n\n
    Por ejemplo:<\/p>\n\n\n\n
    cat \/proc\/PID\/status<\/code><\/pre>\n\n\n\n
    Revisar variables de ambiente:<\/p>\n\n\n\n
    tr '\\0' '\\n' < \/proc\/PID\/environ<\/code><\/pre>\n\n\n\n
    Revisar el comando utilizado para iniciar el proceso:<\/p>\n\n\n\n
    tr '\\0' ' ' < \/proc\/PID\/cmdline<\/code><\/pre>\n\n\n\n
    Esto puede ser extremadamente \u00fatil investigando aplicaciones Java.<\/p>\n\n\n\n
    \n\n\n\n
    16. Revisar servicios con systemctl<\/code><\/h2>\n\n\n\n
    En sistemas modernos basados en systemd<\/code>:<\/p>\n\n\n\n
    systemctl status application<\/code><\/pre>\n\n\n\n
    Iniciar:<\/p>\n\n\n\n
    systemctl start application<\/code><\/pre>\n\n\n\n
    Detener:<\/p>\n\n\n\n
    systemctl stop application<\/code><\/pre>\n\n\n\n
    Reiniciar:<\/p>\n\n\n\n
    systemctl restart application<\/code><\/pre>\n\n\n\n
    Revisar logs:<\/p>\n\n\n\n
    journalctl -u application<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    17. Revisar logs del sistema con journalctl<\/code><\/h2>\n\n\n\n
    Consultar eventos recientes:<\/p>\n\n\n\n
    journalctl -xe<\/code><\/pre>\n\n\n\n
    Logs de un servicio:<\/p>\n\n\n\n
    journalctl -u application.service<\/code><\/pre>\n\n\n\n
    \u00daltimas 100 l\u00edneas:<\/p>\n\n\n\n
    journalctl -u application.service -n 100<\/code><\/pre>\n\n\n\n
    Seguir los eventos en tiempo real:<\/p>\n\n\n\n
    journalctl -u application.service -f<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    18. Buscar informaci\u00f3n hist\u00f3rica con history<\/code><\/h2>\n\n\n\n
    Durante un incidente tambi\u00e9n puede ser \u00fatil saber qu\u00e9 comandos fueron ejecutados recientemente:<\/p>\n\n\n\n
    history<\/code><\/pre>\n\n\n\n
    Buscar comandos relacionados con una aplicaci\u00f3n:<\/p>\n\n\n\n
    history | grep weblogic<\/code><\/pre>\n\n\n\n
    Buscar reinicios:<\/p>\n\n\n\n
    history | grep restart<\/code><\/pre>\n\n\n\n
    Naturalmente, el historial disponible depender\u00e1 de la configuraci\u00f3n del shell y del usuario.<\/p>\n\n\n\n
    \n\n\n\n
    19. Verificar qui\u00e9n est\u00e1 conectado al servidor<\/h2>\n\n\n\n
    who<\/code><\/pre>\n\n\n\n
    Tambi\u00e9n:<\/p>\n\n\n\n
    w<\/code><\/pre>\n\n\n\n
    Y para revisar accesos anteriores:<\/p>\n\n\n\n
    last<\/code><\/pre>\n\n\n\n
    Esto puede ser \u00fatil cuando varias personas est\u00e1n trabajando simult\u00e1neamente durante un incidente cr\u00edtico.<\/p>\n\n\n\n
    \n\n\n\n
    20. Analizar archivos con awk<\/code><\/h2>\n\n\n\n
    awk<\/code> es extremadamente \u00fatil para procesar logs y resultados de comandos.<\/p>\n\n\n\n
    Por ejemplo, obtener la quinta columna:<\/p>\n\n\n\n
    awk '{print $5}' archivo.log<\/code><\/pre>\n\n\n\n
    En archivos CSV:<\/p>\n\n\n\n
    awk -F',' '{print $5}' archivo.csv<\/code><\/pre>\n\n\n\n
    Tambi\u00e9n podemos combinarlo con otros comandos:<\/p>\n\n\n\n
    ps -ef | awk '{print $1,$2,$8}'<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    21. Procesar texto con sed<\/code><\/h2>\n\n\n\n
    Por ejemplo, reemplazar texto:<\/p>\n\n\n\n
    sed 's\/ERROR\/WARNING\/g' archivo.txt<\/code><\/pre>\n\n\n\n
    Mostrar determinadas l\u00edneas:<\/p>\n\n\n\n
    sed -n '100,120p' application.log<\/code><\/pre>\n\n\n\n
    sed<\/code>, awk<\/code> y grep<\/code> forman una combinaci\u00f3n extremadamente poderosa para analizar grandes cantidades de informaci\u00f3n.<\/p>\n\n\n\n
    \n\n\n\n
    22. Ordenar y contar resultados<\/h2>\n\n\n\n
    Comandos como sort<\/code>, uniq<\/code> y wc<\/code> son muy \u00fatiles durante troubleshooting.<\/p>\n\n\n\n
    sort archivo.txt<\/code><\/pre>\n\n\n\n
    Contar l\u00edneas:<\/p>\n\n\n\n
    wc -l archivo.log<\/code><\/pre>\n\n\n\n
    Contar valores \u00fanicos:<\/p>\n\n\n\n
    sort archivo.txt | uniq -c<\/code><\/pre>\n\n\n\n
    Ordenarlos por frecuencia:<\/p>\n\n\n\n
    sort archivo.txt | uniq -c | sort -nr<\/code><\/pre>\n\n\n\n
    Esto puede ayudarnos, por ejemplo, a encontrar los errores que aparecen con mayor frecuencia.<\/p>\n\n\n\n
    \n\n\n\n
    23. Revisar conexiones de red<\/h2>\n\n\n\n
    ss -ant<\/code><\/pre>\n\n\n\n
    Podemos analizar conexiones hacia un puerto:<\/p>\n\n\n\n
    ss -ant | grep :443<\/code><\/pre>\n\n\n\n
    O contar conexiones por estado:<\/p>\n\n\n\n
    ss -ant | awk '{print $1}' | sort | uniq -c<\/code><\/pre>\n\n\n\n
    Muy \u00fatil cuando investigamos problemas de saturaci\u00f3n o conectividad.<\/p>\n\n\n\n
    \n\n\n\n
    24. Revisar certificados SSL\/TLS con openssl<\/code><\/h2>\n\n\n\n
    En ambientes empresariales, muchos incidentes est\u00e1n relacionados con certificados.<\/p>\n\n\n\n
    Consultar un servidor:<\/p>\n\n\n\n
    openssl s_client -connect server.example.com:443<\/code><\/pre>\n\n\n\n
    Mostrar informaci\u00f3n del certificado:<\/p>\n\n\n\n
    openssl s_client -connect server.example.com:443 <\/dev\/null 2>\/dev\/null |\nopenssl x509 -noout -subject -issuer -dates<\/code><\/pre>\n\n\n\n
    Esto permite revisar r\u00e1pidamente el subject, issuer y fechas de validez<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    25. Revisar carga del servidor con uptime<\/code><\/h2>\n\n\n\n
    Un comando sencillo pero extremadamente \u00fatil:<\/p>\n\n\n\n
    uptime<\/code><\/pre>\n\n\n\n
    Adem\u00e1s del tiempo que lleva encendido el servidor, muestra el load average<\/strong> de los \u00faltimos 1, 5 y 15 minutos.<\/p>\n\n\n\n
    \n\n\n\n
    Un escenario real de troubleshooting L3<\/h1>\n\n\n\n
    Supongamos que recibimos el incidente:<\/p>\n\n\n\n
    “La aplicaci\u00f3n de producci\u00f3n no responde.”<\/strong><\/p>\n\n\n\n
    En lugar de reiniciar inmediatamente el servicio, podemos investigar:<\/p>\n\n\n\n
    1. \u00bfEl servidor tiene recursos?<\/h3>\n\n\n\n
    uptime\nfree -h\ndf -h\ntop<\/code><\/pre>\n\n\n\n
    2. \u00bfLa aplicaci\u00f3n est\u00e1 ejecut\u00e1ndose?<\/h3>\n\n\n\n
    ps -ef | grep java<\/code><\/pre>\n\n\n\n
    3. \u00bfEst\u00e1 escuchando en el puerto?<\/h3>\n\n\n\n
    ss -lntp | grep 8080<\/code><\/pre>\n\n\n\n
    4. \u00bfResponde localmente?<\/h3>\n\n\n\n
    curl -v http:\/\/localhost:8080\/application<\/code><\/pre>\n\n\n\n
    5. \u00bfQu\u00e9 dicen los logs?<\/h3>\n\n\n\n
    tail -100 application.log\ngrep -Ei \"error|exception|failed\" application.log<\/code><\/pre>\n\n\n\n
    6. \u00bfExiste conectividad con las dependencias?<\/h3>\n\n\n\n
    nc -vz database-server 1521\nnc -vz api-server 443<\/code><\/pre>\n\n\n\n
    7. \u00bfExiste alg\u00fan problema DNS?<\/h3>\n\n\n\n
    dig api-server.example.com<\/code><\/pre>\n\n\n\n
    Con unos cuantos comandos podemos comenzar a determinar si estamos frente a un problema de aplicaci\u00f3n, JVM, filesystem, memoria, CPU, red, DNS, base de datos o servicio externo<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    Cheat Sheet \u2014 Linux para Application Support L3<\/h1>\n\n\n\n
    FILESYSTEM\ndf -h\ndu -sh *\nfind \/ -type f -size +1G\n\nLOGS\ntail -f application.log\nless application.log\ngrep -Ei \"error|exception|failed\" application.log\n\nPROCESSES\nps -ef | grep java\ntop\nfree -h\n\nNETWORK\nss -lntp\nnc -vz host port\ndig hostname\n\nHTTP \/ APIs\ncurl -v URL\ncurl -I URL\n\nSERVICES\nsystemctl status service\njournalctl -u service\n\nSSL\/TLS\nopenssl s_client -connect host:443\n\nTEXT PROCESSING\ngrep\nawk\nsed\nsort\nuniq\nwc\n\nSERVER\nuptime\nwho\nw\nlast<\/code><\/pre>\n\n\n\n
    Conclusi\u00f3n<\/h2>\n\n\n\n
    Trabajar como Application Support Engineer<\/strong> no significa simplemente reiniciar servicios cuando algo falla.<\/p>\n\n\n\n
    El verdadero trabajo consiste en recopilar evidencia, correlacionar logs, analizar procesos, revisar recursos, validar conectividad y encontrar la causa ra\u00edz del problema<\/strong>.<\/p>\n\n\n\n
    Despu\u00e9s de a\u00f1os trabajando con Linux, middleware, aplicaciones Java, APIs, bases de datos y ambientes distribuidos, comandos aparentemente sencillos como grep<\/code>, find<\/code>, ps<\/code>, top<\/code>, curl<\/code>, ss<\/code>, awk<\/code> y tail<\/code> terminan convirti\u00e9ndose en algunas de las herramientas m\u00e1s importantes para resolver incidentes cr\u00edticos.<\/p>\n\n\n\n
    Dominar Linux no significa memorizar cientos de comandos.<\/p>\n\n\n\n
    Significa saber qu\u00e9 comando utilizar cuando producci\u00f3n est\u00e1 fallando y necesitas descubrir por qu\u00e9.<\/strong><\/p>\n\n\n\n
    <\/p>\n","protected":false},"excerpt":{"rendered":"
    Cuando trabajas como Application Support Engineer, Linux se convierte en una de las herramientas m\u00e1s importantes para investigar incidentes en producci\u00f3n ya […]<\/p>\n","protected":false},"author":2,"featured_media":1390,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"25 comandos Linux esenciales para Soporte de Aplicaciones","jetpack_seo_html_title":"comandos Linux para soporte de aplicaciones","jetpack_seo_noindex":false,"jetpack_seo_schema_type":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[5,61,60],"tags":[],"class_list":["post-1389","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-production_support","category-sysadmin"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/i0.wp.com\/folken-it.com\/wp-content\/uploads\/2026\/08\/commandosLinux.png?fit=1536%2C1024&ssl=1","_links":{"self":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1389","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1389"}],"version-history":[{"count":1,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1389\/revisions"}],"predecessor-version":[{"id":1391,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/posts\/1389\/revisions\/1391"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=\/wp\/v2\/media\/1390"}],"wp:attachment":[{"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1389"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1389"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/folken-it.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1389"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}