martes, 2 de junio de 2015

Personalización en zimbra

Bueno, creo que muchos ya saben instalar y configurar Zimbra, pues hay miles de tutoriales, la cuestión es a la hora de personalizarlo, lo cual no es complicado, lo que si es complicado es conseguir información sobre el tema, porque no dicen bien las rutas, o ponen una información algo capada. En este caso, traigo un compendio de configuraciones de lo que he realizado a la hora de personalizar el zimbra para la empresa donde trabajo. Espero que este tema les sirva a algunos y puedan personalizar la gran herramienta que es Zimbra. 

Cambiar color de interfaz de inicio

zmprov modifyConfig zimbraSkinBackgroundColor "#DFECF5" ZimbraSkinSecondaryColor "#1558BE"

En este caso si miran el enlace, podrán apreciar que hay 2 opciones, una para dominio y otra para global. En nuestro caso se configura la global, pues por razones que desconozco fué infructuoso realizarlo con la opciones de dominio. Esto en zimbra 8.6.0 con las actualizaciones de seguridad.
En este caso, solo queremos cambiar los patrones de colores del inicio, así que no hay necesidad de usar otras opciones.
Para sacar los códigos de color usen la siguiente página
Editar Sección

Cambio de Logos

Bueno hay una forma de cambiar los logos, diferente a la que indica de forma oficial los foros de Zimbra, aunque las 2 formas tienes que colocar las imágenes en la carpeta jetty
La primera, que no la recomiendo para los que gustan de una personalización más fina, pero es la mas fácil y la oficial  es la siguiente:

Comandos Oficiales para cambiar iconos de inicio de sesión


URL del logo que aparece en la aplicación principal 
zmprov md igvsb.gob.ve zimbraSkinLogoURL
URL del logo que aparece en la aplicación principal 
zmprov md igvsb.gob.ve zimbraSkinLogoLoginBanner
URL del icono al iniciar la aplicación 
zmprov md igvsb.gob.ve zimbraSkinLogoAppBanner
Para agregar nuestros logos y re-dirección de URL en zimbra, debemos crear la carpeta logos en nuestro servidor zimbra, en la ruta 
/opt/zimbra/jetty/webapps/zimbra/logos/
Copiar los archivos en formato png, en nuestro caso login.png y app.png
zmprov md igvsb.gob.ve zimbraSkinLogoLoginBanner /logos/login.png 
zmprov md igvsb.gob.ve zimbraSkinLogoAppBanner /logos/app.png
y para configurar la URL ponemos 
zmprov md igvsb.gob.ve zimbraSkinLogoURL http://mail.igvsb.gob.ve
También se puede colocar la que se requiera 
para guardar los cambios ejecutamos
zmmailboxdctl reload
La razón por la que no me guista esta opción es que cambia los iconos de administrador y usuario como uno solo y no deja opciones a una mejor personalización. 
De esta primera forma de personalización lo único rescatable es la opción de configurar URL, que podemos complementar con la siguiente información:

Comandos Nada oficiales para cambiar iconos, imágenes y configuración de inicio de sesión


Las rutas para cambiar los iconos son las siguientes:
las rutas /opt/zimbra/jetty/webapps/zimbra/img/logo/, esta para la interfaz de usuario y/home/igvsb/jetty/webapps/zimbraAdmin/img/logo/ contienen los iconos de navegador, útil para evitar que vean que tenemos zimbra a simple vista, y también para personalizar la apariencia de nuestro correo.
En las locaciones 
/opt/zimbra/jetty/webapps/zimbra/skins/_base/logos y
 /opt/zimbra/jetty/webapps/zimbraAdmin/skins/_base/logos/
se cambian las imágenes de los logos o banners, que en nuestro caso cambiaremos por las de la empresa o institución.

Recomiendo que el tamaño de los nuevos logos no exceda el de los originales, pues no se van a visualizar correctamente. 

Existe una guía en inglés de la que he sacado valiosa información. La pueden encontrar en: http://sanjaygurav.blogspot.com.es/2012/07/how-to-re-brand-your-zimbra.html
De acá sacaremos muchas maneras de personalizar, aunque se ha de aclarar que cada vez que se actualice se debe cambiar los parámetros nuevamente.

