Buenas esta es la continuacion de la parte #1 ... seguimos...
# ab -c 5 -t 60 http://www.vicente-navarro.com/blog/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.vicente-navarro.com (be patient)
Finished 23 requests
Server Software: Apache/2.2.3
Server Hostname: www.vicente-navarro.com
Server Port: 80
Document Path: /blog/
Document Length: 63231 bytes
Concurrency Level: 5
Time taken for tests: 60.523663 seconds
Complete requests: 23
Failed requests: 21
(Connect: 0, Length: 21, Exceptions: 0)
Write errors: 0
Total transferred: 1510651 bytes
HTML transferred: 1505035 bytes
Requests per second: 0.38 [#/sec] (mean)
Time per request: 13157.318 [ms] (mean)
Time per request: 2631.464 [ms] (mean, across all concurrent requests)
Transfer rate: 24.37 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 2319 11847 9921.7 9117 40440
Waiting: 1251 5547 7283.9 2763 30366
Total: 2319 11847 9921.7 9117 40440
Percentage of the requests served within a certain time (ms)
50% 8977
66% 14074
75% 15522
80% 18804
90% 27300
95% 29838
98% 40440
99% 40440
100% 40440 (longest request)
Volvamos a repetir la prueba tras habilitar el plugin para WordPress WP Super Cache, del que ya hablamos en Comprimir y cachear las páginas generadas por WordPress y veremos que de las decepcionantes 23 peticiones servidas pasamos a nada menos que 8193 peticiones con un tiempo de espera máximos de 71ms:
# ab -c 5 -t 60 http://www.vicente-navarro.com/blog/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.vicente-navarro.com (be patient)
Completed 5000 requests
Finished 8193 requests
Server Software: Apache/2.2.3
Server Hostname: www.vicente-navarro.com
Server Port: 80
Document Path: /blog/
Document Length: 63301 bytes
Concurrency Level: 5
Time taken for tests: 60.358 seconds
Complete requests: 8193
Failed requests: 0
Write errors: 0
Total transferred: 520941496 bytes
HTML transferred: 518752897 bytes
Requests per second: 136.55 [#/sec] (mean)
Time per request: 36.617 [ms] (mean)
Time per request: 7.323 [ms] (mean, across all concurrent requests)
Transfer rate: 8478.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 3 2.5 3 26
Processing: 13 32 4.1 33 69
Waiting: 2 8 4.4 8 49
Total: 18 36 4.1 36 71
Percentage of the requests served within a certain time (ms)
50% 36
66% 37
75% 38
80% 39
90% 41
95% 43
98% 45
99% 46
100% 71 (longest request)
¡Ah! Y si permitimos la compresión con la opción -H "Accept-Encoding: gzip", el resultado es incluso más espectacular, llegándose a las 16122 peticiones servidas, aunque ahora la diferencia ya era previsible, ya que es debida sólo a que ahora se sirven menos datos:
# ab -c 5 -t 60 -H "Accept-Encoding: gzip" http://www.vicente-navarro.com/blog/
[...]
Complete requests: 16122
[...]
Por supuesto, lo ideal es hacer estas pruebas desde otro sistema de Internet, donde el cuello de botella del ancho de banda se note, pero estas pruebas desde la LAN también pueden ser muy ilustrativas y útiles para entender por dónde cojea nuestre servidor web.
El servidor de correo
Los dos servicios básicos de un hosting son el servidor web y el servidor de correo, así que de nuestro HC también podríamos esperar que fuera un buen servidor de correo.
Sin embargo, quitando la parte de que un servidor de correo como sendmail o exim puede ser realmente difícil de configurar, la realidad es que en la actualidad, siendo el spam un problema tan grande en Internet, un servidor de SMTP funcionando desde una red de usuarios finales con IPs dinámicas es candidato seguro a ser ignorado por casi todos los servidores de correo de Internet.
E incluso aunque nuestra IP fuera fija, al no ser la IP conocida de un ISP profesional, lo más probable es que nuestros correos también fueran rechazados por un alto porcentaje de servidores destino. Además, no podremos cambiar la resolución inversa de la IP, algo que muchos servidores de correo verifican.
Por ejemplo, imaginemos que instalo el paquete exim4, y lo configuro con “dpkg-reconfigure exim4-config” como servidor SMTP del dominio hostingcasero.homelinux.org (para direcciones como [email protected]).
Elegimos que el “General type of mail configuration” sea “internet site“
En “System mail name” ponemos hostingcasero.homelinux.org
El “Domains to relay mail for” en principio lo podemos dejar vacío, así como el “Machines to relay mail for“. El “Keep number of DNS-queries minimal (Dial-on-Demand)?” no tiene mayor importancia en nuestra configuración, así como el “Delivery method for local mail” y el “Split configuration into small files?“, que ya van según las preferencias de cada uno.
Pues bien, a finalizar me encuentro con que si intento enviar un e-mail a Hotmail me dice que no acepta mi correo porque mi IP no es de fiar:
# mail [email protected] < /tmp/correo.txt
delivering 1JY4zH-0001ym-VM
R: dnslookup for [email protected]
T: remote_smtp for [email protected]
Connecting to mx2.hotmail.com [65.54.244.168]:25 ... connected
SMTP<< 220 bay0-mc2-f2.bay0.hotmail.com Sending unsolicited commercial or bulk e-mail to Microsoft's computer network is prohibited. Other restrictions are found at http://privacy.msn.com/Anti-spam/. Violations will result in use of equipment located in California and other states. Sat, 8 Mar 2008 11:45:44 -0800
SMTP>> EHLO localhost
SMTP<< 250-bay0-mc2-f2.bay0.hotmail.com (3.5.0.22) Hello [81.39.245.151]
250-SIZE 29696000
250-PIPELINING
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-AUTH LOGIN
250-AUTH=LOGIN
250 OK
SMTP>> MAIL FROM:<[email protected]> SIZE=1367
SMTP>> RCPT TO:<[email protected]>
SMTP>> DATA
SMTP<< 550 DY-001 Mail rejected by Windows Live Hotmail for policy reasons. We generally do not accept email from dynamic IP's as they are not typically used to deliver unauthenticated SMTP e-mail to an Internet mail server. http://www.spamhaus.org maintains lists of dynamic and residential IP addresses. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support
SMTP>> QUIT
LOG: MAIN
** [email protected] R=dnslookup T=remote_smtp: SMTP error from remote mail server after MAIL FROM:<[email protected]> SIZE=1367: host mx2.hotmail.com [65.54.244.168]: 550 DY-001 Mail rejected by Windows Live Hotmail for policy reasons. We generally do not accept email from dynamic IP's as they are not typically used to deliver unauthenticated SMTP e-mail to an Internet mail server. http://www.spamhaus.org maintains lists of dynamic and residential IP addresses. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support
LOG: MAIN
<= <> R=1JY4zH-0001ym-VM U=Debian-exim P=local S=1777
LOG: MAIN
Completed
Pero en cambio, GMail sí que me lo acepta:
# mail [email protected] < /tmp/correo.txt
delivering 1JY51y-0001yu-LW
R: dnslookup for [email protected]
T: remote_smtp for [email protected]
Connecting to gmail-smtp-in.l.google.com [216.239.59.27]:25 ... connected
SMTP<< 220 mx.google.com ESMTP g11si5603645gve.6
SMTP>> EHLO localhost
SMTP<< 250-mx.google.com at your service, [81.39.245.151]
250-SIZE 28311552
250-8BITMIME
250 ENHANCEDSTATUSCODES
SMTP>> MAIL FROM:<[email protected]> SIZE=1363
SMTP<< 250 2.1.0 OK
SMTP>> RCPT TO:<[email protected]>
SMTP<< 250 2.1.5 OK
SMTP>> DATA
SMTP<< 354 Go ahead
SMTP>> writing message and terminating "."
SMTP<< 250 2.0.0 OK 1205005717 g11si5603645gve.6
SMTP>> QUIT
LOG: MAIN
=> [email protected] R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [216.239.59.27]
LOG: MAIN
Completed
aunque según mi experiencia, dependiendo de la IP dinámica que te haya tocado, es muy posible que también se te rechacen los correos si alguna vez la ha tenido alguien sospechoso de mandar spam. En definitiva, es un servicio nada fiable.
Si tenemos un dominio propio con Custom DNS, crear un registro SPF en el DNS puede ayudar para que no rechacen los correos de tu servidor. En openspf.org tienen un formulario que nos ayuda a confeccionar uno adecuado para nuestro servidor.
Las MSN Hotmail Guidelines son un buen sitio donde contrastar todos estos requisitos, que suelen ser bastante comunes:
Sender is expected to comply with all technical standards for the transmission of Internet e-mail, as published by The Internet Society’s Internet Engineering Task Force (IETF), including RFC 2821, RFC 2822, and others.
After given a numeric SMTP error response code between 500 and 599 (also known as a permanent non-delivery response), the sender must not attempt to retransmit that message to that recipient.
After multiple non-delivery responses (see #2), the sender must cease further attempts to send e-mail to that recipient.
Sender must not open more than 500 simultaneous connections to MSN Services inbound e-mail servers without making prior arrangements.
Messages must not be transmitted through insecure e-mail relay or proxy servers.
The mechanism for unsubscribing, either from individual lists or all lists hosted by the sender, must be clearly documented and easy for recipients to find and use.
Connections from dynamic IP space may not be accepted.
E-mail servers must have valid reverse DNS records.
Y fijémonos además en lo que nos decía el mensaje de rechazo de Hotmail:
Mail rejected by Windows Live Hotmail for policy reasons. We generally do not accept email from dynamic IP’s as they are not typically used to deliver unauthenticated SMTP e-mail to an Internet mail server. http://www.spamhaus.org maintains lists of dynamic and residential IP addresses. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support.
Esa lista que menciona de Spamhaus no sólo la usa Microsoft, sino que muchas otras empresas e ISPs se basan en ella para descartar los correos desde determinados rangos de IPs en función de la lista.
Con los correos entrantes no tendremos ningún problema siempre que nuestro servidor esté arriba. Los servidores SMTP que nos quieran mandar correo buscarán el registro MX (o el A si no hay MX) en elDNS y salga la IP que salga, ahí se mandará el correo. Para recuperar los correos recibidos en el servidor, puede ser suficiente el clásico comando mail, o con un simple “apt-get install qpopper“, podemos tener un servidor de POP3 listo en pocos segundos. Sin embargo, si nuestro servidor no está arriba por algún problema cuando otro servidor SMTP quiera conectarse al nuestro para enviarle un e-mail, el servidor remoto tendrá que decidir si reintenta el envío más tarde o si lo descarta, por lo que el servicio de recepción de correos tampoco es fiable.
Si realmente queremos tener un servidor de correo fiable en nuestro sistema, la solución definitiva puede venir por contratar el servicio de DynDNS MailHop Relay (42.5$/año), específicamente pensado para estos problemas. El servidor SMTP de DynDNS es el que da la cara y nosotros lo usamos como smarthost para mandar los correos a través de él y viceversa, para que él nos los envíe de vuelta, guardándolos temporalmente si nuestro servidor está caído.
Bytecoders también trató estos temas hace poco en Aviso de actualizaciones en Debian por e-mail y SMTP: la lacra del SPAM.
Correo con nuestro propio dominio con Google Apps
Para mí, todos estos problemas con el correo se acabaron cuando apareció el Google Apps y pude usar el equivalente a GMail (con su POP3 y su IMAP) pero creando diferentes direcciones sobre mi propio dominio (vicente-navarro.com). Para ello, lo único que tuve fue darme de alta en el servicio y apuntar los registros MX de mi dominio a los servidores de Google (Configuring Your MX Records):
# nslookup
> set querytype=MX
> vicente-navarro.com
Server: 80.58.61.250
Address: 80.58.61.250#53
Non-authoritative answer:
vicente-navarro.com mail exchanger = 10 alt1.aspmx.l.google.com.
vicente-navarro.com mail exchanger = 15 alt2.aspmx.l.google.com.
vicente-navarro.com mail exchanger = 5 aspmx.l.google.com.
Authoritative answers can be found from:
alt1.aspmx.l.google.com internet address = 72.14.215.114
alt1.aspmx.l.google.com internet address = 72.14.215.27
alt2.aspmx.l.google.com internet address = 64.233.179.27
aspmx.l.google.com internet address = 216.239.59.27
Tras esto, creé buzones de correo (o alias) para cada una de las cuentas que iba a usar y reconfiguré mi servidor para que usara un smarthost:
Y para que usara smtp.google.com como smarthost
el resto de la configuración, puede quedar igual que estaba antes. Bueno, igual pero no se nos tiene que olvidar poner nuestro dominio en el apartado de “System mail name“.
Lo único que tendremos que tener en cuenta es que ahora los correos no se reciben localmente sino en la cuenta de Google Apps (lo que en realidad es más cómodo), pero si aún así fuera necesario traer esos correos a nuestro servidor, siempre podríamos configurarlo para que se los trajera de Google usando POP3.
Por supuesto, Google requiere autentificación para mandar correos a través de él, por lo que en el fichero /etc/exim4/passwd.client tendremos que asociar nuestro usuario y contraseña de Google Apps al servidor SMTP:
# password file used when the local exim is authenticating to a remote
# host as a client.
#
# see exim4_passwd_client(5) for more documentation
#
# Example:
### target.mail.server.example:login:password
gmail-smtp.l.google.com:[email protected]:contrasenya
Independientemente de que vayamos a usar el servidor de HC para enviar y recibir correos en serio o no, es indudable que necesitamos tenerlo bien configurado como servidor de correo para que podamos mandarnos advertencias sobre problemas que pueda haber en el servidor desde nuestros scripts de monitorización. O, simplemente, porque aplicaciones como WordPress mandan correos cada vez que llega un nuevo comentario, por ejemplo. Si el servidor de correo no está bien configurado, las aplicaciones que envían correos como parte de su funcionamiento normal, no podrán hacerlo.
Otras cuestiones
Backups
#!/bin/bash
while ! queda_claro
do
insistir_en_el_backup
done
no_se_puede_insistir_bastante
Creo que no hace falta decir más. Tenemos todo el trabajo invertido en configurar nuestro servidor casero, las bases de datos con los comentarios de nuestros visitantes, nuestras imágenes, nuestro trabajo ahí. ¿De verdad nos vamos a arriesgar a que el disco duro falle o a que inadvertidamente hagamos un “rm -rf *” y desaparezca todo de un plumazo?
Para esta tarea, rysnc es nuestro mejor amigo (Backups con rsync), aunque herramientas como tar o cpio también pueden ayudar. Yo recomendaría una copia de todos los ficheros importantes en algún directorio del propio servidor casero y otra/s copia/s en otro/s sistema/s que tengamos a través de de la red con rsync.
Para exportar todas las bases de datos MySQL del sistema e incluirlas en el backup, podemos hacer un:
mysqldump -uroot -ppassword --all-databases > backup_mysql.bak
y lo podríamos recuperar con un:
mysql -uroot -ppassword < backup_mysql.bak
Más detalles sobre cómo usar el mysqldump en “mysqldump — A Database Backup Program“.
El sistema de respaldo
Durante el año habrá algunos días, semanas o meses que pases fuera de tu casa. Seguramente esos días te querrás dejar la luz, el agua y el gas de casa cerrados para prevenir incidentes. ¿Qué haces con el servidor casero? ¡Tiene que seguir dando servicio!
Si tienes la suerte, como yo, de contar con algún otro ordenador que pueda servir también de servidor casero y de tener algún familiar/amigo con conexión a Internet y que consienta en tenerlo en su casa, una especie de “housing casero”, lo tenemos muy fácil:
Instalamos la misma versión de sistema operativo que en el servidor “oficial” y lo llevamos a su nuevo destino.
Creamos un nuevo nombre para el otro sistema en DynDNS y lo configuramos para que el ddclient del nuevo sistema lo actualice, pero muchísimo mejor si podemos configurar el router de “la otra casa” para que lo haga automáticamente.
Opcional: Preparamos el router y el sistema “hospedado en casa ajena” para arrancar con Wake on Lan. Tenemos que tener en cuenta que si no es el router el que se encarga de actualizar la IP en DynDNS, podemos tener el problema de no saber la IP de destino para enviarle el paquete mágico.
Le ponemos una IP fija al sistema o configuramos el router para que le asigne por DHCP siempre la misma y abrimos los puertos necesarios en el router.
Creamos una batería de scripts basados en rsync y SSH para sincronizar todos los ficheros de configuración necesarios y adaptar los que varían en el nuevo sistema (por ejemplo, el /etc/ddclient.conf). También deberían actualizar las bases de datos y reiniciar los procesos necesarios tras modificar la configuración.
Tener previstos otros scrips para pasar el servicio de un sistema a otro. Al final, esto sólo consiste en que el sistema que sea el primario actualice los registros DNS con su IP y el secundario deje de hacerlo.
Tras la estancia en el otro sistema, tendremos que sincronizar los cambios de vuelta al sistema principal y probablemente querramos recoger los logs que se hayan generado allí.
Este sistema de respaldo no sólo nos puede servir en caso de tener que apagar nuestro servidor habitual. También lo podemos utilizar mientras hacemos tareas de mantenimiento o si en tenemos problemas con la conexión a Internet o estamos sufriendo un apagón.
Los cortes de corriente
Otro de los problemas con los que nos tendremos que enfrentar serán los cortes de corriente. Aunque no son muy frecuentes, de vez en cuando tendremos uno y tenemos que tener previsto qué hacer cuando ocurran.
Si se trata de un breve corte, lo más importante es que el servidor arranque sólo cuando vuelva a recibir corriente. Para ello, tenemos que buscar el parámetro de nuestra BIOS que lo permite.
Por ejemplo, en una VIA EPIA SP8000E, el parámetro se llama AC Loss Auto restart y podemos hacer que la máquina se encienda siempre cuando vuelva la luz, que no se encienda nunca o que vuelva al estado anterior:
AC Loss Auto restart
The field defines how the system will respond after an AC loss during system operation.
Off: Keeps the system in an off state until the power button is pressed
On: Restarts the system when the power is back
Former-Sts: Restores the system to its previous state
En una placa Asus A8N-SLI, el parámetro se llama Restore on AC Power Loss y sólo tiene dos valores posibles, activado o desactivado:
Pero si queremos estar prevenidos de verdad ante cortes de corriente, la mejor opción es tener un SAI al que conectar el servidor y el router que da acceso a Internet. Si el servidor es un sistema de bajo consumo, tendremos bastante tiempo de margen para esperar a que vuelva la luz, o al menos, el tiempo suficiente para actualizar nuestro servidor de respaldo por si tiene que entrar en acción.
Mantenimiento remoto
La posibilidad de conectarnos por SSH a nuestro servidor casero siempre tiene que estar abierta. En mi experiencia, un servidor SSH abierto en Internet trae infinidad de intentos de conexión con reiteradas pruebas con distintos usuarios. Sin ir más lejos, hoy mismo, alguien ha probado 1520 combinaciones diferentes de usuario/contraseña en mi sistema
# grep "Invalid user" auth.log.0 | grep "Mar 9" | wc -l
1520
Algunos ejemplos:
Mar 9 06:15:05 telemaco sshd[6028]: Invalid user ibm from 61.250.91.34
Mar 9 06:15:09 telemaco sshd[6032]: Invalid user informix from 61.250.91.34
Mar 9 06:40:08 telemaco sshd[7742]: Invalid user stevie from 61.250.91.34
Mar 9 06:40:11 telemaco sshd[7746]: Invalid user kelly from 61.250.91.34
Mar 9 06:40:15 telemaco sshd[7750]: Invalid user rasoul from 61.250.91.34
Es por eso que lo mejor es deshabilitar completamente el acceso con usuario/contraseña y permitir exclusivamente la autentificación por clave pública/privada: Autentificación trasparente por clave pública/privada con OpenSSH.
Cambiar el puerto del servidor SSH (por defecto 22) a otro también puede ser una medida útil para evitar algunos de estos insistentes intentos de acceso.
Otra herramienta de mucha utilidad para el mantenimiento remoto es conectar un módem a nuestro servidor casero, tal y como vimos en: Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP. En casos en que el router haya perdido la conexión a Internet, podemos tratar de conectarnos por módem y a través del interfaz de configuración por telnet del router tratar de reiniciarlo. Otra situación útil es en caso de una avalancha de peticiones en la que tú mismo no puedes acceder por el router por la absoluta falta de ancho de banda y, en ese caso, la entrada “por la puerta de atrás” nos puede servir para llegar al sistema sin usar Internet.
¿P2P y hosting casero?
Supongamos que necesitamos bajarnos el último DVD de Knoppix por Bittorrent. ¿Es compatible el P2P con sus altas necesidades de ancho de banda con el HC?
Pues en principio, puede serlo -en función del número de visitas que recibamos- siempre que limitemos el ancho de banda de subida disponible para P2P a un límite que permita servir los contenidos hospedados a una velocidad razonable. En el mejor de los casos, el uso de P2P en la misma conexión de un HC irá completamente en detrimento de la experiencia de nuestros visitantes, aunque sólo tengamos uno en ese momento, pero que notará que la página descarga más lenta.
El mejor consejo al respecto es que si activamos el P2P, deberíamos de estar pendientes de que el tiempo de respuesta sea un mínimo aceptable probando nosotros mismos a conectarnos desde otro sistema de Internet. Si vemos que va muy lento, deberíamos desactivar el P2P. Por supuesto, en caso de un pico de visitas, deberíamos de desactivar el P2P inmediatamente.
Scripting
Cualquier administrador que se encargue de un servidor UNIX tiene que estar continuamente creándose scripts para no realizar las mismas tareas una y otra vez. Para nosotros, como administradores de nuestro HC no va a ser distinto. Deberíamos de tener unos conocimientos mínimos de scripting que nos serán muy útiles para hacer backups, para analizar logs, para monitorizar el estado de algún proceso, para enviar e-mails con advertencias, etc.
A lo largo de este año, yo me he llegado a crear un buen número de scripts. La mayoría son muy específicos de mis necesidades particulares, pero me gustaría dejar aquí uno muy sencillito que nos manda un e-mail cada vez que el ISP nos cambia la dirección IP dinámica:
#!/bin/bash
cd /root/scripts_ip
mv -f ippublica ippublica.old
./ippublica.sh > ippublica
if ! diff ippublica ippublica.old > /dev/null
then
cat cabecera ippublica | mail -s "La IP del servidor ha cambiado - `date +"%g/%m/%d %H:%M"`" [email protected]
fi
El ippublica.sh puede ser, bien una petición por SNMP al router para ver cuál es la IP del interfaz de WAN:
snmpwalk -c comunidad -v 1 192.168.1.1 IP-MIB::ipAdEntAddr|egrep -v '0.0|192.168' | awk '{print $4}'
bien un acceso a checkip.dyndns.org:
/usr/bin/wget -q -O - http://checkip.dyndns.org/index.html | /usr/bin/fromdos | /bin/sed 's_<html><head><title>Current IP Check</title></head><body>Current IP Address: __' | /bin/sed 's_</body></html>__'
El fichero cabecera es algo como:
La IP del servidor es ahora:
Conclusión
En esta entrada he tratado de recopilar lo más importante de lo que me ha sido necesario conocer durante un año completo de autohospedaje en el que creo que el resultado ha sido bastante satisfactorio. Por carambolas del destino, ahora ya he pasado a un hosting profesional, pero la travesía ha valido la pena y la repetiría tantas veces como hiciera falta. Si alguien tiene intención de adentrarse en esta aventura ha de saber que aprenderá mucho y espero que en estas líneas encuentre consejos que le sean de utilidad, como creo que me hubieran sido a mí.
También hay que tener en cuenta que también es posible tener un hosting casero sin tomárnoslo muy en serio, de forma que no nos importe en absoluto si tenemos la página caída varios días seguidos, pero creo que si nos ponemos, vale la pena hacerlo lo mejor posible. No hay nada que dé peor impresión en Internet que una página que tarda en cargar o que cada dos por tres esté caída. Esa no es la forma de fidelizar a nuestros lectores.
El HC es un poco como tener un perro en casa. Puede ser divertido, te dará muchas satisfacciones, pero a cambio ganas muchas obligaciones: Tienes que estar pendiente de él, te da trabajo y no puedes irte de vacaciones sin buscarle un acomodo.
Si te gusto dame puntos
