Acerca de Maldito Nerd

Informático por elección, linuxero por convicción, viejo y choto por que no queda otra, el tiempo pasa. Escribo sobre lo que mas me gusta: La música y las computadoras.

Todo lo que sé de sysadminear lo aprendí de mi mamá

Lo que sigue debajo es todo lo que mi mamá me inculcó desde muy chiquito, o lo que me gusta llamar: las 20 leyes del sysadmineo que mi vieja me inculcó desde pequeño y me trajeron hasta acá.



  1. El método noseasunpelotudo de estimación de tiempo.
    Cuando alguien pregunta cuánto tiempo tomará algo, no seas un pelotudo, siempre dobla tu estimación. Esto te da espacio para respirar y corregir errores sin presión, porque, como todos sabemos, en la informática, las cosas rara vez salen según lo planeado y lo que parece el atajo suele ser en realidad el camino más largo entre dos puntos.

  2. Viernes de sólo lectura.
    Los viernes son sagrados. Read-Only hasta la muerte. Evita cualquier cambio que pueda afectar tu entorno de producción en absoluto. La gente está menos disponible para ayudarte si surge un problema, y podrías terminar trabajando el fin de semana, como todos tus putos fines de semana, pero a diferencia de estos últimos, en algo que no tenías previsto atender.

  3. Nombres con significado.
    Jamás nombres un archivo o servidor con ‘test’, ‘tmp’, ‘dev’ o ‘borrar’ a menos que realmente esté destinado para pruebas y podría ser eliminado sin consecuencias. Todos tienen un «entorno de pruebas», pero solo algunos pocos elegidos tienen un «entorno de producción».
    O como dice la ley de Murpy: si se podía borrar, alguien te lo va a borrar, y vas a cagar fuego y del bueno.

  4. No es por los DNS; No puede ser por los DNS; Eran los DNS.
    La regla infalible del sysadmin: cuando algo sale mal, revisá siempre primero los DNS. Por inverosímil que parezca. Por improbable que parezca. Por mucho que creas entender cómo funcionan los DNS.

  5. Cuidado con las POCs que se convierten en producción.
    Si algo comienza como una prueba de concepto (POC) y de repente se convierte en producción, asegúrate de gestionar las expectativas. Una POC siempre debe ser solo eso, una POC.

  6. Establece Límites.
    No seas el pelotudo técnico de aplicaciones para personas que no tienen ni idea de las tecnologías subyacentes que las hacen funcionar. Cada chancho para su rancho. Si algo te excede que lo arregle otro. Que escale hasta el que entiende realmente y que se sepa que te excedió.

  7. Buscá a los que parecen pero no son.
    Si hay alguien pasa todo el puto el día hablando con usuarios, pero no hace el trabajo real de solucionar problemas: te está cagando. Documentá todo su accionar. Vas a necesitar pruebas.

  8. Nunca confíes del todo en lo que dice el usuario.
    Cuando un usuario dice que «todo el sistema está caído y nadie puede trabajar, no anda nada, es urgente», verificá antes de correr. Por lo general es que solamente no le anda internet, MS Word, o la calculadora de Windows.

  9. Siempre tenés que tener un plan de respaldo.
    Si una implementación, un upgrade, un downgrade o una migración comienza a desmoronarse, asegúrate de tener un plan para volver al sistema anterior. Siempre tenés que tener claro cómo volver al estado original cuando algo que no se suponía que salga mal, salga mal.
    Si no tenés un plan para hacer rollback y vas a dar el salto de fé: noseasunpelotudo, posponelo hasta que se te ocurra cómo tener un plan.

  10. Numerá los pasos para esos usuarios que necesitan instrucciones.
    Si estás brindando soporte a alguien que necesita seguir instrucciones, numerá los pasos. Cuando inevitablemente no sigan las instrucciones porque ni te leyeron en el mail original que les enviaste, preguntales en qué paso se quedaron atascados. El 90% del tiempo nunca más volverás a escuchar de ellos y podrás cerrar el ticket por inactividad.

  11. Antes del cambio, preparación.
    Si vas a cambiar algo en un sistema, tenés que tener una imagen CLARÍSIMA de lo que ocurrirá antes de tocarlo. También debes saber, no adivinar, SABER EN SERIO: cuál será el impacto en los usuarios y clientes del sistema.
    Si no podés anticipar los efectos colaterales directos e indirectos: no sos la persona adecuada para realizarlo.

  12. Documentá todo.
    Armate de un conocimiento centralizado coherente en una base de datos de cualquier índole. El primer artículo debe ser sobre cómo formatear todos los futuros artículos para mantener la consistencia.

  13. La regla del y si mañana sos pollo.
    Ninguna persona debe tener conocimiento exclusivo sobre un sistema o mecanismo. La matriz de reemplazo debe contener siempre a gente capaz de hacer lo mismo que ese que mañana no va a poder venir, porque lo pisó un tren. Clave para la continuidad.

  14. Sobre la vitamina D.
    Ser sysadmin es como montar en bicicleta… excepto que la bicicleta está en llamas, tú estás en llamas, todo está en llamas y estás en el infierno.
    De esas llamas es que los que amamos la profesión obtenemos nuestra vitamina D. No nos bronceamos, nos rostizamos en problemas todos de misión crítica.

  15. Confiá, pero verificá.
    Trata a todos con respeto y dignidad, pero siempre verifica la información. El mundo está lleno de idiotas bienintencionados.

  16. ¿Reiniciaste? ¿Seguro? ¿Seguro seguro? ¿Seguro seguro seguro?.
    Odio profundamente a fast-boot. Mi vida sería infinitamente mejor sin fast boot.

  17. Revisá los logs
    Si. Flor de paja. Está todo ahí, a tu alcance, en los logs. Nada más tenés que esforzarte un poco.

  18. Configurá y ajustá las alertas
    Configura las alertas según tus necesidades. Todo tiene la capacidad de enviarte alertas. No siempre necesitás alertas y por lo general menos es más. Cuidado con la fatiga de alertas. Menos alertas enfocadas mata ametralladora de notificaciones.

  19. No serruches la rama en la que estás sentado.
    Siempre que hagas una actualización o cambio, tenés que estar del lado del tronco y no del lado de la rama. Si algo sale mal, tenés que tener un sistema o método para no quedarte fuera. Un método que me dió buenos resultados siempre por ejemplo: programar para dentro de dos minutos un reboot de todo el servidor o restart de un servicio específico justo antes de ejecutar un comando que testeará un cambio de configuración no persistente pero que podría dejarme sin acceso.