Algo que no se dice en esta guía, es que si se tiene un idioma diferente a inglés, se debe configurar el archivo contentivo de ese idioma. Lo bueno es que todos están bien definidos y en la misma ruta /opt/zimbra/jetty/webapps/zimbra/WEB-INF/classes/messages/
Para cambiar los mensajes editamos
sudo vim /opt/zimbra/jetty/webapps/zimbra/WEB-INF/classes/messages/ZmMsg.properties
sudo vim /opt/zimbra/jetty/webapps/zimbra/WEB-INF/classes/messages/ZmMsg_es.properties


En ello podemos cambiar el mensaje de inicio que aparece abajo, donde nos indica el año y la información de zimbra, pudiendo personalizar en gran grado dicha información, y evitar así que personas indeseadas vean mas de lo que no deben ver.

otra cosa es cambiar el color del skin de zimbra, para poder ver personalizar los colores, pues en la primera parte de este apartado solo cambiamos la interfaz pero no el skin.

Para ellos usaremos el tema serenity, y evitaremos (si así lo desea el administrador) en uso de otros skins.
vamos a la ruta del skin serenity
cd /opt/zimbra/jetty/webapps/zimbra/skins/serenity/
editamos
sudo vim skin.properties

y veremos los códigos de color donde dice skin colors

#
# ***** BEGIN LICENSE BLOCK *****
# Zimbra Collaboration Suite Web Client
# Copyright (C) 2011, 2012, 2013, 2014 Zimbra, Inc.
#
# This program is free software: you can redistribute it and/or modify it under
# the terms of the GNU General Public License as published by the Free Software Foundation,
# version 2 of the License. #
# without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;
# You should have received a copy of the GNU General Public License along with this program.
# See the GNU General Public License for more details. # If not, see <http://www.gnu.org/licenses/>. # ***** END LICENSE BLOCK ***** #
# Skin Substitutions #
########################################################################## #------------------------------------------------------------------------# # # Add or change entries below to customize this skin.
#========================================================================#
# See: http://wiki.zimbra.com/?title=Themes # # NOTE: Substitutions that begin and end with "_" (eg: "AppC") # should only be used within this file -- never in a CSS or HTML file # SkinName = serenity SkinVersion = 1
# If you are using the Zimbra Collaboration Suite (ZCS) under the
########################################################################## # Logo Licensing Rules # #------------------------------------------------------------------------# # # open source license, and you have not modifed the software,
# and you have modified the software,
# then you are required to use the Zimbra logo (the default). # LogoImgDir = @AppContextPath@/skins/_base/logos LogoURL = http://www.zimbra.com # #------------------------------------------------------------------------- # If you are using ZCS under the open source license,
# then you are welcome to use your own logo in place of the Zimbra logo,
# then you are required to use the Zimbra Inside logo. # # LogoImgDir = @AppContextPath@/skins/_base/logos/ZimbraInside # LogoURL = http://www.zimbra.com # #------------------------------------------------------------------------- # If you are using ZCS under the network (commercial) license,
# Skin Colors #
# or to retain the original Zimbra logo. # # LogoImgDir = @AppContextPath@/skins/@SkinName@/logos # LogoURL = http://www.yourcompany.com # #========================================================================# ##########################################################################
NotificationBanner = @LogoImgDir@/NotificationBanner_grey.gif?v=@jsVersion@
#------------------------------------------------------------------------# # AppC = #EEEEEE AltC = #1558BE SelC = #DFECF5 TxtC = #333333 # #========================================================================# AppBannerImg = @LogoImgDir@/AppBanner_white.png?v=@jsVersion@
Decor1 = @DecorOpacity@ @img(, Decor1Img, 500px, 100px)@
LoginBannerImg = @LogoImgDir@/LoginBanner_white.png?v=@jsVersion@ LoginLabelColor = white LoginButton = @ButtonRounding@ @ButtonShadowDefault@ border:1px solid @ButtonBorderColor@; #IFNDEF MSIE_LOWER_THAN_9 DecorOpacity = @opacity(30)@ Decor1Img = @SkinImgDir@/Decoration.png?v=@jsVersion@ #ENDIF SkinSearchRadius = 4px
ButtonRounding = @roundCorners(3px)@
SkinTopRowColor = white SkinTopRowDividerColor = transparent SkinTextUsername = @Text-contrast@ font-weight:bold; AppTabBorder-normal = @Text-contrast@ AppTabRoundCorners = @roundCorners(3px 3px 0px 0px)@ ToastRoundCorners = @roundCorners(3px)@ ToastBackground = background-color:#FFC; CalendarNowColor = @AltC@ Text-link = color:#369;
Conv2Bg = background:url(@SkinImgDir@/convBkgd_48x48.png?v=@jsVersion@) repeat fixed;
ButtonRoundingLeft = @roundCorners(3px 0px 0px 3px)@ ButtonRoundingRight = @roundCorners(0px 3px 3px 0px)@ ButtonColorTop = white ButtonColorBottom = #DFE2E2 ButtonHovColorTop = white ButtonHovColorBottom = #B8DEF3 ButtonActColorTop = #E3F4FC ButtonActColorBottom = #74B6DD TabRoundCorners = border-collapse:separate; @roundCorners(3px 3px 0px 0px)@

