Ayuda para diseñar hosting jamonero
15 views
Skip to first unread message
JSO
Jun 7, 2008, 2:04:06 PM6/7/08
to labola.org
Hola a todos.
Esta semana ha sido un pequeño via crucis para ibergour, debido a la
caída del datacenter de ThePlanet donde está albergado nuestro
servidor:
http://tech.slashdot.org/article.pl?sid=08/06/01/1715247
En este momento nuestro servidor "vive" gracias a una serie de
generadores eléctricos de gasoil que los de ThePlanet han puesto como
medida provisional hasta que reparen los destrozos de la explosión
(sí, sí, explosión) que destrozó la instalación eléctrica del lugar.
En fin... a pesar de que no entraba para nada en nuestros planes,
hemos decidido buscar una alternativa de hosting que nos permita
minimizar el impacto de una incidencia de este tipo. Esta semana hemos
estado 3 días sin servicio (y no me extrañaría que todavía tuviésemos
más problemas), y no quiero ni pensar qué habría pasado si esto llega
a ocurrir en plena campaña de navidades.
Me gustaría comentaros nuestras necesidades, las soluciones que estoy
barajando, y leer vuestros comentarios y recomendaciones al respecto.
Nuestras necesidades:
* Tenemos muy poquito tráfico; entre los diferentes sites sumamos unas
50.000 páginas vistas/mes, para un tráfico entrante de 1GB/mes y
saliente de 6GB/mes aprox.
* Desde febrero de 2006, todos los servicios (BD, web, mail...) se
gestionan con un único servidor: un Celeron 1.3 ghz, 512 MB RAM, 60 GB
7200RPM IDE. Una carraca, pero para nuestras necesidades ya chuta la
mar de bien. Nos cuesta $99/mes.
Solución que barajo:
Creo que no tiene sentido que nos pongamos ahora a diseñar una
arquitecura de alta disponibilidad con servidores redundantes ni
historias de esas. Tenemos cosas más urgentes que hacer desde el punto
de vista de negocio. En ese sentido, simplemente me gustaria poder
replicar lo que ya tenemos en una plataforma en la que si un día
nuestro servidor es fulminado, poder montar una réplica del mismo de
forma fácil, y estar operativos lo antes posible.
He estado mirando la infraestructura EC2 de Amazon, y me parece que
puede ser una solución interesante. A priori me parecía algo overkill
para ibergour (esto del EC2 yo lo tenía en mente como algo más bien
pensado para aplicaciones con unas necesidades de escalabilidad
importantes), pero el tema de poder tener una "imagen" de toda tu
máquina almacenada en S3 que en un momento dado puedes poner en
marcha, cargar con tus datos y resucitar, me parece algo realmente muy
potente. Además cualquier día de estos parece que se pondrá en marcha
el servicio de persistencia de datos (si no lo está ya), con lo que ya
mejor que mejor...
Haciendo unos cálculos rápidos con la calculadora de tarifas de AWS
( http://calculator.s3.amazonaws.com/calc5.html ) parece que incluso
podemos ahorrarnos unas pelillas (me sale un coste aprox. de $75/mes
usando una máquina "Small Instance", que ya es bastante más potente
que lo que tenemos ahora).
Después de investigar un poco, he visto algunas cosas de EC2 que son
un tanto problemáticas:
* Gestión de DNSs : el tema de que cada nueva instancia recibe una
nueva IP pública complica la gestión de DNSs en el caso de que por lo
que sea la instancia caiga y haya que reinstanciarla (por cierto, para
los que tengan experiencia en EC2... ¿esto ocurre mucho?)
* Envío de mails : la misma problemática de las IPs hace que te puede
tocar una IP que haya sido utilizada anteriormente para espamear.
Esto, o simplemente el hecho de que la IP pertenezca a un rango de IPs
dinámico hace que el mail enviado por tu máquina tenga muchos números
de ser marcado como SPAM por los servidores de sus destinatarios.
* El tema de la volatilidad de los datos. Esto en realidad no me
parece un problema muy grave... ya tenemos una política de backups
montada, y no tendríamos que hacer nada especial al respecto,
simplemente algun script o algo que nos ayudase a cargar datos de un
backup en una nueva instancia.
Para el tema de los DNSs, parece que hay 2 soluciones típicas: o bien
usar una IP elástica, o bien usar un servicio de DNS dinámico como
dynds.org o easydns.com , tal y como indican estos artículos:
http://spattendesign.com/2007/10/10/updating-dynamic-dns-on-amazon-ec2
http://blog.codesta.com/codesta_weblog/2008/02/amazon-ec2---wh.html
En cualquier caso, desde el punto de vista de garantizar la tolerancia
a catástrofes de un servicio tan fundamental como los DNSs, ¿donde
creéis que sería mejor albergar el servicio de DNS de nuestros
dominios? ¿Alguna experiencia al respecto?
Para resolver el tema del mail, las soluciones que barajo son:
* Para el correo saliente automático (los mails que envía nuestra
aplicación hacia el exterior), usar un servicio de relay hacia un
gateway como authsmtp.com
http://pauldowman.com/2008/02/17/smtp-mail-from-ec2-web-server-setup/
, o si al final usamos dyndns o easydns para el tema de los DNSs, ya
puestos podríamos usar también sus respectivos servicios de gateway
SMTP:
http://www.dyndns.com/services/mailhop/outbound.html
http://support.easydns.com/outbound_smtp.php
* Para el correo entrante, quizás usar los servicios de mail de Google
Apps, y va que chuta.
Bueno, disculpad por el rollo, pero antes de dar el paso quería tirar
un poco de vuestro expertise. Si creéis que se me va la olla con la
solución, si se me están pasando cosas que pueden darme problemas, o
tenéis sugerencias o advertencias de cualquier otro tipo, toda
aportación será bienvenida.
Gracias por todo. May the ham be with you.
Jose
Esta semana ha sido un pequeño via crucis para ibergour, debido a la
caída del datacenter de ThePlanet donde está albergado nuestro
servidor:
http://tech.slashdot.org/article.pl?sid=08/06/01/1715247
En este momento nuestro servidor "vive" gracias a una serie de
generadores eléctricos de gasoil que los de ThePlanet han puesto como
medida provisional hasta que reparen los destrozos de la explosión
(sí, sí, explosión) que destrozó la instalación eléctrica del lugar.
En fin... a pesar de que no entraba para nada en nuestros planes,
hemos decidido buscar una alternativa de hosting que nos permita
minimizar el impacto de una incidencia de este tipo. Esta semana hemos
estado 3 días sin servicio (y no me extrañaría que todavía tuviésemos
más problemas), y no quiero ni pensar qué habría pasado si esto llega
a ocurrir en plena campaña de navidades.
Me gustaría comentaros nuestras necesidades, las soluciones que estoy
barajando, y leer vuestros comentarios y recomendaciones al respecto.
Nuestras necesidades:
* Tenemos muy poquito tráfico; entre los diferentes sites sumamos unas
50.000 páginas vistas/mes, para un tráfico entrante de 1GB/mes y
saliente de 6GB/mes aprox.
* Desde febrero de 2006, todos los servicios (BD, web, mail...) se
gestionan con un único servidor: un Celeron 1.3 ghz, 512 MB RAM, 60 GB
7200RPM IDE. Una carraca, pero para nuestras necesidades ya chuta la
mar de bien. Nos cuesta $99/mes.
Solución que barajo:
Creo que no tiene sentido que nos pongamos ahora a diseñar una
arquitecura de alta disponibilidad con servidores redundantes ni
historias de esas. Tenemos cosas más urgentes que hacer desde el punto
de vista de negocio. En ese sentido, simplemente me gustaria poder
replicar lo que ya tenemos en una plataforma en la que si un día
nuestro servidor es fulminado, poder montar una réplica del mismo de
forma fácil, y estar operativos lo antes posible.
He estado mirando la infraestructura EC2 de Amazon, y me parece que
puede ser una solución interesante. A priori me parecía algo overkill
para ibergour (esto del EC2 yo lo tenía en mente como algo más bien
pensado para aplicaciones con unas necesidades de escalabilidad
importantes), pero el tema de poder tener una "imagen" de toda tu
máquina almacenada en S3 que en un momento dado puedes poner en
marcha, cargar con tus datos y resucitar, me parece algo realmente muy
potente. Además cualquier día de estos parece que se pondrá en marcha
el servicio de persistencia de datos (si no lo está ya), con lo que ya
mejor que mejor...
Haciendo unos cálculos rápidos con la calculadora de tarifas de AWS
( http://calculator.s3.amazonaws.com/calc5.html ) parece que incluso
podemos ahorrarnos unas pelillas (me sale un coste aprox. de $75/mes
usando una máquina "Small Instance", que ya es bastante más potente
que lo que tenemos ahora).
Después de investigar un poco, he visto algunas cosas de EC2 que son
un tanto problemáticas:
* Gestión de DNSs : el tema de que cada nueva instancia recibe una
nueva IP pública complica la gestión de DNSs en el caso de que por lo
que sea la instancia caiga y haya que reinstanciarla (por cierto, para
los que tengan experiencia en EC2... ¿esto ocurre mucho?)
* Envío de mails : la misma problemática de las IPs hace que te puede
tocar una IP que haya sido utilizada anteriormente para espamear.
Esto, o simplemente el hecho de que la IP pertenezca a un rango de IPs
dinámico hace que el mail enviado por tu máquina tenga muchos números
de ser marcado como SPAM por los servidores de sus destinatarios.
* El tema de la volatilidad de los datos. Esto en realidad no me
parece un problema muy grave... ya tenemos una política de backups
montada, y no tendríamos que hacer nada especial al respecto,
simplemente algun script o algo que nos ayudase a cargar datos de un
backup en una nueva instancia.
Para el tema de los DNSs, parece que hay 2 soluciones típicas: o bien
usar una IP elástica, o bien usar un servicio de DNS dinámico como
dynds.org o easydns.com , tal y como indican estos artículos:
http://spattendesign.com/2007/10/10/updating-dynamic-dns-on-amazon-ec2
http://blog.codesta.com/codesta_weblog/2008/02/amazon-ec2---wh.html
En cualquier caso, desde el punto de vista de garantizar la tolerancia
a catástrofes de un servicio tan fundamental como los DNSs, ¿donde
creéis que sería mejor albergar el servicio de DNS de nuestros
dominios? ¿Alguna experiencia al respecto?
Para resolver el tema del mail, las soluciones que barajo son:
* Para el correo saliente automático (los mails que envía nuestra
aplicación hacia el exterior), usar un servicio de relay hacia un
gateway como authsmtp.com
http://pauldowman.com/2008/02/17/smtp-mail-from-ec2-web-server-setup/
, o si al final usamos dyndns o easydns para el tema de los DNSs, ya
puestos podríamos usar también sus respectivos servicios de gateway
SMTP:
http://www.dyndns.com/services/mailhop/outbound.html
http://support.easydns.com/outbound_smtp.php
* Para el correo entrante, quizás usar los servicios de mail de Google
Apps, y va que chuta.
Bueno, disculpad por el rollo, pero antes de dar el paso quería tirar
un poco de vuestro expertise. Si creéis que se me va la olla con la
solución, si se me están pasando cosas que pueden darme problemas, o
tenéis sugerencias o advertencias de cualquier otro tipo, toda
aportación será bienvenida.
Gracias por todo. May the ham be with you.
Jose
Ubaldo Huerta
Jun 8, 2008, 4:09:06 AM6/8/08
to labola.org
Jose
En sentido general, el rapid provisioning de servidores que da amazon
es, imho, un salto qualititativo, como dirian los marxistas, con
relacion al dedicating hosting a la theplanet, o ev1servers, etc. Por
puntos, como el chiki chiki diria que
1- Con elastic IP no tendrias que preocuparte por SMTP spam, etc.
Quoting from a url
http://blog.rightscale.com/2008/03/26/rightscale-supports-the-new-amazon-ec2-elastic-ip-addresses-and-availability-zones/
"For inbound SMTP traffic the static IP address ensures that mailers
around the world can safely deliver the traffic across instance
changes. For outbound SMTP traffic the static IP ensures that spam
filters don’t discard the email because the IP is listed as dynamic or
because of a prior user that sent out spam".
Asi y todo, yo añadiria SPF records, etc para mayor seguridad.
Incomming email en Google app for domains es buena idea, yo lo haria
con la conciencia intranquila de saber que google cada dia controla
mas todo, pero terminaria capitulando para evitarme IMAP backup,
recovery, etc en caso que se muera el servidor.
2- Usaria un servicio dns externo aputando A records a estatic IP, con
DNS servers en todas las latitudes, como dyndns. Tengo muy buena
experiencia con dyndns.
3- Probablemente haria un mysql dump todas las noches a s3 para
resucitar el muerto en caso que se me caiga la instancia. Ah, tendria
el latest image instance (cada vez que haga cambios) y la intancia
anterior, guardaditas en s3 por si tengo que resucitar el muerto
4- Como tengo mi mente en GAP en estos dias no he visto si esta
disponible lo del persistente storage en EC2 (y si no tiene mucha
latencia) para usarlo como HD de mysql. Este punto lo miro luego por
curiosidad. Logicamente creo que tranquiliza saber que si falla power
supply, por ejemplo, con reiniciar bastaria. Sin persistente storage
habria que revivir al frankestein, y eso lleva su tiempo, a menos que
te quieras gastar tener otra instancia igaulita, con mysql de esclavo,
lista para reasignarle el elastic IP, en caso que muera el master
Sort!
-Ubaldo
> (http://calculator.s3.amazonaws.com/calc5.html) parece que incluso
En sentido general, el rapid provisioning de servidores que da amazon
es, imho, un salto qualititativo, como dirian los marxistas, con
relacion al dedicating hosting a la theplanet, o ev1servers, etc. Por
puntos, como el chiki chiki diria que
1- Con elastic IP no tendrias que preocuparte por SMTP spam, etc.
Quoting from a url
http://blog.rightscale.com/2008/03/26/rightscale-supports-the-new-amazon-ec2-elastic-ip-addresses-and-availability-zones/
"For inbound SMTP traffic the static IP address ensures that mailers
around the world can safely deliver the traffic across instance
changes. For outbound SMTP traffic the static IP ensures that spam
filters don’t discard the email because the IP is listed as dynamic or
because of a prior user that sent out spam".
Asi y todo, yo añadiria SPF records, etc para mayor seguridad.
Incomming email en Google app for domains es buena idea, yo lo haria
con la conciencia intranquila de saber que google cada dia controla
mas todo, pero terminaria capitulando para evitarme IMAP backup,
recovery, etc en caso que se muera el servidor.
2- Usaria un servicio dns externo aputando A records a estatic IP, con
DNS servers en todas las latitudes, como dyndns. Tengo muy buena
experiencia con dyndns.
3- Probablemente haria un mysql dump todas las noches a s3 para
resucitar el muerto en caso que se me caiga la instancia. Ah, tendria
el latest image instance (cada vez que haga cambios) y la intancia
anterior, guardaditas en s3 por si tengo que resucitar el muerto
4- Como tengo mi mente en GAP en estos dias no he visto si esta
disponible lo del persistente storage en EC2 (y si no tiene mucha
latencia) para usarlo como HD de mysql. Este punto lo miro luego por
curiosidad. Logicamente creo que tranquiliza saber que si falla power
supply, por ejemplo, con reiniciar bastaria. Sin persistente storage
habria que revivir al frankestein, y eso lleva su tiempo, a menos que
te quieras gastar tener otra instancia igaulita, con mysql de esclavo,
lista para reasignarle el elastic IP, en caso que muera el master
Sort!
-Ubaldo
> podemos ahorrarnos unas pelillas (me sale un coste aprox. de $75/mes
> usando una máquina "Small Instance", que ya es bastante más potente
> que lo que tenemos ahora).
>
> Después de investigar un poco, he visto algunas cosas de EC2 que son
> un tanto problemáticas:
> * Gestión de DNSs : el tema de que cada nueva instancia recibe una
> nueva IP pública complica la gestión de DNSs en el caso de que por lo
> que sea la instancia caiga y haya que reinstanciarla (por cierto, para
> los que tengan experiencia en EC2... ¿esto ocurre mucho?)
> * Envío de mails : la misma problemática de las IPs hace que te puede
> tocar una IP que haya sido utilizada anteriormente para espamear.
> Esto, o simplemente el hecho de que la IP pertenezca a un rango de IPs
> dinámico hace que el mail enviado por tu máquina tenga muchos números
> de ser marcado como SPAM por los servidores de sus destinatarios.
> * El tema de la volatilidad de los datos. Esto en realidad no me
> parece un problema muy grave... ya tenemos una política de backups
> montada, y no tendríamos que hacer nada especial al respecto,
> simplemente algun script o algo que nos ayudase a cargar datos de un
> backup en una nueva instancia.
>
> Para el tema de los DNSs, parece que hay 2 soluciones típicas: o bien
> usar una IP elástica, o bien usar un servicio de DNS dinámico como
> dynds.org o easydns.com , tal y como indican estos artículos:http://spattendesign.com/2007/10/10/updating-dynamic-dns-on-amazon-ec2http://blog.codesta.com/codesta_weblog/2008/02/amazon-ec2---wh.html
> usando una máquina "Small Instance", que ya es bastante más potente
> que lo que tenemos ahora).
>
> Después de investigar un poco, he visto algunas cosas de EC2 que son
> un tanto problemáticas:
> * Gestión de DNSs : el tema de que cada nueva instancia recibe una
> nueva IP pública complica la gestión de DNSs en el caso de que por lo
> que sea la instancia caiga y haya que reinstanciarla (por cierto, para
> los que tengan experiencia en EC2... ¿esto ocurre mucho?)
> * Envío de mails : la misma problemática de las IPs hace que te puede
> tocar una IP que haya sido utilizada anteriormente para espamear.
> Esto, o simplemente el hecho de que la IP pertenezca a un rango de IPs
> dinámico hace que el mail enviado por tu máquina tenga muchos números
> de ser marcado como SPAM por los servidores de sus destinatarios.
> * El tema de la volatilidad de los datos. Esto en realidad no me
> parece un problema muy grave... ya tenemos una política de backups
> montada, y no tendríamos que hacer nada especial al respecto,
> simplemente algun script o algo que nos ayudase a cargar datos de un
> backup en una nueva instancia.
>
> Para el tema de los DNSs, parece que hay 2 soluciones típicas: o bien
> usar una IP elástica, o bien usar un servicio de DNS dinámico como
>
> En cualquier caso, desde el punto de vista de garantizar la tolerancia
> a catástrofes de un servicio tan fundamental como los DNSs, ¿donde
> creéis que sería mejor albergar el servicio de DNS de nuestros
> dominios? ¿Alguna experiencia al respecto?
>
> Para resolver el tema del mail, las soluciones que barajo son:
> * Para el correo saliente automático (los mails que envía nuestra
> aplicación hacia el exterior), usar un servicio de relay hacia un
> gateway como authsmtp.comhttp://pauldowman.com/2008/02/17/smtp-mail-from-ec2-web-server-setup/
> En cualquier caso, desde el punto de vista de garantizar la tolerancia
> a catástrofes de un servicio tan fundamental como los DNSs, ¿donde
> creéis que sería mejor albergar el servicio de DNS de nuestros
> dominios? ¿Alguna experiencia al respecto?
>
> Para resolver el tema del mail, las soluciones que barajo son:
> * Para el correo saliente automático (los mails que envía nuestra
> aplicación hacia el exterior), usar un servicio de relay hacia un
> , o si al final usamos dyndns o easydns para el tema de los DNSs, ya
> puestos podríamos usar también sus respectivos servicios de gateway
> SMTP:http://www.dyndns.com/services/mailhop/outbound.htmlhttp://support.easydns.com/outbound_smtp.php
> puestos podríamos usar también sus respectivos servicios de gateway
Joaquin Cuenca Abela
Jun 9, 2008, 3:58:47 AM6/9/08
to lab...@googlegroups.com
y que tal simplemente tener dos servidores, con dos companyias
distintas? en el segundo, que no usarias, pones mysql como esclavo del
de theplanet, y si theplanet cae cambias la DNS (ten el TTL a algo
razonable, 1h o menos si es posible).
distintas? en el segundo, que no usarias, pones mysql como esclavo del
de theplanet, y si theplanet cae cambias la DNS (ten el TTL a algo
razonable, 1h o menos si es posible).
Downtime minimo, sencillo de poner en practica, y razonablemente
barato (150$ en lugar de 75$ al mes)
2008/6/8 Ubaldo Huerta <uba...@gmail.com>:
--
Joaquin Cuenca Abela
JSO
Jun 9, 2008, 7:39:26 AM6/9/08
to labola.org
Buenas, Ubaldo y Joaquín
Gracias por vuestros comentarios... creo que al final iré por meterme
en EC2. Tal y como comenta Ubaldo, creo que el asunto del provisioning
on-demand nos dará una flexibilidad y tranquilidad difíciles de
igualar.
Os mantendremos informados...
JSO
On Jun 9, 9:58 am, "Joaquin Cuenca Abela" <e98cu...@gmail.com> wrote:
> y que tal simplemente tener dos servidores, con dos companyias
> distintas? en el segundo, que no usarias, pones mysql como esclavo del
> de theplanet, y si theplanet cae cambias la DNS (ten el TTL a algo
> razonable, 1h o menos si es posible).
>
> Downtime minimo, sencillo de poner en practica, y razonablemente
> barato (150$ en lugar de 75$ al mes)
>
> 2008/6/8 Ubaldo Huerta <uba...@gmail.com>:
>
>
>
>
>
> > Jose
>
> > En sentido general, el rapid provisioning de servidores que da amazon
> > es, imho, un salto qualititativo, como dirian los marxistas, con
> > relacion al dedicating hosting a la theplanet, o ev1servers, etc. Por
> > puntos, como el chiki chiki diria que
>
> > 1- Con elastic IP no tendrias que preocuparte por SMTP spam, etc.
> > Quoting from a url
> >http://blog.rightscale.com/2008/03/26/rightscale-supports-the-new-ama...
> >> dynds.org o easydns.com , tal y como indican estos artículos:http://spattendesign.com/2007/10/10/updating-dynamic-dns-on-amazon-ec...
Gracias por vuestros comentarios... creo que al final iré por meterme
en EC2. Tal y como comenta Ubaldo, creo que el asunto del provisioning
on-demand nos dará una flexibilidad y tranquilidad difíciles de
igualar.
Os mantendremos informados...
JSO
On Jun 9, 9:58 am, "Joaquin Cuenca Abela" <e98cu...@gmail.com> wrote:
> y que tal simplemente tener dos servidores, con dos companyias
> distintas? en el segundo, que no usarias, pones mysql como esclavo del
> de theplanet, y si theplanet cae cambias la DNS (ten el TTL a algo
> razonable, 1h o menos si es posible).
>
> Downtime minimo, sencillo de poner en practica, y razonablemente
> barato (150$ en lugar de 75$ al mes)
>
> 2008/6/8 Ubaldo Huerta <uba...@gmail.com>:
>
>
>
>
>
> > Jose
>
> > En sentido general, el rapid provisioning de servidores que da amazon
> > es, imho, un salto qualititativo, como dirian los marxistas, con
> > relacion al dedicating hosting a la theplanet, o ev1servers, etc. Por
> > puntos, como el chiki chiki diria que
>
> > 1- Con elastic IP no tendrias que preocuparte por SMTP spam, etc.
> > Quoting from a url
>
> >> En cualquier caso, desde el punto de vista de garantizar la tolerancia
> >> a catástrofes de un servicio tan fundamental como los DNSs, ¿donde
> >> creéis que sería mejor albergar el servicio de DNS de nuestros
> >> dominios? ¿Alguna experiencia al respecto?
>
> >> Para resolver el tema del mail, las soluciones que barajo son:
> >> * Para el correo saliente automático (los mails que envía nuestra
> >> aplicación hacia el exterior), usar un servicio de relay hacia un
> >> gateway como authsmtp.comhttp://pauldowman.com/2008/02/17/smtp-mail-from-ec2-web-server-setup/
> >> , o si al final usamos dyndns o easydns para el tema de los DNSs, ya
> >> puestos podríamos usar también sus respectivos servicios de gateway
> >> SMTP:http://www.dyndns.com/services/mailhop/outbound.htmlhttp://support.ea...
> >> En cualquier caso, desde el punto de vista de garantizar la tolerancia
> >> a catástrofes de un servicio tan fundamental como los DNSs, ¿donde
> >> creéis que sería mejor albergar el servicio de DNS de nuestros
> >> dominios? ¿Alguna experiencia al respecto?
>
> >> Para resolver el tema del mail, las soluciones que barajo son:
> >> * Para el correo saliente automático (los mails que envía nuestra
> >> aplicación hacia el exterior), usar un servicio de relay hacia un
> >> gateway como authsmtp.comhttp://pauldowman.com/2008/02/17/smtp-mail-from-ec2-web-server-setup/
> >> , o si al final usamos dyndns o easydns para el tema de los DNSs, ya
> >> puestos podríamos usar también sus respectivos servicios de gateway
Eduardo Manchon
Jun 9, 2008, 7:50:45 AM6/9/08
to lab...@googlegroups.com
No puedo comentar mucho de temas técnicos, pero si decir que para el
correo entrante Google Apps es una maravilla, puedes crear nuevas
cuentas de correo o listas de correo en un segundo y gestionarlas muy
facilmente, especialmente interesante porque en un segundo tienes
listas cuentas de correo para temas especificos, en la ayuda indicamos
pass...@panoramio.com para problemas con la contraseña, por ejemplo,
y asi con un sencillo filtro en un segundo ves los temas urgentes de
soporte y los que no. No es que sea dificil crear cuentas, pero si es
mucho mas comodo y la misma persona que gestiona el soporte lo puede
hacer sin tener que pedir ayuda al que configura el servidor.
correo entrante Google Apps es una maravilla, puedes crear nuevas
cuentas de correo o listas de correo en un segundo y gestionarlas muy
facilmente, especialmente interesante porque en un segundo tienes
listas cuentas de correo para temas especificos, en la ayuda indicamos
pass...@panoramio.com para problemas con la contraseña, por ejemplo,
y asi con un sencillo filtro en un segundo ves los temas urgentes de
soporte y los que no. No es que sea dificil crear cuentas, pero si es
mucho mas comodo y la misma persona que gestiona el soporte lo puede
hacer sin tener que pedir ayuda al que configura el servidor.
Eso si, recomiendo crear mailing lists en lugar de cuentas
individuales aunque luego se usen individualmente, las cuentas
individuales para luego forwardearlas tienes que darle una contraseña,
hacer sign-in en esa cuenta y hacer que forwardee. Sin embargo con las
mailing list es solo indicar el nuevo e-mail y a donde debe
forwardear, se hace todo en Google Apps.
Edu
2008/6/7 JSO <jsa...@gmail.com>:
--
-------------------------------------------------
Panoramio.com - http://www.panoramio.com: Photos of the World
JSO
Jun 27, 2008, 12:51:54 PM6/27/08
to labola.org
Probando el sistema de mail, parece que las IPs elásticas son
susceptibles de estar vetadas por determinados servidores de correo,
simplemente por el hecho de pertenecer a rangos de IPs definidos como
dinámicos.
He aquí la cabecera de un mail que envié desde mi instancia, y me ha
llegado rebotado por el servidor de mail de mi cuenta en evolucy.com
La IP que figura ahí [75.101.140.180] es la IP elástica que me ha
tocado.
#####################
This is the mail system at host domU-12-31-38-00-
A2-08.compute-1.internal.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<jsa...@evolucy.com>: host evolucy.com[64.62.148.34] said:
550-"JunkMail
rejected - ec2-75-101-140-180.compute-1.amazonaws.com
550-(domU-12-31-38-00-A2-08.compute-1.internal) [75.101.140.180] is
in an
RBL, 550 see http://www.spamhaus.org/query/bl?ip=75.101.140.180"
(in reply
to RCPT TO command)
Final-Recipient: rfc822; jsa...@evolucy.com
Action: failed
Status: 5.0.0
Remote-MTA: dns; evolucy.com
Diagnostic-Code: smtp; 550-"JunkMail rejected -
ec2-75-101-140-180.compute-1.amazonaws.com
550-(domU-12-31-38-00-A2-08.compute-1.internal) [75.101.140.180] is
in an
RBL, 550 see http://www.spamhaus.org/query/bl?ip=75.101.140.180"
###################
Así que parece que tendremos que buscar un relay para el correo
saliente. ¿Alguien tiene alguna recomendación al respecto?
Por lo demás, de momento el montaje en EC2 va bastante fino.
Por cierto, no recomiendo a nadie que registre sus dominios en
networksolutions.com :
Me tiré 1 semana intentando cambiar los nameservers de ibergour.de a
los servidores de dyndns.com
Tras no conseguirlo y acabar hasta las pelotas de su soporte técnico,
me he tirado 2 semanas más para conseguir hacer el transfer del
dominio a otro registrador.
El soporte por mail contesta un mail al día, siempre a base de
mensajes enlatados tirando balones fuera.
El soporte telefónico también lamentable, llegaron incluso a decirme
que para dominios .DE no se podía hacer el transfer a otro
registrador. Cabrones.
Técnicamente, la única cosa que todavía tengo que resolver es el tema
de los certificados SSL. Os comento: en el mismo servidor albergamos
los diferentes dominios de la tienda: ibergour.com, ibergour.fr,
ibergour.co.uk
Como sabréis, un certificado SSL estándar permite autenticar un único
dominio y actúa sobre una IP única, es decir: si quiero cifrar el
tráfico de 2 dominios diferentes en la misma máquina, necesito 2 IPs
públicas para que cada dominio se sirva desde su IP, y 2 certificados
SSL diferentes, uno para cada dominio. En la máquina actual es así
como lo tenemos. Mi idea era solicitar 3 IPs elásticas, hacer que las
3 apuntasen a la misma instancia, y usar los mismos certificados que
ya tenemos.
Putada: EC2 no permite que 2 IPs elásticas apunten a la misma
instancia.
Posible solución: tener 3 instancias (una para cada dominio), pero en
nuestro caso es una "overkillada" de cojones, y mutliplica el coste
por 3.
Pero parece que existe una cosa llamada certificados UCC o MDC (Multi-
Domain Certificate), que nos permitirán hacer el juego. En godaddy los
venden a precios razonables. ¿Alguien ha jugado alguna vez con un
certificado de estos? Lo tengo que probar con cariño, porque como
empiecen los navegadores a dar warnings de seguridad en el checkout,
menuda risa...
Seguiremos informando...
On Jun 8, 10:09 am, Ubaldo Huerta <uba...@gmail.com> wrote:
> Jose
>
> En sentido general, el rapid provisioning de servidores que da amazon
> es, imho, un salto qualititativo, como dirian los marxistas, con
> relacion al dedicating hosting a la theplanet, o ev1servers, etc. Por
> puntos, como el chiki chiki diria que
>
> 1- Con elastic IP no tendrias que preocuparte por SMTP spam, etc.
> Quoting from a urlhttp://blog.rightscale.com/2008/03/26/rightscale-supports-the-new-ama...
> > dynds.org o easydns.com , tal y como indican estos artículos:http://spattendesign.com/2007/10/10/updating-dynamic-dns-on-amazon-ec...
susceptibles de estar vetadas por determinados servidores de correo,
simplemente por el hecho de pertenecer a rangos de IPs definidos como
dinámicos.
He aquí la cabecera de un mail que envié desde mi instancia, y me ha
llegado rebotado por el servidor de mail de mi cuenta en evolucy.com
La IP que figura ahí [75.101.140.180] es la IP elástica que me ha
tocado.
#####################
This is the mail system at host domU-12-31-38-00-
A2-08.compute-1.internal.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<jsa...@evolucy.com>: host evolucy.com[64.62.148.34] said:
550-"JunkMail
rejected - ec2-75-101-140-180.compute-1.amazonaws.com
550-(domU-12-31-38-00-A2-08.compute-1.internal) [75.101.140.180] is
in an
RBL, 550 see http://www.spamhaus.org/query/bl?ip=75.101.140.180"
(in reply
to RCPT TO command)
Final-Recipient: rfc822; jsa...@evolucy.com
Action: failed
Status: 5.0.0
Remote-MTA: dns; evolucy.com
Diagnostic-Code: smtp; 550-"JunkMail rejected -
ec2-75-101-140-180.compute-1.amazonaws.com
550-(domU-12-31-38-00-A2-08.compute-1.internal) [75.101.140.180] is
in an
RBL, 550 see http://www.spamhaus.org/query/bl?ip=75.101.140.180"
###################
Así que parece que tendremos que buscar un relay para el correo
saliente. ¿Alguien tiene alguna recomendación al respecto?
Por lo demás, de momento el montaje en EC2 va bastante fino.
Por cierto, no recomiendo a nadie que registre sus dominios en
networksolutions.com :
Me tiré 1 semana intentando cambiar los nameservers de ibergour.de a
los servidores de dyndns.com
Tras no conseguirlo y acabar hasta las pelotas de su soporte técnico,
me he tirado 2 semanas más para conseguir hacer el transfer del
dominio a otro registrador.
El soporte por mail contesta un mail al día, siempre a base de
mensajes enlatados tirando balones fuera.
El soporte telefónico también lamentable, llegaron incluso a decirme
que para dominios .DE no se podía hacer el transfer a otro
registrador. Cabrones.
Técnicamente, la única cosa que todavía tengo que resolver es el tema
de los certificados SSL. Os comento: en el mismo servidor albergamos
los diferentes dominios de la tienda: ibergour.com, ibergour.fr,
ibergour.co.uk
Como sabréis, un certificado SSL estándar permite autenticar un único
dominio y actúa sobre una IP única, es decir: si quiero cifrar el
tráfico de 2 dominios diferentes en la misma máquina, necesito 2 IPs
públicas para que cada dominio se sirva desde su IP, y 2 certificados
SSL diferentes, uno para cada dominio. En la máquina actual es así
como lo tenemos. Mi idea era solicitar 3 IPs elásticas, hacer que las
3 apuntasen a la misma instancia, y usar los mismos certificados que
ya tenemos.
Putada: EC2 no permite que 2 IPs elásticas apunten a la misma
instancia.
Posible solución: tener 3 instancias (una para cada dominio), pero en
nuestro caso es una "overkillada" de cojones, y mutliplica el coste
por 3.
Pero parece que existe una cosa llamada certificados UCC o MDC (Multi-
Domain Certificate), que nos permitirán hacer el juego. En godaddy los
venden a precios razonables. ¿Alguien ha jugado alguna vez con un
certificado de estos? Lo tengo que probar con cariño, porque como
empiecen los navegadores a dar warnings de seguridad en el checkout,
menuda risa...
Seguiremos informando...
On Jun 8, 10:09 am, Ubaldo Huerta <uba...@gmail.com> wrote:
> Jose
>
> En sentido general, el rapid provisioning de servidores que da amazon
> es, imho, un salto qualititativo, como dirian los marxistas, con
> relacion al dedicating hosting a la theplanet, o ev1servers, etc. Por
> puntos, como el chiki chiki diria que
>
> 1- Con elastic IP no tendrias que preocuparte por SMTP spam, etc.
>
> > En cualquier caso, desde el punto de vista de garantizar la tolerancia
> > a catástrofes de un servicio tan fundamental como los DNSs, ¿donde
> > creéis que sería mejor albergar el servicio de DNS de nuestros
> > dominios? ¿Alguna experiencia al respecto?
>
> > Para resolver el tema del mail, las soluciones que barajo son:
> > * Para el correo saliente automático (los mails que envía nuestra
> > aplicación hacia el exterior), usar un servicio de relay hacia un
> > gateway como authsmtp.comhttp://pauldowman.com/2008/02/17/smtp-mail-from-ec2-web-server-setup/
> > , o si al final usamos dyndns o easydns para el tema de los DNSs, ya
> > puestos podríamos usar también sus respectivos servicios de gateway
> > SMTP:http://www.dyndns.com/services/mailhop/outbound.htmlhttp://support.ea...
> > En cualquier caso, desde el punto de vista de garantizar la tolerancia
> > a catástrofes de un servicio tan fundamental como los DNSs, ¿donde
> > creéis que sería mejor albergar el servicio de DNS de nuestros
> > dominios? ¿Alguna experiencia al respecto?
>
> > Para resolver el tema del mail, las soluciones que barajo son:
> > * Para el correo saliente automático (los mails que envía nuestra
> > aplicación hacia el exterior), usar un servicio de relay hacia un
> > gateway como authsmtp.comhttp://pauldowman.com/2008/02/17/smtp-mail-from-ec2-web-server-setup/
> > , o si al final usamos dyndns o easydns para el tema de los DNSs, ya
> > puestos podríamos usar también sus respectivos servicios de gateway
Ubaldo Huerta
Jul 5, 2008, 3:13:11 PM7/5/08
to labola.org
Me he pasado un par de semanas en Cuba, en total abstinencia de
internet. Ni una vez me conecte. No tengo experiencia en el multi-
domain certificate que mencionas pero con relacion al tema del spam
filtering, te puede recomendar el SPIF record http://www.openspf.org/
Yo he salido mas de una vez de spam lists con SPIF records.
Sort!
On Jun 27, 6:51 pm, JSO <jsan...@gmail.com> wrote:
> Probando el sistema de mail, parece que las IPs elásticas son
> susceptibles de estar vetadas por determinados servidores de correo,
> simplemente por el hecho de pertenecer a rangos de IPs definidos como
> dinámicos.
> He aquí la cabecera de un mail que envié desde mi instancia, y me ha
> llegado rebotado por el servidor de mail de mi cuenta en evolucy.com
> La IP que figura ahí [75.101.140.180] es la IP elástica que me ha
> tocado.
>
> #####################
> This is the mail system at host domU-12-31-38-00-
> A2-08.compute-1.internal.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
> The mail system
>
> ...
>
> read more »
internet. Ni una vez me conecte. No tengo experiencia en el multi-
domain certificate que mencionas pero con relacion al tema del spam
filtering, te puede recomendar el SPIF record http://www.openspf.org/
Yo he salido mas de una vez de spam lists con SPIF records.
Sort!
On Jun 27, 6:51 pm, JSO <jsan...@gmail.com> wrote:
> Probando el sistema de mail, parece que las IPs elásticas son
> susceptibles de estar vetadas por determinados servidores de correo,
> simplemente por el hecho de pertenecer a rangos de IPs definidos como
> dinámicos.
> He aquí la cabecera de un mail que envié desde mi instancia, y me ha
> llegado rebotado por el servidor de mail de mi cuenta en evolucy.com
> La IP que figura ahí [75.101.140.180] es la IP elástica que me ha
> tocado.
>
> #####################
> This is the mail system at host domU-12-31-38-00-
> A2-08.compute-1.internal.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
> The mail system
>
> <jsan...@evolucy.com>: host evolucy.com[64.62.148.34] said:
> 550-"JunkMail
> rejected - ec2-75-101-140-180.compute-1.amazonaws.com
> 550-(domU-12-31-38-00-A2-08.compute-1.internal) [75.101.140.180] is
> in an
> RBL, 550 seehttp://www.spamhaus.org/query/bl?ip=75.101.140.180"
> 550-"JunkMail
> rejected - ec2-75-101-140-180.compute-1.amazonaws.com
> 550-(domU-12-31-38-00-A2-08.compute-1.internal) [75.101.140.180] is
> in an
> (in reply
> to RCPT TO command)
>
> Final-Recipient: rfc822; jsan...@evolucy.com
> to RCPT TO command)
>
> Action: failed
> Status: 5.0.0
> Remote-MTA: dns; evolucy.com
> Diagnostic-Code: smtp; 550-"JunkMail rejected -
> ec2-75-101-140-180.compute-1.amazonaws.com
> 550-(domU-12-31-38-00-A2-08.compute-1.internal) [75.101.140.180] is
> in an
> RBL, 550 seehttp://www.spamhaus.org/query/bl?ip=75.101.140.180"
> Status: 5.0.0
> Remote-MTA: dns; evolucy.com
> Diagnostic-Code: smtp; 550-"JunkMail rejected -
> ec2-75-101-140-180.compute-1.amazonaws.com
> 550-(domU-12-31-38-00-A2-08.compute-1.internal) [75.101.140.180] is
> in an
>
> read more »
Reply all
Reply to author
Forward
0 new messages