Linux Es Dificil — Hasta Que Entiendes estas 7 Cosas

Fuente: artículo original de Pawan Natekar en CodeX. Adaptado y ampliado por Sammi De Blas.

---

Lo que nadie te dice al principio

La primera vez que Linux te dice “Permission denied”, lo tomas personal.

Escribiste el comando bien. Seguiste el tutorial paso a paso. Y Linux se niega.

Linux no te está bloqueando. Te está enseñando una regla que nunca aprendiste.

---

1. Permisos ” El primer muro

El error clasico

./backup.sh
bash: ./backup.sh: Permission denied

Solución instintiva del principiante:

sudo ./backup.sh

Funciona, pero es como forzar una puerta en vez de usar la llave. Estas evadiendo el problema, no entiendendolo.

Como funciona de verdad

En Linux, cada archivo responde 3 preguntas:

• Quien es el dueno?
• Quien mas tiene acceso?
• Que exactamente pueden hacer?

ls -l backup.sh
-rw-r--r-- 1 pawan pawan 2456 backup.sh

Desglose de esa linea:

-rw-r--r--
│└┬┘└┬┘└┬┘
│ │  │  └── Otros: solo lectura (r--)
│ │  └───── Grupo: solo lectura (r--)
│ └──────── Dueno: lectura+escritura (rw-)
└────────── Tipo: archivo normal (-)

No hay x ” por eso no puedes ejecutarlo. Linux no se equivoco. Es preciso.

La solución correcta:

chmod +x backup.sh     # Anadir permiso de ejecucion
./backup.sh            # Ahora funciona

Los 3 permisos fundamentales

Permiso	Letra	Significado	Para archivos	Para directorios
Read	r	Leer	Ver contenido	Listar archivos (ls)
Write	w	Escribir	Modificar	Crear/eliminar archivos dentro
Execute	x	Ejecutar	Ejecutar como programa	Entrar con cd

El error de usar sudo para todo

sudo ejecuta como root. Cada vez que haces sudo para algo que no lo necesita, estas:

• Saltandote el sistema de permisos (no aprendes como funciona)
• Dandole poder de root a un script que no lo necesita
• Creando dependencia de sudo (si algo falla con sudo, no sabes por que)

Regla: Si puedes hacerlo sin sudo, hazlo sin sudo. Si necesitas sudo, pregunta por que.

---

2. El Filesystem ” Por que Linux se siente “perdido”

La primera vez que instalas un servicio en Linux, preguntas: “Donde fue?”

No hay C:. No hay ventana de instalador. No hay acceso directo.

Linux no esconde archivos ” los categoriza. Cada directorio tiene un proposito:

Directorio	Contenido	Ejemplo
/etc	Configuracion	/etc/nginx/nginx.conf, /etc/ssh/sshd_config
/var/log	Logs	/var/log/syslog, /var/log/auth.log
/home	Datos de usuarios	/home/pawan/
/bin	Ejecutables esenciales del sistema	ls, cp, mv
/usr/bin	Ejecutables de usuario/aplicaciones	python3, curl, git
/tmp	Archivos temporales (se borra al reiniciar)	Archivos de sesion
/opt	Software de terceros	/opt/google/chrome/
/srv	Datos de servicios	/srv/www/
/proc	Informacion del kernel en tiempo real (virtual)	/proc/cpuinfo, /proc/meminfo
/dev	Dispositivos (todo es un archivo)	/dev/sda, /dev/null

El mapa mental:

• Configuración rota? ←’ /etc
• Necesito ver que paso? ←’ /var/log
• Donde está el binario? ←’ /bin o /usr/bin o which comando
• Donde viven los datos del servicio? ←’ /srv o /var/lib

Linux no es caotico. Tu no tienes el mapa. Una vez que sabes donde va cada cosa, dejas de buscar al azar.

---

3. Procesos ” La multitud invisible

El sistema va lento. Reinicias. Nada cambia.

top

De repente ves todo:

• CPU al 98% por un proceso
• Memoria agotada
• El proceso culpable con su PID

Version mas util:

htop                  # top con interfaz mejorada (instalar si no esta)
ps aux | grep java    # Buscar un proceso especifico

Para matar el proceso culpable:

kill 12345            # PID del proceso (SIGTERM, cortes)
kill -9 12345         # Forzar muerte (SIGKILL, sin cortesia " ultimo recurso)