Si llegaste hasta acá habrás notado que puse 20 leyes pero son 19.
La número 20 es: no creas todo lo que está en internet. No siempre es verdad.

Y por último: con esta concluyo la serie. Este post es mi tercer experimento, tomé un borrador pendiente de publicar y se lo pasé a CHAT GPT. Arriba pueden apreciar el resultado. Llegó el futuro, damas y caballeros.

Maldita Replicación: repadmin, las dos opciones que tenés que conocer si o si.

Saludos, sufridores del mundo de la administración de sistemas. Hoy, nos adentramos en el maravilloso mundo del replicación en Active Directory. Acompáñame mientras intentamos comprender cómo usar los comandos repadmin /showrepl y repadmin /syncall para mantener un mínimo de cordura en esta locura digital.

Maldita Replicación: repadmin, las dos opciones que tenés que conocer si o si.

Repadmin /showrepl: El Detector de Problemas Compulsivo

¿Alguna vez has tenido esa sensación incómoda de que algo está mal en tu dominio de Active Directory? Pues, ¡felicidades! ¡Bienvenido a la vida de un administrador de sistemas! repadmin /showrepl es tu arma secreta, tu linterna en la oscuridad.

Este comando es el súper detective de Active Directory. Te mostrará todo lo que necesitas saber sobre la replicación entre controladores de dominio. ¿Quieres saber si todo está en orden o si hay un desastre en ciernes? ¡repadmin /showrepl te lo dirá!

Pro Tip: Si eres amante de la emoción, ejecuta este comando y observa los errores de replicación. Después, siéntate, toma una taza de café y disfruta mientras intentas descifrar esos mensajes crípticos.

Repadmin /syncall: ¡La Varita Mágica de la Sincronización!