Bueno, creo que para empezar con todas estas configuraciones tiene suficiente, espero les sirva para personalizar su Zimbra.

miércoles, 13 de mayo de 2015

El descenso a los infiernos de Hewlett-Packard. Una historia rocambolesca


HP300
Sencillamente impresionante la historia de Hewlett-Packard  también conocida como HP(NYSE:HPQ) y cómo pasar de ser una de las mayores empresas por capitalización bursátil del mundo a ver como una cadena de errores estratégicos y de gestión la está llevando directa a los infiernos. Sin duda todo un caso de estudio para muchas escuelas de negocios.
Empecemos por lo más visible.. la evolución de su cotización:
hp cotización en Bolsa
Desde principios de 2010 a día de hoy la acción de HP ha pasado de 55$ a 11$, una caída o pérdida del 80% del valor de la compañía. Un absoluto descalabro, en la que la compañía ha intentado despistar a los inversores tratando de incrementar sus resultados vía una frenética carrera de adquisiciones.
El pasado mes de junio os avisábamos en un post “La trampa: Jim Chaos sobre HP” en el que el manager de Kynikos Associates, diseccionaba porque lo de HP era totalmente insostenible y porque él estaba apostando agresivamente a la baja contra el precio de la acción ya que la compañía estaba en una especie de huida hacia adelante vía adquisiciones que le permitían salvar la publicación de resultados.

Un banquillo más caliente que el del Atlético de Madrid

Y es que desde que Lewis Platt dejó la compañía en 1999, el puesto de CEO de HP ha sido más caliente que el de un entrenador de fútbol. En la última década, HP ha tenido nueve diferentes CEO o Presidentes y desde Agosto de 2010 ya van tres CEOs diferentes, Cathie Lesjak ,  Léo Apotheker y la última  Meg Whitman.
Muchos hablan del cambio continuo y la destrucción creativa,pero 9 CEOs diferentes en una década tiene que ser demoledor para cualquier organización, ya sólo por eso es una clara señal que algo grave sucede en HP y lo mejor que podría hacer uno es ponerse corto en la acción.

El núcleo del negocio de HP se sigue desintegrándo

Mientras los respectivos CEOs se han embarcado en una carrera de adquisiciones frenética, ya sabéis que lo de adquirir compañías es algo bastante entretenido y que deja suculentos fees y bonus, el núcleo del negocio de HP sigue acelerando su deterioro. Estas son las cifras de los resultados que publicó ayer:
  • Sistemas Personales: Caída de ingresos del 14% respecto al año anterior.  Unidades de Desktops y Notebooks vendidas -12% .
  • División de impresión: Caída del -5% en los ingresos. Unidades vendidas de impresoras 20%.
  • Servicios: Caída de los ingresos por servicios  tecnológicos del -6% declined .
  • Servidores empresa almacenamiento y  Networking (ESSN): Caída de los ingresos del -9%.
