He aquí el porque escribo Open Source…, para que miles de personas utilicen mis códigos. Aquí esta una prueba de ello, un popular (casi 20mil descargas) plug-in de Wordpress.
Grande Photo Xhibit
Gracias a Sarita por avisarme.
Siguiendo con mi post sobre servidores, una parte fundamental es la parte de backup, ya que siempre es importante estar preparados los desastres. Lo importante de los backups es la redundancia, y la seguridad. Nadie mas que nosotros tiene que poder ver nuestros backups.
Anteriormente mencione que Amazon S3 es una solución barata, muchas veces barata no es suficiente (especialmente si pagas a Amazon S3 una fortuna por otros sitios). Luego de pensar, y pensar en un medio de almacenamiento mas o menos seguro y gratis de ser posible, se ocurrió que tengo bastante espacio ocioso en mi gmail (65% para ser exacto). La única limitación es que el backup generado tiene que ser menor de 20MB. El único problema que ahora surge es que Google podría leer nuestros backups y ahí obtener valiosa información sobre nuestro sitio web, base de dato u otra cosa que este contenida en el backup,
Para solucionar ese problema podríamos usar encriptación, de manera que nadie pueda ver el contenido del archivo sin una clave.
Aqui les presento el script que yo utilizo para hacer los backups de mis servidores.
#!/bin/bash -x MAIL=foobar@gmail.com #Obviamente, no solo funciona con @gmail. SQL=/tmp/tables.sql DATE=`date '+%F'` # Password que es un MD5 # de un string que tiene la fecha, # cada dia, tiene un password unico echo "password con $DATE " > /tmp/foo PASS=`md5sum /tmp/foo | sed "s/ .*//g"` rm /tmp/foo # backup de mysql. mysqldump -u root --all-databases | bzip2 | openssl des3 -salt -k $PASS | dd of=$SQL # Ahora comprimimos tar cfj - /www/foobar.com | openssl des3 -salt -k $PASS | dd of=foobar.com-$DATE.bin # /etc tar cfj - /etc/ | openssl des3 -salt -k $PASS | dd of=etc-$DATE.bin # Ahora enviar los mails echo | mutt -s "[backup] $DATE foobar.com " $MAIL -a foobar.com-$DATE.bin echo | mutt -s "[backup] $DATE /etc" $MAIL -a etc-$DATE.bin echo | mutt -s "[backup] $DATE MySQL" $MAIL -a $SQL rm $SQL
Para restaurar el backup simplemente hay que ejecutar el siguiente script. Lo importante es proveer siempre la clave correcta, que cambia para cada día (utiliza la fecha). Sin la clave es literalmente imposible que recuperemos el contenido, de ahi la importancia de no olvidar la clave.
#!/bin/bash -x dd if=$1 |openssl des3 -d -k $3 | dd of=$2
Para restaurar el backup simplemente debe realizar lo siguiente:
$ restore archivo-encriptado archivo-salida-desencriptado clave
Si se preguntan cuan seguro es el encriptado?, pues la respuesta es suficiente para que yo ponga informacion real sobre una de mis tarjetas de creditos con algunos dolares (sobrantes del Google Summer of code) en un sitio de descarga para que la gente intente romper la seguridad. Si deseas intentar puedes bajarte de aqui.
Luego de leer esta increíble página con algunos chistes frikis, me acorde que despues de mucho googlear encontre un mirror del desaparecido raulito el friki, sin pensarlo dos veces escribí un rápido script en bash para que me bajara todas las tiras.
Para aquellos desconocedores de la tira; Raulito es un friki con unos 30 años amante de Debian GNU/Linux y con la desgracia de que las iniciales de su nombre son R P M (Raúl Peñáez Martinez), que no puede encajar en la sociedad (¿O la sociedad no encaja con él?). Sus padres frustrados de su anómalo hijo (el cual reiteradas veces piensa y actúa como un kernel de Linux) tratan de cambiarlo e integrarlo a la sociedad, por ejemplo llamando a un cura (del opus dei) para que lo guíe por el buen camino. Al final éste termina creyendo que esta poseído y que es un ferviente y apasionado homosexual.
Si se preguntan porque no dudé ni un segundo en bajarte “la temporada”, vean porque: 
Si quieren bajarse las demás tiras, aquí están de la tira 1 hasta el 95.
Si alguien quiere también tengo todas las bilo y nano.
En estos días me he dedicado a ahondar en temas de performance para sitios relativamente grandes para shared hostings, y pequeños para servidores dedicados (posiblemente tenga que hostear un periodico local con 50.000 visitas diarias, todavía no está confirmado). Aunque el título de este post suena un poco marketinero, en realidad este artículo será la continuación de como mejorar el rendimiento de una web.
Para la mayoría de los sitios webs no se justifica un servidor dedicado y un shared hosting que pequeño, entonces ¿cuál sería el punto medio?, ahí cuando entran en juego las VPS. Básicamente las VPS son máquinas virtuales en donde tenemos acceso total, casi todos utilizan Xen aunque personalmente me encanta el Linux-VServer (esto es totalmente irrelevante en este artículo), hablando mal y rápido son como máquinas dedicadas con menores recursos y lo más importante mucho menos precio.
Yo utilizo Linode, y realmente no me puedo quejar de su servicio, pero existen varios otra opciones en el mercado.
La seguridad es un tópico bastante extenso, y básicamente es una buena práctica. Ya que nadie no velará por la seguridad de nuestro server, más que nosotros mismos tenemos que tomar algunas medidas, básicamente ocultar los detalles de nuestro servidores. En todos los ataques “hackers” que fui parte (siempre como victima, en algún trabajo) fue por que el “atacante” conocía como funcionaba el servidor (ex-funcionario) o por culpa del administrador del servidor que dejó las configuraciones por defecto.
Algunas de las buenas prácticas son las siguientes:
Como decía en mi articulo anterior (como mejorar el rendimiento de una web), si deseamos tener un servidor para atender un gran número de visitas lo más importante despues de la buena práctica de programación era tener un servidor web efectivo, parte de la efectividad era separa las consultas dinámicas y las estáticas hacia diversos servidores. Esto no es problema si hacemos las aplicaciones from scratch, pero que pasaría si por ejemplo queremos instalar una aplicación Open Source (ej: wordpress), cambiar las direcciones de los archivos estáticos hacia otro dominio sería un poco trabajoso (todos sabemos que no sería un problema que con wp, solo es un ejemplo). La solución más simple sería un reverse proxy que redirija la petición dependiendo de que si el recurso requerido es estático o dinámico.
Ahí es cuando entra en juego el NGinx ya que aparte de ser un increíble webserver, también es reverse proxy entre otras cosas. La configuración será la siguiente.
Aquí va la configuración.
# El usuario va a ser nginx, siempre es importante
# ejecutar como usuario sin privilegio.
user nginx;
# número de procesos "workers" que se encargaran de
# atender a la peticiones entrantes.
worker_processes 2;
# log
error_log logs/error.log;
# pid, útil para reiniciar el "servicio"
pid logs/nginx.pid;
events {
# procesos que se encargaran de responder la petición
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] $request '
'"$status" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log logs/access.log main;
sendfile on;
keepalive_timeout 65;
# Comprimir todo, útil para ahorrar ancho de banda.
gzip on;
server {
listen 80;
server_name www.servidor,com;
access_log logs/host.access.log main;
location / {
# Por defecto pasar todas las peticiones al Apache.
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
# Si lo requerido es una archivo "estático", nginx tiene que responder,
# y el cliente no tiene que volver a preguntar (gracias al cache).
location ~* ^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
root /var/www/html/;
expires max;
}
# Página estática de error
error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
Para este ejemplo el Apache tiene que escuchar el puerto 8080 del IP 127.0.0.1. También sería razonable desabilitar los logs de acceso (pero los de error no, ya que PHP escribiría ahí los errores) ya que esos logs son generados por nginx, y para qué repetir datos?
Lo aquí expresado es estrictamente personal y nada tiene que ver con el CNC o el NIC, aunque yo trabaje en el CNC.
En estos días se hizo eco el “hackeo” a la página del NIC, un buen hackeo realizado por un conocido bastante inteligente (nada contra él, todo bien) que aprovechaba algunos bugs del CGI escrito en Perl (hace más de 10 años) haciendo un inyección (no voy a entrar en detalles). Los “daños” realizado fueron mínimos ya que solo entraron al servidor web que no tiene nada de información, bases de datos ni nada relacionado al NIC o al CNC, si desearían hackear necesitarían hacer algo mejor que eso ya que todo está en una red privada.
Si piensan que los culpables somos los funcionarios actuales del CNC, la respuesta es NO, ya que esa página está desde hace mas de 10 años, y tenemos una larga lista de actividades de cosas a hacer, no podemos pasar la vida controlando cosas que fueron hechas hace años y que funcionan (o así parece).
Hasta ahí todo bien, ahora lo que me molesta y bastante es que algunas personas anden opinando por foros o algo así, y mucho más un tal Lucho Benítez (ex funcionario del CNC, de la misma época cuando el CGI fue escrito) esté escribiendo artículos amarillistas y aprovechándose de la ignorancia de los medios de prensa, para hacer polémicas (flameware) y así tener unas cuantas visitas en su blog (y hacer unos cuantos dolares), típico troll, alguien debería comentarle que si quiere visitantes existe digg, o meneame si solo habla español.
Investigué algo referente a Lucho Benítez, lastimosamente google no me dijo nada, pregunté a gente del CNC, y tampoco me dijeron nada, por lo visto su paso por el CNC no marcó historia como el de algunos legendarios que sus nombres aún se escuchan por los pasillos. A continuación responderé algunas cosas de su artículo amarillista.
Que sucedió en el CNC? ya no tienen presupuesto para el mantenimiento de los servicios? Habría que recordar que este también es un MONOPOLIO al que ni la prensa ni los proveedores hacen referencia.
Monopolio?!, que otra empresa está preparada para tener el servicio de NIC?, algún grupito de “hackers” o usuarios Unix?, otro ente público? alguna empresa privada?. Si tienen problemas deberían hablar con el Rectorado UNA, no con el CNC.
Por qué este evento desnuda un problema grave? Simplemente por que el DNS forma parte de los protocolos que hacen a la arquitectura de Internet. Sin el DNS del NIC.py nadie en ninguna parte del mundo podrá llegar a servidores que tienen su dominio bajo .py. Podrían hacerlo por el número IP, pero no por el nombre de dominio. Al tomar cierto control de este equipo es solo cuestión de tiempo, (y si se tiene el conocimiento adecuado) tomar el control del resto de la infraestructura.
Linda clase para muggles pero totalmente irrelevante, y nada tiene que ver con el servidor web que fue “hackeado”.
Es por ello que me parece gravisima la desidia y/o negligencia del personal del CNC, y ante todo una vez más la población (sobre todo los usuarios) de vuelta esta desprotegida, y seguirá así, si no cambian ciertas prácticas.
Que tiene que ver eso con un servidor web?
Otra cosa que me molesta es la gente ignorante que se quejan por los precios del NIC asociando al CNC como responsable, si tienen problemas con el precio (o burocracia) deberían hablar con la gente del Rectorado (somos dependiente del Rectorado UNA) o comprarse .com
Modestia aparte, en el CNC sólo trabaja gente muy buena (entre las mejores del Paraguay, si no me creen pueden googlear el nombre de algún funcionario del área técnica), pero el problema principal es la constante rotación del personal debido al bajo salario (somos funcionarios del Rectorado).
PHP Dev, located in Paraguay who wants to work abroad. You could read more about me here
![[FSF Associate Member]](http://cesar.la/fsf.png){kind=small}
|
