$ echo "Made with a MacBook" | lsb_release -a > Debian GNU/Linux unstable
Mar 11 2010
1-Nueva versión de un imprescindible, OpenSSH (la 5.4). Novedad; “netcat mode”, corrige bugs leves (ENG).
2-Importante release, Servidor web Apache versión 2.2.15 (ENG). Corrige bug en SSL y otros de importancia.
3-Forat sigue con su proyecto de servidor web, en la última entrega (usando el servicio de DNS “no-ip).
4-Las 10 apps Open Source más descargadas de la historia (lo de alguna de ellas ni me lo imaginaba). (ENG).
Ene 29 2010
Si amigos, Forat suelta la mecha del que será su próximo gran proyecto para empezar el 2 010 con fuerza y celebrar su reciente paternidad (podéis seguir las novedades de su “apt-get remove pañal” xD en www.forat.es, el blog de su hijo Eric-;).
En una de mis anteriores entradas, me hice eco de la nueva situación de Forat a nivel personal que se avecinaba y también en su blog con el cierre de comentarios, decisión que le ayudé a tomar y que apoyé en todo momento. Pero como dijo en su día, no iba a parar su actividad, sino que este punto y seguido serviría para preparar futuros contenidos de un modo más pausado y aquí está el resultado.
He estado muy cerca de la creación de este tutorial en el que paso a paso, podréis instalaros un servidor web en vuestra casa con software libre y listo para funcionar a pleno gas y os puedo decir que Forat ha echado el resto como podréis ir viendo en cada entrega del tutorial.
Somos compañeros de podcast y de terminal muchas noches en interminables y apasionantes sesiones vía SSH coordinando la jugada por Skype (con el cambio de su server que comenta en la intro del tuto tuvimos alguna memorable-;) pegándonos con Apache, MySQL, PHP y “casi todo lo que se menea” en un servidor web y os aseguro que si seguís los pasos que plantea Forat, os vais a ahorrar mucho trabajo -;).
Acceso a “Servidor Web bajo Linux Ubuntu Server – Introducción”
Ánimo bro !! Estamos con ganas de ver ya todo el material -;)
Mar 19 2009
Bien, para poneros en antecedentes os comentaré que hace tiempo (más de 4 años) ya expresé públicamente lo que pensaba acerca de “cierta política” de recuperación de dominios de amen.es. Por lo que en este caso, llueve sobre mojado.
Para no dispersaros mucho de vuestra multitarea, que sé como es el tema, os lo resumiré lo que más pueda pero prefiero documentar un poco los pasos para que os pongáis escena. Esto le ha sucedido a un colega con un servidor dedicado en el que yo he realizado algunas tareas de administración y optimización, el nombre no viene al caso, quizás alguno sabéis de quien hablo pero lo importante es saber con que empresa trata uno en casos como este.
Está claro que no se puede generalizar y que la gente de Amen no hará todo mal, también sé muy bien que la administración de sistemas no es una tarea fácil y que hay muchos puntos críticos o que sean susceptibles de fallar más que otros pero hablaré de lo que he visto en todo este proceso de la forma más objetiva posible.
Máquina, un servidor dedicado con tiempo ya, un Dual Xeón con mucho trote y descatalogado de la oferta actual de Amen, 150 Gb de disco duro, 2 Gb de Ram y una distribución de Fedora Linux junto a uno de esos imagino “males necesarios” que son los paneles de administración vía web, (tema del que hablé), en este caso Direct Admin.
Esto sucedió un Viernes, me llega un mail de mi colega “Dabo, el servidor ha petado, me dicen que hay muchos errores en el disco los de Amen y que me ponen el servidor en modo recuperación”, ellos lo llaman “Recovery mode” que no es otra cosa que un arranque de la maquina en cuestión vía un Live CD de Ubuntu en este caso (que supongo será una imagen vía red que tendrán preparada).
Más datos sobre el detalle del recovery mode famoso, una salida del comando uname -a (con -r da menos info);
root@wpc:~# uname -a
Linux wpc___.amenworld.com 2.6.24.2-live #1 SMP Tue Apr 22 16:13:55 UTC 2008 i686 GNU/Linux
Para saber la versión exacta del S.O, suelo usar “lsb”, concretamente lsb_release -a (hay otras formas);
root@wpc:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04
Release: 8.04
Codename: hardy
Viernes noche / Sábado, bien, a partir de ahí entro vía SSH al servidor en modo “rescate” y veo como efectivamente la salida del comando fsck (usadlo sólo sin estar montadas las unidades) reporta un montón de errores en el disco, había un sistema Raid por software con una forma de petar muy extraña pero eso es otra historia.
Previamente había estado haciendo algunas que otras comprobaciones con la ayuda de mi colega “AJ”, al final después de unos cuantos reinicios en “modo normal” desde el panel web de Amen a ver si arrancaba el sistema y viendo que no había forma de poder ya levantar todo normalmente y que ni conectaba vía SSH, ya descarté seguir en esa máquina y la prioridad para mi fue recuperar todo el contenido de /home (donde estaban las webs) y de /var/lib/mysql, donde estaban las bases de datos en el momento de petar…
Como sabéis, el comando fsck que tiene varios parámetros para ejecutarse, una vez que hace las comprobaciones de disco, envía los archivos recuperados al directorio “Lost+Found”, había muchos material para recuperar en este caso, una vez finalizadas todas las operaciones en el disco, vía rsync hubo que colocarlos en su lugar original, para después, dejar montada una partición de disco con /home y /var con todo el contenido original con la idea de enviarlo después vía rsync al nuevo servidor…
Esta parte de la recuperación la resumo mucho porque llevó unas 5 o 6 horas recuperando, reiniciando, desmontando y montando unidades, Raids y la madre que le parió al disco duro… (se haría muy largo el post, os lo aseguro).
A todo esto ¿Qué le decía a su cliente o más bien hacía Amen? nada de nada, Viernes tarde y claro, como para ponerse con un “pancho” como este…toma soporte 24 x 7 x 365 (otra cosa como veis de la que ya escribí) y ojo, no cobran mal no, unos 50 eur la hora y no digamos lo que se gastó mi colega llamando a algún número 807…”Lo estamos mirando”.
Para colmo de la mala suerte, el cliente tenía contratado un servicio de backups para las bases de datos hacia otra máquina que falló, el problema es que no es ni mucho menos seguro que funcionen las bases de datos en un caso de “petazo” volviendo a poner las antiguas como estaban en el nuevo servidor, lo digo porque están como si fuera vía una “copia en caliente” o con el comando cp, no con un mysqldump que es lo suyo, pero se puede intentar hacer ese volcado en otro server o localmente y luego revertir el volcado y esperar a que funcione y si no chuta, a intentar reparar vía mysqlcheck o myisamchk las bases pero eso ya es otra historia…
¿Y dónde estaba Amen el Sábado y el Domingo? no sé, fuera de servicio (y de juego…)
Al final, llamaron el Lunes a las 10 am y llegaron a un acuerdo con mi colega para que le cambiaran a otro servidor más potente, un Core2 Duo y le dijeron que se ponían con la instalación del sistema…Le dieron varias opciones, todas con Plesk como panel de administración vía web y le aconsejé lógicamente que le metieran Debian GNU/Linux.
“Nos ponemos con la instalación”
Le llaman otra vez por teléfono;
“Sr cliente, hay un problema con el script de instalación, no podemos instalar Debian pero podemos ofrecerle Ubuntu o Fedora”
Me lo cuenta y yo alucino y le digo que a una mala meta Ubuntu pero que no transija fácilmente y que si tiene que esperar que lo hiciera. Después le llamaron y le dijeron que lo habían solventado…WTF !
Se tiran todo el Lunes out y el sistema sin instalar hasta el Martes, día en el que por fin quedó todo listo. Me manda el password del root, entro y zas !, la primera en la frente, el esquema de particiones brillando por su ausencia o más bien por su escasez…Todo montado en la raíz /. No les da la cabeza para meter en particiones diferentes el home, var (ya no digo /var/log y var/lib/mysql), /tmp o las webs /www pero es algo que no sólo lo hace Amen.
No os cuento nada de la configuracion por defecto del S.O, Apache o mysql…
No os enrollo más porque no acabaría dando detalles y más detalles ¿Cómo acabó la historia?, al final tuve suerte con la recuperación / restauración y más o menos todo está funcionando bajo Debian y Plesk 8 (El Plesk y estos paneles de administración vía web digo que son un “mal necesario” por la cantidad de porquería que meten en el sistema y como se medio apoderan de el, pero algo muy útil para usuarios que no sepan de sistemas) con algún tema que está dando guerra.
Viendo el resultado final, lo mínimo para lo que podía haber sido, todas las bases estan chutando y los 60 gigas de datos replicados al nuevo servidor. Quedan cosas por afinar, servicios por asegurar etc, pero de verdad, desde luego que no será porque Amen se ha molestado por su cliente...
De todos modos, en una ocasión ya opiné sobre los peligro de un servidor web dedicado mal administrado vía Plesk, Cpanel, DirectAdmin o similar sin meterte vía SSH a actualizar-monitorizar-optimizar el sistema. Lo siento por Amen, pero van dos y puede que alguno de vosotros haya pasado por lo mismo e imagino que te puede hacer de todo menos gracia.
Se me olvidaba, ese servidor para mi colega es su medio de trabajo...No se ha ido de Amen porque en Enero firmó un contrato hasta el mismo mes de 2.010. Está bien dar una segunda oportunidad a la gente, ya que como he dicho en el comienzo del post, no todo será malo pero creo que es bueno saber con lo que puedes contar llegado ese momento que por cierto, tarde o temprano, nos puede sobrevenir a todos.
Pero creo que lo peor fue en una situación como esta, no recibir una verdadera opinión – actuación profesional por parte de una empresa que se entiende y de hecho asi es, sabe de todo esto mucho más que yo.
Feb 01 2008
Alguna vez tengo que conectarme a un host remoto mediante SSH y no tengo una línea de comandos Unix-GNU/Linux frente a mi, al igual que seguramente muchos de vosotros, uso PuTTY, el cliente SSH por excelencia para entornos Windows que también está portado a otras plataformas.
En esos momentos es cuando más echo de menos las pestañas de mi querida “Konsole” en Debian o “iTerm” en Mac OS X. Hasta ahora, mis sesiones remotas vía PuTTY eran un engorro porque si quería tener más de una sesión abierta, tenía que abrir múltiples ventanas, un rollo vaya.
Pues bien, vía LifeHacker me entero de la existencia de PuTTY Connection Manager, una aplicación que hace posible el uso de pestañas en PuTTY que tiene que estar instalado previamente en el sistema. Recomendable también el uso de PuTTY Tray para una mayor personalización de la ventana.
Technorati Tags: PuTTY, pestañas, tabs, ssh, Windows, redes, iTerm, Konsole
Sep 05 2007
/ Edito y añado, Fenixer, empresa de alojamiento web se ha hecho eco de este post y mirad que clarito hablan, da gusto /.
Hace unos días, en otro post contestando a Aj, comenté que iba a hablar sobre el tema. Intentaré ser lo más objetivo posible y lo que aquí os diga, tomadlo únicamente como una opinión personal, fruto del uso de estas soluciones durante un tiempo, para acabar dejándolas de lado.
Quizás alguno piensa que el título o “titular” es un poco alarmista, pero os aseguro que igual me quedo corto viendo lo que se ve por ahí.
La cuestión es simple, imaginad un sitio web que tiene unas necesidades de expansión grandes y decide contratar un servidor dedicado. Dentro de los planes de alojamiento habituales, esta es la opción más potente y cara dicho sea de paso, una máquina enterita para ti, con toda su capacidad y también, con sus problemas…
Por debajo de esta opción, está el llamado “servidor virtual” donde te aseguran (es muy fácil decirlo) un mínimo de memoria RAM o CPU de la máquina que compartes (también acceso por ssh como root, etc, etc).
En una escala inferior, (la más común) se encuentra el típico alojamiento compartido, donde puedes llegar a convivir en el mismo servidor con otros cientos de webs, pero que tampoco necesariamente tiene que funcionar mal si está bien controlado.
Hasta aquí, creo que todos entienden más o menos las diferencias, ahora pasemos a hablar del porqué de mi afirmación de “servidores en peligro”.
En este caso, tengo que pasarle la mayor parte de la responsabilidad a los proveedores de alojamiento, no voy a acusarles de publicidad engañosa pero para ser políticamente correcto (que no lo suelo ser -;), lo dejaré en un “es un cuasi-engaño“.
El cliente, leyendo frases como esta, piensa que es como el nirvana aplicado a la web;
“Podrá usted mantener su sistema actualizado y siempre a punto de un modo totalmente gráfico y sin necesidad de aprender complicados comandos de administración remota”.
Y UNA MIERDA !! con perdón xD. Si alguno se piensa que con una solución tipo Plesk, cPanel, etc, va a administrar un servidor web que dios le pille confesado -;).
Algunos casos de las “bondades” de Plesk los podéis leer (por citar un caso) en Abansys sobre Plesk pero que nadie piense que esto no es algo generalizado, ellos no dicen nada que no digan los demás, sirva como digo únicamente a modo de ejemplo, este que os pongo es de una búsqueda rápida en Google.
Plesk utiliza el estandar en seguridad adoptado por los servidores UNIX (security model). Este modelo ha sido probado en cientos de miles de servidores UNIX de todo el muno y ha demos- trado su altisimo nivel de seguridad. Al mismo tiempo, Plesk ha sido desarrollado para preservar la flexibilidad de los administadores de sistemas UNIX que necesitan un total control sobre sus servidores..
No he visto a un Plesk activar y controlar la caché de MySQL, compilar Apache con un módulo determinado, parchear un Kernel o hacer rular DenyHosts, esto va por lo de “total control“…
Aquí algo de información sobre cPanel que es parecido a Plesk en la gestión y uso de las opciones con las que cuenta.
Vamos a ver, con un software como los que he citado (que hay más), tu puedes; crear cuentas de correo, administrar cuotas de disco, crear usuarios FTP, añadir dominios, reiniciar servicios, hacer backups, instalar algo de software, etc, etc. (Ver Demos al final del post).
Por supuesto nada que no se pueda realizar desde un línea de comandos Unix GNU/Linux. La ventaja del uso de alguna de estas soluciones es que accedes a través de una interfaz web donde, a golpe de ratón y de un modo muy sencillo, controlas varios aspectos del servidor web.
¿Qué es lo que no se dice? lo que no se dice es que puedes administrar PARTES de un servidor web con cPanel o Plesk, pero es imprescindible que además lo hagas del modo “tradicional”, linea de comandos ssh y teclear comandos y más comandos.
Oct 29 2006
Viendo la lista de correo de Security Focus, me he encontrado con esta información muy interesante sobre el análisis de los intentos de ataque a SSH a un servidor.
En él artículo, Christian Seifert, da un repaso a las técnicas más efectivas para detectar y bloquear ataques a este medio de conexión remota entre ordenadores, si bien es más seguro que el clásico “Telnet” (los datos viajan bajo una capa de cifrado), como decía, es especialmente crítico para un servidor web.
También estaciones de trabajo en red o por ejemplo, yo entre mis dos ordenadores, conecto si estoy fuera de casa el portátil al fijo vía SSH para consultar lo que necesite.
Hace un tiempo os comenté lo útil que resultaba DenyHosts para bloquear esos intentos de login al SSH, como complemento, esta información viene muy bien porque habla del uso de “honeypots” para recopilar información sobre los ataques y su posterior análisis, apoyado también por otras herramientas de auditoría, análisis que el autor va desgranando de un modo muy claro e inteligible, recibe por cierto como unos 300 ataques al día…
También da consejos sobre como fortalecer SSH frente a ataques externos.
Acceso al árticulo original, en Inglés.
Lo he subido a Menéame, en este post, para compartirlo (sin autobombo ni adsense “code” Richardddd que te conozco-;).
Sep 12 2006
Hola -;) Solo quería comentaros desde aquí un pequeño ejemplo de como usando el mod de Apache “Mod_Status” (También llamado “Server Status”) se puede detectar tráfico indeseado sobre vuestro server.
Un amigo llevaba varias semanas con problemas de tráfico en su servidor dedicado, me lo comentó y quedé en darle un vistazo, en la máquina me decía que tenía picos muy altos de carga y repentinos.
Me puse manos a la obra a ver si veía algo raro y sobre todo a ver los logs y monitorizar el server , una máquina con Debian GNU/Linux funcionando.
Estaba haciendo un “top” a la máquina cuando vi que el índice de carga subió de repente a un 4,40 y llevaba una carga (load average) de un 0,40 de media, un valor normal en estos casos.
Yo había instalado previamente Iptraf , (algo he comentado aquí sobre esa utilidad de red) y el “Apache Status” para llegado el caso ver que sucedía en la máquina. (aquí os linko a un ejemplo del mod_status rulando de apache.org para que veáis como funciona, da datos sobre ips conectadas, Kb consumidos, carga de la CPU a que host etc etc, abajo hay una leyenda de esos valores).
Lo primero que hice fue creo que un ps -aux para ver si algún proceso del “cron” había saltado o alguna aplicación tipo Spam-Assasian o similar etc lo provocaba.
Vi que no y que era el Apache quien tenía una carga más alta de la normal, abrí en una ventana Iptraf y en otra hice un netstat -an | grep :80 para ver el tráfico del puerto 80.
Ene 25 2006
Pues si, hoy me toca dar un poco la paliza con SSH, como podéis leer en la link a la wikipedia, se trata de un modo más seguro que el Telnet tradicional para trabajar con archivos remótamente. Puedes usarlo en Mac, Linux, Unix o Windows, los tres primeros tienen incorporadas líneas de comandos y para Windows hay una utilidad que te permite ejecutar comandos Unix remotamente, putty.