Lo único que crece en HP, es Software business (+9%) y la división de  “Financial Services”, es decir la financiación de compras de productos a los clientes, este punto da francamente bastante miedo, ahora HP para poder vender algo se tiene que convertir en un banco.

Y llega el escándalo. Deals from Hell

Y bueno, ayer lo que hizo saltar todas las alarmas,  cómo no podría ser de otro modo, fue el anuncio que HP provisionaba el grueso de la inversión que había realizado en la adquisción en Agosto de 2011 de la firma británica Autonomy plc, en la que se gastó la friolera de 10.300 millones de dólares.
Parece ser que Autonomy, había falseado sus cuentas y básicamente HP había comprado humo.
La tarta de los fees
Por cierto, los bancos de inversión que asesoraron a HP fueron  Perella Weinberg Partners y  Barclays que se llevaron 35 millones de dólares en comisiones. Por el lado de Autonomy, actuaron como asesores Qatalyst Partners, UBS, Goldman Sachs,Citigroup, JPMorgan Chase and Bank of America Merrill Lynch, recibieron también entre  $35 $40 milliones.
Y después tenemos a los asesores legales, por parte de HP actuaron las firmas de abogados  Gibson, Dunn & Crutcher; Freshfields Bruckhaus Deringer; Drinker Biddle; and Skadden, Arps, Slate, Meagher & Flom.
Asesoraron a  Autonomy,  Morgan Lewis  y Slaughter & May.
En total en una operación que valoró a Autonomy en 10.500 millones de dólares, se repartieron casi 100 millones de dólares en fees de asesoramiento, el 1% 10% del valor de la compañía !  A la que podéis añadir el bonus que se debió llevar Léo Apotheker, el CEO de HP, por cerrar la adquisición. Por cierto fue lo últimos que hizo antes de dejar HP.
Y un último apunte. Los auditores de Autonomy, … Deloitte, firmaron obviamente la auditoria de Autonomy sin salvedades.

miércoles, 25 de febrero de 2015

DNSSEC


 Todos sabemos que el DNS es un protocolo que resuelve los nombres de dominio en direcciones IP, pero ¿cómo sabemos la autenticidad de la dirección IP devuelta? Es posible que un atacante pueda alterar una respuesta DNS o envenenar la caché DNS y redirigir los usuarios a un sitio malicioso con el nombre de dominio legítimo en la barra de direcciones. Las extensiones de seguridad DNS (DNSSEC) son una especificación que tiene por objeto el mantenimiento de la integridad de los datos de las respuestas DNS. DNSSEC firma todos los registros de recursos DNS (A, MX, CNAME, etc.) de una zona mediante PKI (Public Key Infrastructure). Las resoluciones de DNS habilitando DNSSEC (como Google Public DNS) pueden verificar la autenticidad de una respuesta DNS (que contiene una dirección IP) utilizando el registro DNSKEY público.

Acerca de DNSSEC


Un registro de recursos (RR) contiene una información específica sobre el dominio. Entre los más comunes son un registro que contiene la dirección IP del dominio, registro AAAA que contiene la información de IPv6, y registro MX que tiene servidores de correo de un dominio. Una lista completa de DNS RR se puede encontrar aquí .Del mismo modo DNSSEC también requiere varios RR.

DNSSEC registros de recursos

  • DNSKEY Contiene la clave pública que resolutores de seguridad.
  • RRSIG existe para cada RR y contiene la firma digital de un registro.
  • DS - Delegación Firmante - existe este registro en los servidores de nombres del dominios de primer nivel. Así que si example.com era su nombre de dominio, el TLD es "com" y sus servidores de nombres son a.gtld-servers.net., -b.gtld-servers.net. hasta m.gtld-servers.net. El objetivo de este registro es para verificar la autenticidad de la misma DNSKEY.


Nombre de Dominio: ejemplo.gob.ve 
Entorno de instalación

Nombre del servidor: DNS01  
Dirección IP: 192.168.200.2 y 172.16.0.195 (Virtual) Nombre de host: 
dns02.ejemplo.gob.ve SO: Debian 7