Linux no se pone lento. Un proceso se descontrola. Los procesos son la multitud invisible ” hasta que miras, no sabes quien hace que.

Comandos utiles de procesos

ps aux                      # Todos los procesos del sistema
ps -ef --forest             # Arbol de procesos (padre-hijo)
pgrep -f nginx              # Encontrar PID por nombre
pkill -f nginx              # Matar proceso por nombre
lsof -i :8080              # Quien esta usando el puerto 8080?
 uptime                      # Tiempo encendido y carga (load average)

---

4. Servicios ” “Ayer funcionaba”

El servidor web no arranca. Sin popup, sin warning, sin nada.

systemctl status nginx

Ahi está la respuesta ” un archivo de configuración faltante, un puerto ocupado, un certificado expirado. El sistema te lo dice, solo que no grita.

Comandos esenciales de servicios:

systemctl status servicio      # Estado actual + ultimas lineas de log
systemctl start servicio       # Iniciar
systemctl stop servicio        # Parar
systemctl restart servicio     # Reiniciar (stop + start)
systemctl enable servicio      # Arrancar al boot
systemctl disable servicio     # No arrancar al boot
systemctl list-units --type=service --state=running   # Servicios activos

Si algo funcionaba ayer y hoy no: no reinstales. systemctl status te dice que paso. Casi siempre es un config roto, un puerto en conflicto, o un certificado caducado.

---

5. Logs ” Linux siempre se explica

El error mas grande de los principiantes: “Linux nunca te dice que está mal.”

Falso. Linux te lo dice todo ” en los logs.

journalctl -xe                    # Log del sistema con contexto de error
tail -f /var/log/syslog           # Seguir logs en tiempo real
tail -f /var/log/auth.log         # Intentos de autenticacion (SSH, sudo)
dmesg                             # Logs del kernel (hardware, drivers)

Logs por servicio comun:

journalctl -u nginx --since "1 hour ago"    # Logs de nginx de la ultima hora
journalctl -u ssh --since today             # Logs de SSH de hoy
tail -100 /var/log/nginx/error.log          # Ultimos 100 errores de nginx

Cada crash tiene una historia. Cada fallo deja un rastro. Linux no grita errores. Los registra. Tienes que saber donde buscar.

Donde buscar segun el problema

Problema	Donde mirar
Servicio no arranca	systemctl status servicio + journalctl -u servicio
Error de autenticacion SSH	/var/log/auth.log
Kernel panic / hardware	dmesg
Cron job que falla	journalctl -u cron o /var/log/syslog
Aplicacion web	/var/log/nombre_app/error.log
Perdida de red	journalctl -u NetworkManager

---

6. Networking ” “En mi maquina funciona”

El servicio corre. El puerto está abierto. Pero no hay conexión.

Misma metodologia que el articulo anterior ” en orden:

# 1. Interfaz
ip a
 
# 2. Puertos abiertos
ss -tuln
 
# 3. Conectividad basica
ping google.com
 
# 4. Firewall
firewall-cmd --list-all
# o
iptables -L -n

Networking deja de ser magia cuando lo tratas como lógica: el paquete sale de la interfaz, pasa por la ruta, cruza el firewall o se queda. punto.

---

7. El cambio mental

Linux no es dificil. Es honesto.

• No asume que quieres hacer algo
• No adivina tus intenciones
• No te protege de tus malas decisiones
• Cada accion tiene consecuencias visibles en permisos, logs y procesos

La diferencia entre un principiante frustrado y un admin que resuelve problemas no es inteligencia. Es conciencia ” saber donde mirar, que preguntar, y seguir el orden en vez de saltar al azar.

---

Resumen: Los 7 puntos en una linea cada uno

1. Permisos: Si dice “denied”, no uses sudo ” lee los permisos con ls -l y entiende que falta
2. Filesystem: No busques al azar ” cada directorio tiene un proposito (/etc config, /var/log logs, /home datos)
3. Procesos: Si va lento no reinicies ” mira top o htop y encuentra el culpable
4. Servicios: Si algo dejo de funcionar no reinstales ” systemctl status te dice por que
5. Logs: Linux siempre te dice que paso ” journalctl -xe o tail -f /var/log/syslog
6. Networking: Sigue el orden (interfaz ←’ ruta ←’ DNS ←’ firewall) y dejas de adivinar
7. Mentalidad: Linux no te odia. Es preciso. Aprende sus reglas y deja de pelear contra ellas

---