42.zip es un archivo zip de 42.374 bytes, contiene 16 archivos zips que a su vez contienen otros 16 zips y así hasta 6 veces. Los 16 últimos zips contienen un archivo de 4,3 Gb cada uno. Si descomprimimos el archivo 42.zip de 42.374 bytes obtendriamos 4.5 Pb de datos descomprimidos.
16 x 4294967295 = 68.719.476.720 (68GB)
16 x 68719476720 = 1.099.511.627.520 (1TB)
16 x 1099511627520 = 17.592.186.040.320 (17TB)
16 x 17592186040320 = 281.474.976.645.120 (281TB)
16 x 281474976645120 = 4.503.599.626.321.920 (4,5PB)
Este tipo de archivos se denominan Zips de la muerte o Zips bomba y suelen usarse como herramienta para ataques DoS.
PD: hay que ver como una cosa tan pequeña te puede joder el servidor enterito 😀 , así que pequeños sysadmins tener muy definidas las reglas de cuotas de disco con sus respectivas alertas a vuestro email 😀 raiola manda y no el panda
Y es que, cada vez se ven mas destrozos a causa de las webs mal hechas (o poco actualizadas) en php . Que si postnuke, que si phpnuke, phpbb, mybb y un larguisimo etc. Ya que esto es un dolor de cabeza para cualquier sysadmin, algo a tener en cuenta es el deshabilitar ciertas funciones de php en el php.ini, y el que las quiera.. que las habilite en el .htaccess de su virtualhost bajo su responsabilidad, no? Empezamos:
Editamos fichero de configuración de PHP php.ini
#vi /etc/php.ini
buscamos la linea que contiene disable_functions. Posiblemente tenga un ; delante, que sirve para inutilizarla. Eliminamos el ; y dejamos la linea de esta forma:
No es nada difícil instalar un servidor de Subversion en un linux, pero hay que tener unas cuantas cosas en cuenta si queremos que se integre bien con Plesk y poder alojar todos nuestros proyectos bajo un subdominio del tipo https://svn.midominio.com/repositorio1
Como siempre, para toquetear el servidor necesitas tener acceso al sistema por consola con el usuario root. Este tutorial funciona con Plesk 8 y Plesk 9 (concretamente Plesk 9.2) corriendo sobre un Linux CentOS, que no es otra cosa que un servidor dedicado de 1and1. Y siendo honrados, hay que decir que básicamente es la adaptación y traducción del howto que yo usé escrito por Ale Le (en inglés).
NOTA: Cambia “repositorio1″ por el nombre que le quieras dar y “dominio.com” por tu nombre de dominio.
Resumen de los pasos a seguir:
Instalar el servidor de Subversion
Configurar apache
Crear el repositorio Subversion
Configurar Plesk
Crear usuarios y repositorios
Paso 1: Instalar el servidor de Subversion
# yum install subversion Una vez hecho login con el usuario root, usamos yum para instalar los paquetes de subversion (si en vez de CentOs utilizas otra distribución, quizás tengas que usar aptget u otro gestor de paquetes). Para comprobar que la versión de subversion es la correcta ejecuta # svn --version y tendría que darte 1.4 (en concreto, yo tengo 1.4.2)
Paso 2: Configurar Apache
Gracias a yum hemos instalado Subversion con gran facilidad y podríamos usarlo ya con los protocolos y puertos de subversion. Ahora hemos de configurar apache para que cuando alguien llame a https://svn.midominio.com/repositorio1 se esté conectando a subversion via WEBDAV.
# yum install mod_dav_svn Instalamos el mod_dav_svn para apache (DAV es la tecnología que nos permitirá hacer commits a través de http). Este comando debería instalar todos los paquetes que dependan para su funcionamiento (como mod_authz_svn). Puedes ver los módulos de apache que tienes instalados en # ll /etc/httpd/modules
# vi /etc/httpd/conf.d/subversion.conf LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so Puede ser que el archivo ya esté creado, aunque con un nombre subversion.conf.ALGO : si estas dos lineas aparecen arriba y no están comentadas, ya nos vale. Hemos de asegurarnos de que apache está cargando el archivo mod_dav_svn.so al arrancar. En /etc/httpd/conf/httpd.conf podemos ver que después de cargar módulos básicos hace Include conf.d/*.conf. Por lo que crearemos un archivo llamado /etc/httpd/conf.d/subversion.conf y le insertamos el código arriba escrito.
Paso 3: Crear el repositorio Subversion
# mkdir /var/svn/ # mkdir /var/svn/repositorio1 Crearemos el directorio svnrepo en /var/, donde se alojarán los repositorios de subversion
# svnadmin create /var/svn/repositorio1 Instalamos un repositorio en ese directorio mediante el comando svnadmin create
chmod -R 777 /var/svn/repositorio1 Muy importante es dar permisos de escritura a este directorio. Si no es así, apache no podrá modificar estos archivos y por tanto, los commits nunca funcionarán.
Paso 4: Configurar Plesk
Creamos un subdominio mediante el panel de control de Plesk. Dentro del dominio en el que queremos colgar nuestro servidor de subversion. Hay que ir al panel del dominio > Sitio Web > Crear subdominio y le llamamos “svn”, por ejemplo. Si al crear el dominio hemos activado https y hemos dicho que vaya al mismo sitio que http, podremos acceder por https a nuestro repositorio.
Como Plesk sobreescribe el archivo /var/www/vhosts/dominio.com/conf/httpd.confy el /var/www/vhosts/dominio.com/subdomains/svn/conf/httpd.conf cada vez que tocamos algo en el panel de control, hemos de hacer los cambios en otro fichero que creamos con el nombre vhost.conf. En ese fichero introducimos el código que he puesto arriba. Con eso le decimos a apache que use DAV y que el repositorio de svn está en /var/svnrepo/ y que para autenticar pida cualquier usuario válido en el archivo de passwords /etc/svn-auth-file (luego lo creamos).
# /usr/local/psa/admin/sbin/websrvmng -u --vhost-name=dominio.com Como siempre que añadamos un archivo al directorio conf de un dominio, hemos de decir a Plesk que regenere el httpd.conf incluyendo un “include” a nuestro vhost.conf. Al poner name=dominio.com sólo regenerará ese dominio.
# /etc/init.d/httpd restart Una vez el include está en httpd.conf, reiniciamos el apache y así leerá el nuevo archivo vhost.conf. Ahora ya tenemos montado el servidor y el subdominio apuntando a nuestro subversion en http://svn.dominio.com/repositorio1 o https://svn.dominio.com/repositorio1 si lo hemos configurado así (pruébalo, venga!)
Paso 5: Crear usuarios y repositorios
# htpasswd -c /etc/svn-auth-file usuario1 La aplicación htpasswd crea un archivo en /etc/svn-auth-file e introduce un usuario con nombre usuario1 (en seguida nos pide que escribamos y confirmemos su contraseña). ¡Alerta! Si queremos crear más usuarios, no debemos usar la opción -c, ya que esta crea un nuevo fichero, sobreescribiendo el anterior. Para el segundo y siguientes usuarios, usaremos # htpasswd /etc/svn-auth-file usuario2. Si queremos borrar un usuario, podemos editar el fichero o usar la opción -D mayúscula.
Además, a mi me interesa tener varios repositorios, sólo he de hacer los pasos 3, 4 (sólo el punto 2, añadiendo un bloque debajo del otro) y 5 cambiando “repositorio1″ por otro nuevo repositorio
Si sólo quiero dar acceso a ciertos usuarios a repositorios concretos, puedo hacerlo cambiando la linea en vhost.conf Require valid-user por Require user usuario1 usuario2
Por favor, dejad comentarios si veis algún fallo o sugerencia. Espero que esto os ahorre unas cuantas horas de investigación
Para ajustar la hora del BIOS utilizamos el comando hwclock de la siguiente manera:
# hwclock --set --date hh:mm
Para verificar que efectivamente hemos realizado el cambio, podemos ver el reloj del Hardware con la opción –show, de la forma siguiente:
# hwclock --show
Sun 21 Feb 2010 11:44:23 PM CET -0.468872 seconds
Ahora ajustamos el reloj del sistema con el comando:
# hwclock --hctosys
Lo anterior copia la fecha y hora del reloj del BIOS al reloj del sistema, es decir, sincroniza ambos relojes. Finalmente, para comprobar que nuestros comandos surtieron efecto, pedimos la fecha y hora del sistema con date.
La revolucionaria película “Avatar” se ha convertido en una referencia para el futuro del cine en tres dimensiones, pero aquellos que quieran producir una película similar tendrán que tener en cuenta las ingentes necesidades que impone.
Una charla de uno de los administradores de sistemas de Weta Digital -la empresa encargada de los efectos especiales- ha revelado algunos detalles sobre los centros de datos que se utilizaron para una producción que usó Ubuntu como sistema operativo.
Uno de los asistentes a las conferencias Linux Conf Australia 2010 (LCA2010) ha contado cómo en una de las charlas intervino Paul Gunn, administrador de sistemas en Weta Digital, responsable de los efectos visuales de la película Avatar.
En el post de Dustin Kirkland -que trabaja en Ubuntu Server- se indica que la infraestructura del centro de datos que tuvo que poner en marcha Weta Digital para esta producción fue impresionante. Ya habíamos hablado de la matriz de almacenamiento con capacidad para hasta 2 Petabytes, pero aún hay más detalles.
Entre otros, que se usó una red de conectividad a 10 Gbps, que había más de 4.000 HP Blades con cerca de 35.000 núcleos de proceso en su interior en el centro de datos y 104 Tbytes de memoria RAM en total, y que aún así se tardaba 48 horas en renderizar algunas de las secuencias gráficas.
Según Paul Gunn, responsable de la charla “Challenges in Data Center Growth“, Ubuntu fue el sistema operativo base de todo este desarrollo, y estaba instalado en todos los nodos de renderizado y en el 90% de los PCs de sobremesa de Weta Digital. De hecho, Gunn indicó que su propia “granja de renderizado” hace uso de Ubuntu Server, y no de RHEL como se publicó en algunos medios.
Eso ha permitido generar una película en la cual cada minuto ha ocupado nada menos que 17,28 Gbytes de datos, y curiosamente para refrigerar toda la instalación se limitaron a establecer la temperatura a 25º C, una cifra mayor que la mayoría de centros de datos, pero que les permitió ahorros energéticos importantes.
Nota: si quereis bajaros la pelicula Avatar visitar tuentishare.com