Nombre del servidor: DNS02   
Dirección IP: 192.168.200.2 y 172.16.0.196 (virtual) Nombre de host:  
dns02.ejemplo.gob.ve OS: Debian 7


Habilitar DNSSEC añadiendo las siguientes directivas de configuración dentro de /etc/bind/named.conf.options, Esto Puede variar dependiendo de como se configure el DNS y como se ordene la información.Configuración del maestro DNSSEC


dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
//bindkeys-file "/etc/bind/bind.keys";

Luego colocar la clave de DLV ISC para bind9, para este caso podemos usar Webmin para la tarea de simplificar el prceso, sin embargo acá dejo la clave para ser pegada en la ruta /etc/bind/named.conf.

trusted-keys {
dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh";
};
 
para hacerlo en webmin vamos a la configuración y abrimos el icono que dice:
Image  
  
 
Es este menú se puede configurar todo lo referente a la clave DLV, por defecto BIND crea la clave para la validación.

si se quiere crear una clave de zona, lo que se requiere es crear una clave ksk

martes, 24 de febrero de 2015

BIND9 TSIG

TSIG


TSIG (Transaction SIGnature, RFC 2845) es un método para firmar las transacciones y mensajes de DNS mediante el uso de claves simétricas (secretas) compartidas. Esto incluye los mensajes de consulta recursiva, notificación o consultas dig, aunque TSIG suele utilizarse sobre todo para proteger la transferencia de zonas de un dominio entre un servidor de DNS primario y su(s) secundario(s). TSIG opera con cifrado simétrico, es decir, los servidores implicados en la transacción comparten una misma clave. Esto nos permitirá restringir quién puede transferir las zonas DNS entre servidores. Es el caso que aplicaremos en este documento.Estrictamente hablando, TSIG no es parte de DNSSEC, pero asegurar la comunicación entre los DNS autoritativos suele ser un paso previo a asegurar las zonas con DNSSEC. Conviene saber que TSIG no cifra los datos en tránsito. Su firma digital preserva la integridad de las comunicaciones maestro-esclavo, no la confidencialidad, ya que los datos de una zona son esencialmente públicos pero, si se requiere confidencialidad, se debe configurar una VPN.

Configuración de TSIG
Para configurar TSIG es recomendable crear una clave por cada servidor esclavo. De esa forma, si un servidor esclavo se ve comprometido, solo será necesario reemplazar la clave almacenada en ese host.

Editar Sección

Creación de la clave

Para crear la clave TSIG usaremos dnssec-keygen, una utilidad incluida con bind9 para generar claves DNSSEC:
dnssec-keygen -a HMAC-SHA256 -b 112 -n HOST keyname
  • HMAC-SHA256 es el algoritmo utilizado para el cifrado.
  • 112 es la longitud de la clave (o el número de bits). La actual recomendación de NIST es usar HMAC-SHA256, con 112 bits.
  • HOST: HOST es la palabra clave utilizada para generar una clave para un cifrado de clave simétrico. Por convención, se suele usar como nombre de clave el nombre de host de ambos servidores ('dns01' y 'dns02' en este ejemplo), finalizado en un punto.
En nuestro caso:
$ dnssec-keygen -a HMAC-SHA256 -b 112 -n HOST dns01-dns02.dns01-dns02.+163+14005
163 identifica el algoritmo utilizado (HMAC_SHA256) y 14005 es la huella (útil en DNNSEC porque se permiten varias claves por zona).Si recibimos un error al usar el algoritmo HMAC-SHA256 (private key is invalid) deberemos actualizar nuestra versión de bind9, evitando así tener que usar algoritmos débiles como HMAC-MD5.El comando anterior nos creará dos pequeños ficheros de texto, uno con extensión .key y otro .private:

dns01-dns02.+163+14005.key  dns01-dns02.+163+14005.private

El fichero .key contiene un registro DNS KEY que puede usarse en un fichero de zona. El fichero con extensión -.private es el que nos interesa para nuestro caso: incluye información del algoritmo y la clave que necesitamos (aunque el fichero key contendrá igualmente la clave secreta). Este es su contenido:


