No es así necesariamente, pero la semana pasada se celebró el CanSecWest donde los participantes debían romper la seguridad de tres portátiles, uno con Os X otro con Windows Vista, y otro con Ubuntu 7.10.
El triunfador fue Ubuntu y el menos afortunado Os X. Aunque realmente no quiere decir mucho. En un entorno en producción, el atacante tiene más de tres días y no tiene reglas para romper un sistema. Además la incidencia es mucho mayor si es Windows Vista en los entornos de escritorio por ejemplo.
Más información
31 marzo 2008
28 marzo 2008
Gmail en la empresa
Hace relativamente poco tiempo que hemos migrado nuestro correo corporativo a una cuenta premium de Gmail. No puedo dejar de elogiar a Google por su herramienta de correo y por ponerla a disposición del público.
El correo es uno de los temas que más nos traen de cabeza a los administradores de sistemas sobre todo por el control del spam. Creo que Google hasta ahora tiene la herramienta más avanzada en el control de spam de las que he probado hasta ahora, con lo cual nos quitamos una tarea a administrar que era poco fructífera para el trabajo que requería.
El precio es altamente competitivo, porque cuesta 50 dólares por cuenta con un espacio de 25 GB por cuenta. Realmente si tenemos diez cuentas nos cuesta 500 dólares que es la mitad de lo que cuesta un servidor medio decente, con un espacio de 250 GB y una tecnología de clusters detrás que se ríe de cualquier arquitectura RAID que pudiéramos instalar por ese precio.
Por supuesto se pueden utilizar el resto de las aplicaciones de Google, además de descargar el correo mediante POP o IMAP y soporte 24x7.
Está claro que si estamos pensando en corporaciones con miles de cuentas de correo es otro cantar, aunque hay una versión gratuita para empresas, que proporciona menos espacio, menos funcionalidades y por supuesto, menos soporte
El correo es uno de los temas que más nos traen de cabeza a los administradores de sistemas sobre todo por el control del spam. Creo que Google hasta ahora tiene la herramienta más avanzada en el control de spam de las que he probado hasta ahora, con lo cual nos quitamos una tarea a administrar que era poco fructífera para el trabajo que requería.
El precio es altamente competitivo, porque cuesta 50 dólares por cuenta con un espacio de 25 GB por cuenta. Realmente si tenemos diez cuentas nos cuesta 500 dólares que es la mitad de lo que cuesta un servidor medio decente, con un espacio de 250 GB y una tecnología de clusters detrás que se ríe de cualquier arquitectura RAID que pudiéramos instalar por ese precio.
Por supuesto se pueden utilizar el resto de las aplicaciones de Google, además de descargar el correo mediante POP o IMAP y soporte 24x7.
Está claro que si estamos pensando en corporaciones con miles de cuentas de correo es otro cantar, aunque hay una versión gratuita para empresas, que proporciona menos espacio, menos funcionalidades y por supuesto, menos soporte
27 marzo 2008
Virtualizando con VirtualBox en Ubuntu
Supongo que algún día tendré que escribir una guía, como tantas que debería hacer de cómo he hecho ciertas cosas, pero hasta que llegue ese momento lo único que voy a escribir como hacer que el sistema anfitrión haga bridging con el sistema invitado.
Lo encontré en los foros de ubuntu, pero es que llevaba toda la mañana rompiéndome la cabeza con esto.
Simplemente ejecutando estas líneas (con nuestros datos) lo conseguimos:
$ sudo tunctl -t tap0 -u user
$ sudo chmod 666 /dev/net/tun
$ sudo /usr/sbin/brctl addbr br0
$ sudo /sbin/ifconfig eth0 0.0.0.0 promisc
$ sudo /usr/sbin/brctl addif br0 eth0
$ sudo /sbin/dhclient br0
$ sudo /usr/sbin/brctl addif br0 tap0
$ sudo ifconfig tap0 192.168.0.94 up
$ sudo bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp'
$ sudo route add -host 192.168.0.45 dev tap0
$ sudo arp -Ds 192.168.0.45 eth0 pub
hay que tener en cuenta que 192.168.0.45 es la máquina host, y la 94 es la máquina invitado.
Ahora a ver si consigo salir a internet, pero eso será otro tema...
Lo encontré en los foros de ubuntu, pero es que llevaba toda la mañana rompiéndome la cabeza con esto.
Simplemente ejecutando estas líneas (con nuestros datos) lo conseguimos:
$ sudo tunctl -t tap0 -u user
$ sudo chmod 666 /dev/net/tun
$ sudo /usr/sbin/brctl addbr br0
$ sudo /sbin/ifconfig eth0 0.0.0.0 promisc
$ sudo /usr/sbin/brctl addif br0 eth0
$ sudo /sbin/dhclient br0
$ sudo /usr/sbin/brctl addif br0 tap0
$ sudo ifconfig tap0 192.168.0.94 up
$ sudo bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp'
$ sudo route add -host 192.168.0.45 dev tap0
$ sudo arp -Ds 192.168.0.45 eth0 pub
hay que tener en cuenta que 192.168.0.45 es la máquina host, y la 94 es la máquina invitado.
Ahora a ver si consigo salir a internet, pero eso será otro tema...
Cese del proyecto Automatix
Leo en Barrapunto que los desarrolladores de Automatix han decidido cerrar el proyecto para dedicarse a otros menesteres.
Una pena porque yo lo utilizaba para instalar codecs y alguna cosilla más sin tener que dar demasiadas vueltas en el sistema.
De todos modos supongo que es lo normal, si no es un trabajo remunerado, tarde o temprano tienen que dedicarse a otras cosas para poder comer tres veces al día .
Una pena porque yo lo utilizaba para instalar codecs y alguna cosilla más sin tener que dar demasiadas vueltas en el sistema.
De todos modos supongo que es lo normal, si no es un trabajo remunerado, tarde o temprano tienen que dedicarse a otras cosas para poder comer tres veces al día .
26 marzo 2008
Vuelta a Apache
Bueno, pues después de muchas vueltas, hemos decidido volver a retomar Apache en detrimento de Nginx.
La decisión está basada en el sistema de actualización, y en que vamos a desplegar una red nueva, con distintos servidores, y separando servicios que es lo que interesa.
Supongo que iré escribiendo algo de las optimizaciones. De todos modos tengo que probar a ver que tal funciona la kurobox con un nginx y con pylons en casita, aunque de noche la tenga que apagar por el ruido :-)
La decisión está basada en el sistema de actualización, y en que vamos a desplegar una red nueva, con distintos servidores, y separando servicios que es lo que interesa.
Supongo que iré escribiendo algo de las optimizaciones. De todos modos tengo que probar a ver que tal funciona la kurobox con un nginx y con pylons en casita, aunque de noche la tenga que apagar por el ruido :-)
14 marzo 2008
Nginx y el querystring
Hasta ayer he estado utilizando sin (aparentemente) ningún problema Nginx como frontend de un servidor web.
Ayer nos dimos cuenta de que las cosas no estaban pitando demasiado bien en una petición (un poco rara, la verdad) que un programa hace a ese servidor.
Comprobamos que con apache funcionaba, pero que con nginx no, lo cual me llevó ha hacer una regla de reescritura, pero la URL final que quedaba (y que hacía que funcionara) no nos convencía demasiado.
Finalmente encontramos el problema.
Si tenemos una URL como ésta: http://www.dominio.com?loquesea
Apache la transforma en: http://www.dominio.com/?loquesea
Y nginx la transforma en: http://www.dominio.com
Es decir, nginx se carga la parte que va detrás del interrogante, con lo cual "nos desmonta el negocio".
A mi pesar, y hasta que encuentre solución he tenido que volver a levantar apache como frontend, y ahora estoy haciendo maravillas sirviendo imágenes desde otro servidor (con nginx por supuesto), activando el mod_expire de apache para los ficheros html (Este servidor soporta alrededor de un millón de visitas diarias).
Seguimos a la caza del query_string perdido ....
Ayer nos dimos cuenta de que las cosas no estaban pitando demasiado bien en una petición (un poco rara, la verdad) que un programa hace a ese servidor.
Comprobamos que con apache funcionaba, pero que con nginx no, lo cual me llevó ha hacer una regla de reescritura, pero la URL final que quedaba (y que hacía que funcionara) no nos convencía demasiado.
Finalmente encontramos el problema.
Si tenemos una URL como ésta: http://www.dominio.com?loquesea
Apache la transforma en: http://www.dominio.com/?loquesea
Y nginx la transforma en: http://www.dominio.com
Es decir, nginx se carga la parte que va detrás del interrogante, con lo cual "nos desmonta el negocio".
A mi pesar, y hasta que encuentre solución he tenido que volver a levantar apache como frontend, y ahora estoy haciendo maravillas sirviendo imágenes desde otro servidor (con nginx por supuesto), activando el mod_expire de apache para los ficheros html (Este servidor soporta alrededor de un millón de visitas diarias).
Seguimos a la caza del query_string perdido ....
11 marzo 2008
Balanceadores de Carga en Linux
He estado haciendo pruebas con diferentes balanceadores de carga (load balancers), para ver si de esa manera podemos mejorar el servicio de descarga de programas.
Como las máquinas están en producción, he descartado el lvs, pese a que lo tengo en otras máquinas con satisfactorios resultados. Además las máquinas son muy heterogéneas con lo cual no estoy por la labor de estar cambiándoles los nombres para realizar algunas pruebas y luego deshacer todo.
Los balanceadores con los que he hecho las pruebas han sido balanceadores software, y sobre linux por supuesto.
No he hecho todavía pruebas de rendimiento, sino de funcionalidad, facilidad, modularidad, características, etc...
Los que he probado hasta el momento han sido:
Por supuesto otro punto negativo es la ip que veo en los logs de los servidores web, puesto que al actuar como proxy inverso insertan la ip del balanceador. Claro está que con pequeñas modificaciones en los logs se puede recuperar, pero ya supone más procesamiento de logs.
En resumen, no me convencen demasiado, pero hay que probar, de hecho el autor de Crossroads indica que sus benchmarks eran muy similares a las de lvs.
Como las máquinas están en producción, he descartado el lvs, pese a que lo tengo en otras máquinas con satisfactorios resultados. Además las máquinas son muy heterogéneas con lo cual no estoy por la labor de estar cambiándoles los nombres para realizar algunas pruebas y luego deshacer todo.
Los balanceadores con los que he hecho las pruebas han sido balanceadores software, y sobre linux por supuesto.
No he hecho todavía pruebas de rendimiento, sino de funcionalidad, facilidad, modularidad, características, etc...
Los que he probado hasta el momento han sido:
- Pound
- Crossroads
- Nginx (como balanceador)
- Balance
Por supuesto otro punto negativo es la ip que veo en los logs de los servidores web, puesto que al actuar como proxy inverso insertan la ip del balanceador. Claro está que con pequeñas modificaciones en los logs se puede recuperar, pero ya supone más procesamiento de logs.
En resumen, no me convencen demasiado, pero hay que probar, de hecho el autor de Crossroads indica que sus benchmarks eran muy similares a las de lvs.
05 marzo 2008
Descargas de servidores web
Llevo casi mes y medio lidiando con las descargas que tenemos en un servidor web. A raíz de un problema que tuvimos conseguimos detectar varios problemillas secundarios, que parece que ya están arreglados.
Desde hace un tiempo estamos luchando por conseguir detectar por qué han descendido los porcentajes de descargas respecto a las visitas.
Primeramente hay que hacer notar que el porcentaje de visitas lo tomamos de Google analytics, y el de descargas del log del servidor. En el servidor de descargas tenemos nginx.
Hemos probado varias cosas, balancear las descargas entre servidores heterogéneos, nginx, lighttpd, apache; jugar con los keepalive.
He estado dándole vueltas a configurar varnish como proxy cache, pero después de darle vueltas a la idea, me he dado cuenta de que el problema no es el "throughput" sino la descarga propiamente.
Supongo que todo viene del cambio de instalador. Previamente teníamos un instalador web, se descargaba un fichero pequeñito y este se encargaba de descargar los ficheros que necesitara. Ahora tenemos un fichero grande con todos los ficheros, de modo que la instalación es más grande, pero sospecho que a muchos usuarios no les gusta esta solución y cancelan la descarga al ver que descargan un fichero de 12 Mb.
Sigo investigando. Se aceptan ideas :-)
Desde hace un tiempo estamos luchando por conseguir detectar por qué han descendido los porcentajes de descargas respecto a las visitas.
Primeramente hay que hacer notar que el porcentaje de visitas lo tomamos de Google analytics, y el de descargas del log del servidor. En el servidor de descargas tenemos nginx.
Hemos probado varias cosas, balancear las descargas entre servidores heterogéneos, nginx, lighttpd, apache; jugar con los keepalive.
He estado dándole vueltas a configurar varnish como proxy cache, pero después de darle vueltas a la idea, me he dado cuenta de que el problema no es el "throughput" sino la descarga propiamente.
Supongo que todo viene del cambio de instalador. Previamente teníamos un instalador web, se descargaba un fichero pequeñito y este se encargaba de descargar los ficheros que necesitara. Ahora tenemos un fichero grande con todos los ficheros, de modo que la instalación es más grande, pero sospecho que a muchos usuarios no les gusta esta solución y cancelan la descarga al ver que descargan un fichero de 12 Mb.
Sigo investigando. Se aceptan ideas :-)
Suscribirse a:
Entradas (Atom)