La vida sería tan sencilla si todos los controladores de dominio se llevaran bien y compartieran sus secretos. Pero no, son como niños malcriados que se niegan a jugar juntos en el parque. Aquí es donde entra repadmin /syncall.

Es como decir: «¡Hey, niños, ¡deténganse con esa pelea de replicación! ¡Es hora de compartir sus juguetes!» Con este comando, forzarás a todos los controladores de dominio a sincronizar sus datos y hacer las paces.

Consejo de vida: Úsalo sabiamente, porque una sincronización forzada puede ser como forzar a tus hijos a compartir sus juguetes. Puede que obtengas un breve momento de paz, o puede que desate un desastre aún mayor.

Conclusión

repadmin /showrepl y repadmin /syncall son tus compañeros en la lucha contra los demonios de la replicación en Active Directory. Son tus héroes, tus guías, y tus confidentes en este salvaje mundo de la administración de sistemas.

Así que adelante, valientes administradores, ponte tu traje de superhéroe y enfréntate a los desafíos de Active Directory. Y recuerda, en este mundo caótico, ¡un poco de sarcasmo y humor mordaz siempre ayuda a mantener la cordura!

Hasta la próxima aventura en el emocionante universo de la administración de sistemas. ¡Buena suerte!

Al igual que el post que precedió a este, tomé algunos de mis borradores más viejos y se los pasé a ChatGPT para ver qué hace con ellos, pidiéndole que lo redacte «copiando» el estilo de malditonerd.com y salió esto que ven arriba.
Llegó el futuro.

[TIP] rsync en modo dios.


Otro título sugerido: Como ejecutar rsync, pero copiando absolutamente todo, incluídos los tiempos de modificación, creación y acceso, softlinks, hardlinks, todo, para que el resultado final sea indistinguible de la magia.

Me dejo a mi mismo como siempre, pero también a la posteridad, este comando que tengo que googlear cada vez que necesito: como hacer para que a rsync no se le escape nada al copiar datos y que el source y destination sean idénticos en todos los aspectos que el sistema de archivos subyacentes lo permita. No porque no esté documentado en el manual, sino porque es más rápido tenerlo agendado en algún lado, para las pocas veces al año en que necesito copiar preservando -casi- todos los atributos con excepción de algunos pocos.

Un comando de la muerte, imposible de recordar y que tengo agendado bloguear al respecto desde el 2015 según veo.
Bueno, 8 años más tarde hoy lo tuve que googlear de nuevo porque lo necesité. Aprovechando la oportunidad, lo dejo documentado aquí para cada vez que lo necesitemos de nuevo. 


El comando en cuestión se ejecuta así:

Sigue leyendo

Herramienta de recortes de Windows: aprendé cómo lo hacen los grandes.

Otro título sugerido: todo lo que la snipping tool de Windows quiso y nunca pudo ser, pero para Linux.



Post cortito. Como patada de chancho:



En promedio hasta tres veces por año me encuentro con alguna aplicación que es tan pero TAN TAN buena que me da ganas de hacerle propaganda.

Van 25 días del año 2022 y ya encontré la primera: Flameshot, screenshots para Linux, pero bien hechos. (Y a los que quieran discutir que Lightshot es mejor o que Windows no se la come: vengan de a uno, putos).

Vean nada mas:



Ahora por fin podés dejar de sentirte menos. Ya no tenes nada que envidiarle a los usuarios de Windows sino todo lo contrario:


Si sos un pelotudo como yo y usás i3 como windows manager de tu Linux, podés llamarlo con la tecla Print Screen de tu computadora agregando a tu archivo ~/.config/i3/config dos líneas que digan:

bindsym Print exec flameshot full -p /home/coso/Pictures/screenshots
bindsym Shift+Print exec flameshot gui -p /home/coso/Pictures/screenshots


Para luego aplicar el cambio reiniciando i3 con MOD + SHIFT + C.



Te dejo debajo también la ayuda, para que entiendas cómo lo configuré:


Usage: flameshot [flameshot-options] [arguments]

Options:
-h, --help Displays this help
-v, --version Displays version information
Arguments:
gui Start a manual capture in GUI mode.
screen Capture a single screen.
full Capture the entire desktop.
launcher Open the capture launcher.
config Configure flameshot.