$ cat dns01-dns02.+163+14005.private
Private-key-format: v1.3
Algorithm: 163 (HMAC_SHA256)
Key: 6f5p3ntxg81bTgkpeX4=Bits:
AAA=Created: 20130514083805
​Activate: 20130514083805
Publish: 20130514083805
Edit Plugin:code

La línea Key contiene la clave secreta (”6f5p3ntxg81bTgkpeX4=” en este ejemplo), que por supuesto deberemos proteger y guardar a buen recaudo y que usaremos para configurar bind9, nsd o el servidor DNS de nuestra elección con soporte TSIG. No es necesario copiar el fichero completo, basta con copiar la línea con la clave a nuestro fichero de configuración en nuestro servidor primario y secundario, como se explica a continuación.

Editar Sección

Configurar servidor DNS primario

Ahora que ya tenemos la clave, debemos incluirla tanto en la configuración del servidor DNS primario como en el secundario. Empezamos con el primario, editamos named.conf:
//TSIGkey===============================================================
dns01-dns02. { algorithm hmac-sha256; secret "6f5p3ntxg81bTgkpeX4="; };


Ahora debemos especificar que nuestro secundario (192.168.200.79 y 172.16.0.195) usará la clave dns01-dns02.:
server 192.168.200.79 {
keys {
};
dns01-dns02.; };
dns01-dns02.;
server 172.16.0.196 { keys { };
};

Por ejemplo:
zone "example.com" {
type master;
file "master/db.example.com";
allow-transfer {
​};
key dns01-dns02.;
};

Es una doble seguridad: no basta con conocer la clave, sino que debe proceder de la IP declarada para el secundario.

nota: Se puede cambiar el nombre de este ejemplo por el que se requiera, el nombre descriptivo que se le da a la clave no tiene nada que ver son esta, solo es una asociación, pues cuando el ve que existe la clave en el servidor DNS secundario es que procede a la trasferencia, así que esto es solo con el fin de que se pueda identificar fácilmente la clave y cambiarla de ser necesario. por este motivo también se debe colocar la misma nomenclatura en el servidor secundario.

Editar Sección

Configurar servidor DNS secundario

La configuración del servidor secundario también deberemos modificarla.  tendremos que editar named.conf, como hicimos con el primario, y añadir lo siguiente:

//TSIG ====================================================================
key dns01-dns02. { algorithm hmac-sha256; secret "6f5p3ntxg81bTgkpeX4="; };
server 172.16.0.195 {
server 192.168.200.14 { keys { dns01-dns02.; }; }; keys {
};
dns01-dns02.;
};

Para comprobar que la conexión TSIG funciona, modificamos un registro de zona en el primario (por ejemplo, cambiamos su número de serie). Al recargar el servidor, el maestro debería notificar al secundario que ha habido cambios e inmediatamente el esclavo debe intentar transferir la zona. Tambien puede optar por recargar el esclavo y este buscará recargar las zonas. Si TSIG está correctamente configurado deberíamos ver en los logs del primario algo parecido a esto:

Comprobación
May 14 10:48:26 foo named18123: zone example.com/IN: loaded serial 2013051401
May 14 10:48:26 foo named18123: zone example.com/IN: sending notifies (serial 2013051401)
May 14 10:48:26 foo named18123: client 1.2.3.4#57028: transfer of 'example.com/IN': AXFR-style IXFR started: TSIG dns01-dns02.
​May 14 10:48:26 foo named18123: client 1.2.3.4#57028: transfer of 'example.com/IN': AXFR-style IXFR ended
Y en el secundario:
<a class="wiki" href="1368521223" rel="">1368521223</a> nsd<a class="wiki" href="3508" rel="">3508</a>: info: Zone example.com serial 2013051301 is updated to 2013051401.


Si algo ha ido mal, obtendremos mensajes ”denied” en los logs. Deberemos revisar los ficheros de configuración (named.conf ), pues lo más probable es que hayamos cometido alguna errata.

para mas fuente de consulta visite http://doc.flossystems.com/es/security/dns/tsig

jueves, 19 de febrero de 2015

