La situación es que queremos comprobar que un puerto está abierto y disponemos de un servidor o un pc Linux desde donde hacerlo, nada tan fácil como usar netcat.
Podemos hacerlo de dos maneras, uno enganchando al puerto, o bien, sin enganchar y comprobando el código de retorno (es la manera que más me gusta a mi porque me es útil para hacer scripts).
La primera manera sería simplemente:
# nc host puerto
La segunta manera sería.
# nc -z host puerto; echo $?. Si el código es 0 el puerto está abierto, si es un 1 el puerto está cerrado
Mostrando entradas con la etiqueta redes. Mostrar todas las entradas
Mostrando entradas con la etiqueta redes. Mostrar todas las entradas
06 octubre 2011
22 enero 2008
Problemas de DNS con proveedores de hosting
Aunque el título parece ilustrativo el tema es mucho más profundo, es casi como un cuento :-).
Vamos a situarnos. Tenemos varios servidores dedicados en un ISP (por supuesto linux) que gestionamos directamente nosotros, hasta aquí todo normal.
Uno de los servidores está dedicado a recopilar estadísticas de los otros. En otros servidores tenemos unos ficheros de los cuales queremos guardar estadísticas del número de descargas.
Para conseguir guardar estas estadísticas tenemos un fichero php que se encarga de servir el fichero en cuestión hacer una petición al servidor de estadísticas que realiza la query correspondiente en la base de datos.
Últimamente el jefe me comentaba que veía cosas raras en los servidores y que no debían estar finos porque no parecía que descargaran bien. Yo lo respondía estaba monitorizando los servidores y que iban correctamente, y que apenas tenían carga (ya que los servidores grandes utilizan nginx).
Ayer ya me dijo: "Bórrate el caché y descarga otra vez el fichero X".
Yo lo hice y efectivamente tardaba más de diez segundos en comenzar a cargar un fichero de apenas 100 KB.
Mi conclusión, por una parte lógica, pero por otra precipitada, fue que el problema venía del servidor de estadísticas; aunque por otro lado me extrañaba, porque tenía una carga aparentemente baja como para ralentizar de esta manera las descargas.
Cuán equivocado estaba...
De casualidad y supongo que también ayudó estar mirando diversos logs, descubrimos que todo el problema se debía a los servidores de DNS que teníamos configurados en el /etc/resolv.conf.
Resolvían nombres, pero tenían un pequeño retardo al principio que hacía que se retrasara todo el procesamiento de php, con el consiguiente retardo en las descargas. Tuvimos que incluir los nombres de los servidores en /etc/hosts, a la antigua usanza :-) y entonces comprobamos que las aguas volvían a su cauce
Después de esto nos hemos dado cuenta que tenemos que reescribir ese php, porque si la máquina que procesa las estadísticas repercute en las descargas.
Pero lo mejor estuvo por llegar. A través del webchat, me pongo en contacto con mi proveedor de hosting para indicarles que tienen unos servidores de DNS que están sirviendo mal los nombres.
Simplemente se lo indicaba por si más personas tenían esos servidores configurados.
Me responden, que no me pueden ayudar, que los servidores funcionan perfectamente y que si tengo algún problema que abra un ticket. Realmente es un poco vergonzoso ya que confías en tu proveedor, ni por asomo te puedes imaginar que un servicio básico como el DNS le vaya a funcionar mal y que cuando intentes ayudar te vengan a decir, "andaaaaa,.... que no es por no mirarlo, si hay que mirarlo se mira...., pero si todo funciona bien, ¿para qué voy a mirarlo?"... :-)
Vamos a situarnos. Tenemos varios servidores dedicados en un ISP (por supuesto linux) que gestionamos directamente nosotros, hasta aquí todo normal.
Uno de los servidores está dedicado a recopilar estadísticas de los otros. En otros servidores tenemos unos ficheros de los cuales queremos guardar estadísticas del número de descargas.
Para conseguir guardar estas estadísticas tenemos un fichero php que se encarga de servir el fichero en cuestión hacer una petición al servidor de estadísticas que realiza la query correspondiente en la base de datos.
Últimamente el jefe me comentaba que veía cosas raras en los servidores y que no debían estar finos porque no parecía que descargaran bien. Yo lo respondía estaba monitorizando los servidores y que iban correctamente, y que apenas tenían carga (ya que los servidores grandes utilizan nginx).
Ayer ya me dijo: "Bórrate el caché y descarga otra vez el fichero X".
Yo lo hice y efectivamente tardaba más de diez segundos en comenzar a cargar un fichero de apenas 100 KB.
Mi conclusión, por una parte lógica, pero por otra precipitada, fue que el problema venía del servidor de estadísticas; aunque por otro lado me extrañaba, porque tenía una carga aparentemente baja como para ralentizar de esta manera las descargas.
Cuán equivocado estaba...
De casualidad y supongo que también ayudó estar mirando diversos logs, descubrimos que todo el problema se debía a los servidores de DNS que teníamos configurados en el /etc/resolv.conf.
Resolvían nombres, pero tenían un pequeño retardo al principio que hacía que se retrasara todo el procesamiento de php, con el consiguiente retardo en las descargas. Tuvimos que incluir los nombres de los servidores en /etc/hosts, a la antigua usanza :-) y entonces comprobamos que las aguas volvían a su cauce
Después de esto nos hemos dado cuenta que tenemos que reescribir ese php, porque si la máquina que procesa las estadísticas repercute en las descargas.
Pero lo mejor estuvo por llegar. A través del webchat, me pongo en contacto con mi proveedor de hosting para indicarles que tienen unos servidores de DNS que están sirviendo mal los nombres.
Simplemente se lo indicaba por si más personas tenían esos servidores configurados.
Me responden, que no me pueden ayudar, que los servidores funcionan perfectamente y que si tengo algún problema que abra un ticket. Realmente es un poco vergonzoso ya que confías en tu proveedor, ni por asomo te puedes imaginar que un servicio básico como el DNS le vaya a funcionar mal y que cuando intentes ayudar te vengan a decir, "andaaaaa,.... que no es por no mirarlo, si hay que mirarlo se mira...., pero si todo funciona bien, ¿para qué voy a mirarlo?"... :-)
03 diciembre 2007
Medir el ancho de banda en linux
He probado dos herramientas bastante interesantes para medir el ancho de banda, jnetop y iftop.
Ambas son herramientas que muestran la ocupación de ancho de banda, por petición y en total, con la peculiaridad de que se ejecutan en línea de comandos.
Además jnetop tiene ahora un GUI en java.
Puede ser que iptraf recoja más estadísticas, pero a mi estos dos programas me son de gran utilidad cuando quiero ver de dónde viene la ocupación del ancho en los servidores web.
Ambas son herramientas que muestran la ocupación de ancho de banda, por petición y en total, con la peculiaridad de que se ejecutan en línea de comandos.
Además jnetop tiene ahora un GUI en java.
Puede ser que iptraf recoja más estadísticas, pero a mi estos dos programas me son de gran utilidad cuando quiero ver de dónde viene la ocupación del ancho en los servidores web.
18 octubre 2007
Publicar enlaces p2p no es delito
Así ha sentenciado un juzgado de Madrid archivando una causa contra dos páginas web.
http://www.filmica.com/david_bravo/archivos/006576.html
http://www.filmica.com/david_bravo/archivos/006576.html
18 mayo 2005
Proftpd con mysql y cuotas en Gentoo
Instalacion del proftpd Gentoo Linux.
Lo primero que hice fue reflexionar sobre qué era lo que quería.
Principalmente quería usuarios virtuales, no de sistema, que pudieran subir archivos como el usuario apache y con un
sistema que no necesariamente tuviera que ser compatible con ldap, por lo tedioso (para mi) que es trabajar con
ldap (supongo que cuando se tiene un poco de soltura con ello es igual, pero prefiero mysql).
No me importaba que el sistema utilizara o no base de datos en realidad, aunque finalmente fue así.
También quería que escribiera los datos como el usuario apache, para no tener problemas de permisos, puesto que en
el sistema instalado el usuario que corre apache es "apache", y el grupo "apache".
El software que elegí finalmente fue "proftpd". Es un gran sistema ftp que tiene una sintaxis similar a la de
apache, que soporta usuarios virtuales y tiene varios módulos.
Buscando un poco de información en los foros de Gentoo terminé por combinar información de varios documentos hasta
tener el sistema más o menos parido como lo tengo ahora.
En primer lugar lo que puse en los USE del "make.conf" fue "softquota mysql"; de este modo al instalar el proftpd se
instalaba el soporte mysql y el soporte para cuotas por software. Si quisieramos cuotas por hardware, esto ya es
cometido del kernel y del sistema de archivos. Procedemos:
1.- Instalamos:
# emerge proftpd
2.- Creamos la base de datos donde vamos a tener los usuarios, el directorio que van a utilizar, su
contraseña, las cuotas, etc, etc...
Si no tenemos contraseña de root (de mysql) haríamos mysql < type="MyISAM;" type="MyISAM;" uid="9999;" gid="9999;" bytes_in_used =" bytes_in_used" bytes_out_used =" bytes_out_used">
Lo primero que hice fue reflexionar sobre qué era lo que quería.
Principalmente quería usuarios virtuales, no de sistema, que pudieran subir archivos como el usuario apache y con un
sistema que no necesariamente tuviera que ser compatible con ldap, por lo tedioso (para mi) que es trabajar con
ldap (supongo que cuando se tiene un poco de soltura con ello es igual, pero prefiero mysql).
No me importaba que el sistema utilizara o no base de datos en realidad, aunque finalmente fue así.
También quería que escribiera los datos como el usuario apache, para no tener problemas de permisos, puesto que en
el sistema instalado el usuario que corre apache es "apache", y el grupo "apache".
El software que elegí finalmente fue "proftpd". Es un gran sistema ftp que tiene una sintaxis similar a la de
apache, que soporta usuarios virtuales y tiene varios módulos.
Buscando un poco de información en los foros de Gentoo terminé por combinar información de varios documentos hasta
tener el sistema más o menos parido como lo tengo ahora.
En primer lugar lo que puse en los USE del "make.conf" fue "softquota mysql"; de este modo al instalar el proftpd se
instalaba el soporte mysql y el soporte para cuotas por software. Si quisieramos cuotas por hardware, esto ya es
cometido del kernel y del sistema de archivos. Procedemos:
1.- Instalamos:
# emerge proftpd
2.- Creamos la base de datos donde vamos a tener los usuarios, el directorio que van a utilizar, su
contraseña, las cuotas, etc, etc...
Si no tenemos contraseña de root (de mysql) haríamos mysql < type="MyISAM;" type="MyISAM;" uid="9999;" gid="9999;" bytes_in_used =" bytes_in_used" bytes_out_used =" bytes_out_used">
16 febrero 2005
Megabits
Una definición muy chula que he encontrado en Wikipedia para recordar siempre la diferencia entre Megabits y Megabytes:
Megabit
De Wikipedia, la enciclopedia libre.
El Megabit (Mbit o Mb) es una unidad de medida de información muy utilizada en las transmisiones de datos de forma telemática. Representa un millón de bits (1.000.000) y con frecuencia se le confunde con el Megabyte que equivale a 220 (1 048 576) bytes.
Cuando se expresa una velocidad de, por ejemplo, 2 Mbits/s se quiere decir que en un segundo se transmiten 2 millones de bits, o lo que es lo mismo, 2.000.000 / 8 = 250.000 bytes.
Suscribirse a:
Entradas (Atom)