Script para crear Repositorios de DEBIAN

Como se podrá observar y se habrá visto en la información anterior de instalar debmirror en CENTOS, no existe soporte nativo de ese paquete, y a menos que se tenga un repositorio por rsync no se podrá descargar repositorios Debian para ser hosteados en CENTOS sin la necesidad de este. Por ello al usar esta herramienta hay que tener cuidado de poner las carpetas a sincronizar en diferentes subdirectorios, para evitar que por algún motivo el debmirror borre las carpetas fuera del ámbito del script en el mismo nivel del árbol.

También se recomienda usar el método http. pues el método debmirror y rsync ha arrojado errores con los archivos sources. Los scripts para sincronizar son los siguientes.

Debian MAIN 6,7,8
/usr/local/bin/debmirror --debug \
--progress \
--verbose \
--diff=none \
--host=mirrors.kernel.org \
--root=debian \
--method=http \
--dist=squeeze,wheezy,jessie,wheezy-updates,squeeze-updates,wheezy-backports \
--arch=i386,amd64 \
--nosource \
--section=main,contrib,non-free \
--i18n \
--getcontents \
--ignore-release-gpg \
--ignore-missing-release \
/repo/debian/main > /repo/rsync.log
echo "Culminada la Sincronizacion del repositorio debian arquitetura amd64." 
exit


Debian Security
/usr/local/bin/debmirror --debug \
--progress \
--verbose \
--diff=none \
--host=security.debian.org \
--root=:debian-security \
--method=http \
--dist=squeeze/updates,wheezy/updates,jessie/updates \
--arch=i386,amd64 \
--nosource \
--section=main,contrib,non-free \
--getcontents \
--ignore-release-gpg \
--ignore-missing-release \
--rsync-options=-aIL \
/repo/debian/security > /repo/rsync.log
echo "Culminada la Sincronizacion del repositorio debian security arquitetura amd64."
exit

Sepan disculpar la simpleza, pero espero igual les sea de utilidad.

Script para crear Repositorios de Centos

Los siguentes scrips permiten hacer un Rsync  de cualquier mirror de Centos que cuente con soporte de dicho protocolo, los archivos son los siguientes:
Antes de declarar los scripts debo comentar que creé un LVM aparte para repositorios, en este caso recomiendo por lo menos 500gb pues si se va a instalar paquetes centos y debian, se llenará rápidamente. Solo los de centos ocupan entre centos 6.5 y 7 que en mi caso son los que tengo habilitado junto a sus epel ocupa unos 150GB, así que tomen las previsiones del caso.
Script Centos 6.5
#!/bin/bash
#Test IF
VAR=`ps -ef | grep "rsync --progress --stats -av --delete --delete-excluded --exclude "isos" --exclude "i386" rsync://mirrors.kernel.org/centos/6.5/" | wc -l`
    echo $VAR
    if [ $VAR == 1 ]; then 
        echo "Sincronizando Repositorio Centos 6.5" 
        rsync --progress --stats -av --delete --delete-excluded --exclude "isos" --exclude "i386" rsync://mirrors.kernel.org/centos/6.5/ /repo/centos/6/ > /repo/rsync.log
    elif [ $VAR > 1  ]; then 
        echo "Servicio Operativo"
        exit
    fi
Edit Plugin:code

Script Centos 7
#!/bin/bash
#Test IF
VAR=`ps -ef | grep "rsync --progress --stats -av --delete --delete-excluded --exclude "isos" --exclude "i386" rsync://mirrors.kernel.org/centos/7.0.1406/" | wc -l`
echo $VAR
if [ $VAR == 1 ]; then 
echo "Sincronizando Repositorio Centos7" 
 rsync --progress --stats -av --delete --delete-excluded --exclude "isos" --exclude "i386" rsync://mirrors.kernel.org/centos/7/ /repo/centos/7/ > /repo/rsync.log
elif [ $VAR > 1  ]; then 
echo "Servicio Operativo"
exit
fi
Edit Plugin:code

Script EPEL Centos 6
#!/bin/bash
#Test IF
VAR=`ps -ef | grep "rsync --progress --stats" | wc -l`
if [ $VAR == 1 ]; then 
echo $VAR
echo "Sincronizando Repositorio EPEL Centos6" 
 rsync --progress --stats -av --delete --delete-excluded --exclude 'ppc64' --exclude 'i386' rsync://mirrors.kernel.org/fedora-epel/6/ /repo/epel/6/ > /repo/rsync.log
elif [ $VAR > 1  ]; then 
echo "Servicio en funcionamiento, para ver la salida utilice el comando "tail -f /repo/rsync.log" "
exit
fi
Edit Plugin:code

Script EPEL Centos 7
#!/bin/bash
#Test IF
VAR=`ps -ef | grep "rsync --progress --stats" | wc -l`
if [ $VAR == 1 ]; then 
echo $VAR
echo "Sincronizando Repositorio EPEL Centos7" 
 rsync --progress --stats -av --delete --delete-excluded --exclude 'ppc64' rsync://mirrors.kernel.org/fedora-epel/7/ /repo/epel/7/ > /repo/rsync.log
#rsync --progress --stats -av --delete --delete-excluded rsync://mirrors.neterra.net/epel/7/x86_64/ /repo/epel/7/x86_64/ > /repo/rsync.log
elif [ $VAR > 1  ]; then 
echo "Servicio en funcionamiento, para ver la salida utilice el comando "tail -f /repo/rsync.log" "
exit
fi
Edit Plugin:code

como puede apreciarse se está usando los repositorios de mirrors.kernel.org, debido a el gran ancho de banda que posee dicho repositorio, y la facilidad con que puede descargarse. 

HTTP/2 ha sido finalizado, la mayor actualización de HTTP en 16 años se acerca




Hace apenas unas horas, Mark Nottingham de la IETF ha publicado en su blog que el nuevo estándar HTTP/2 ha sido finalizado, y que ha sido enviado al RFC Editor para comenzar el proceso de publicación de la que será la mayor actualización del protocolo de transferencia de hipertexto desde que se implementó la versión HTTP 1.1 hace ya dieciséis años.

Esta actualización del protocolo que permite que los servidores web y los navegadores se comuniquen entre sí para que el usuario final pueda acceder al contenido de la red, traerá consigouna mayor velocidad en la carga de las páginas, una reducción de los errores de conexión y una menor carga en los servidores de las redes.

Esta versión 2.0 del HTTP está basada en SPDY el protocolo de comunicaciones que Googlepresentó hace algo más de cinco años para conseguir una mayor velocidad de carga de las webs, manipulando el tráfico para mejorar la latencia y la seguridad. Pero aunque la reducción de los tiempos de carga va a ser uno de los grandes alicientes del HTTP/2, no será el único.
Las novedades del nuevo protocolo

Además de la ya mencionada velocidad de carga, el nuevo estándar HTTP también innovará con una nueva función de multiplexación que permitirá que un servidor pueda responder a varias peticiones al mismo tiempo, de manera que no haya problemas de eficiencia y carga que provoquen bloqueos de las páginas.

HTTP/2 también usará bastantes menos conexiones, lo que debería dar como resultadouna menor carga en los servidores y páginas web. Además, también traerá buenas noticias para los desarrolladores, pues será compatible con el código escrito hasta ahora al mantener la misma API HTTP que se ha estado actualizando hasta hoy, haciendo simplemente que todas las mejoras sean opcionales.

Aunque hace unos meses saltó el rumor de que HTTP/2 podría funcionar únicamente a través de conexiones cifradas, de momento no se han tomado medidas tan drásticas para mejorar la seguridad, aunque en las FAQ del proyecto sí que vemos que se están debatiendo posibilidades como la utilización del cifrado oportunista por http:// URI sin autenticación del servidor.

Google ya anunció hace unos días que Chrome empezaría a utilizar HTTP/2 en cuanto estuviese listo, por lo que algunas de sus funciones ya pueden ser probadas tanto en su navegador como en Firefox. Además, seguramente el resto de empresas empiece a adoptar también el protocolo en sus navegadores en cuanto este sea publicado de forma oficial, lo cual no debería tardar demasiado.