Instalar Apache 2.4 en CentOS 6

Voy a ir bastante al grano. Es para instalar la versión Apache 2.4.7.

yum -y install rpm-build

mkdir -p ~/rpmbuild/{SOURCES,SPECS,BUILD,RPMS,SRPMS}

cd ~/rpmbuild/SOURCES

wget http://ftp.cixug.es/apache//httpd/httpd-2.4.7.tar.bz2

En general, si ejecutamos lo siguiente fallará (sino perfecto y te ahorrarás un montón de pasos siguientes…)

rpmbuild -tb httpd-2.4.7.tar.bz2

Para corregir esto hay que instalar un montón de cosas

cd ~/rpmbuild/SOURCES

wget http://ftp.cixug.es/apache//apr/apr-1.5.0.tar.bz2

wget http://ftp.cixug.es/apache//apr/apr-util-1.5.3.tar.bz2

cd ~/rpmbuild/SOURCES

Ahora tendremos un tema y es que hay que tocar cosas del kernel. Como eso suele estar bloqueado, deberemos hacer lo siguiente

sudo vi /etc/yum.conf

y aquí, en el fichero, debemos comentar o eliminar la línea correspondiente (vamos a comentarla)

#exclude=kernel*

A partir de aquí seguimos adelante

sudo yum install kernel-headers

yum -y install autoconf libtool doxygen

rpmbuild -tb apr-1.5.0.tar.bz2

Es probable que esto último falle. Si pasa esto, haremos una revisión de los rpm instalados anteriormente

rpm -qa | grep -i apr

Si existen paquetes anteriores, haremos un “update”, sino un “install”

# UPDATE:
rpm -U ~/rpmbuild/RPMS/x86_64/apr-1.5.0-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-devel-1.5.0-1.x86_64.rpm

#INSTALL
rpm -ivh ~/rpmbuild/RPMS/x86_64/apr-1.5.0-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-devel-1.5.0-1.x86_64.rpm

y continuamos:

yum -y install expat-devel libuuid-devel db4-devel postgresql-devel mysql-devel freetds-devel unixODBC-devel openldap-devel nss-devel

cd ~/rpmbuild/SOURCES

yum install sqlite-devel

rpm -ivh ftp://fr2.rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

cd /etc/yum.repos.d/

wget http://rpms.famillecollet.com/enterprise/remi.repo

yum install freetds freetds-devel

cd ~/rpmbuild/SOURCES

rpmbuild -tb apr-util-1.5.3.tar.bz2

cd ~/rpmbuild/SOURCES

Aquí nos encontramos con la situación anterior… revisamos si existen los paquetes

rpm -qa | grep -i apr-util

Si existen paquetes anteriores, haremos un “update”, sino un “install”

#UPDATE
rpm -U ~/rpmbuild/RPMS/x86_64/apr-util-1.5.3-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-util-devel-1.5.3-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-util-ldap-1.5.3-1.x86_64.rpm

#INSTALL
rpm -ivh ~/rpmbuild/RPMS/x86_64/apr-util-1.5.3-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-util-devel-1.5.3-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/apr-util-ldap-1.5.3-1.x86_64.rpm

y continuamos

cd ~/rpmbuild/SRPMS

wget http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/releases/18/Fedora/source/SRPMS/d/distcache-1.4.5-23.src.rpm

rpmbuild --rebuild distcache-1.4.5-23.src.rpm

rpm -ivh ~/rpmbuild/RPMS/x86_64/distcache-1.4.5-23.x86_64.rpm ~/rpmbuild/RPMS/x86_64/distcache-devel-1.4.5-23.x86_64.rpm

cd ~/rpmbuild/SOURCES/

yum -y install pcre-devel lua-devel libxml2-devel

rpmbuild -tb httpd-2.4.7.tar.bz2

yum -y install mailcap httpd-mmn

Aquí hemos de revisar un par de cosas… la primera es si ya teníamos un Apache instalado anteriormente, y el PHP… en este último caso, deberíamos desinstalar PHP (luego reinstalarlo).

#UPDATE APACHE HTTPD
rpm -U ~/rpmbuild/RPMS/x86_64/httpd-2.4.7-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/httpd-tools-2.4.7-1.x86_64.rpm

#INSTALL APACHE HTTPD
rpm -ivh ~/rpmbuild/RPMS/x86_64/httpd-2.4.7-1.x86_64.rpm ~/rpmbuild/RPMS/x86_64/httpd-tools-2.4.7-1.x86_64.rpm

Para acabar, pondremos correctamente los ficheros de configuración (en caso de que hubiera una instalación anterior)

mv /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.old

mv /etc/httpd/conf/httpd.conf.rpmnew /etc/httpd/conf/httpd.conf

Y con esto debería estar vuestro Apache HTTPD 2.4.7 instalado y funcionando, aunque ahora toca configurarlo.

HTML 5.1: elementos contenedores

Una de las grandes novedades en HTML 5 fue la incorporación tras muchos años de distintos contenedores que no dejan de ser más que un div pero que implícitamente incorporan cierto significado. En los nuevos borradores de HTML 5.1 se incorporan mejoras sobre estos elementos. Los elementos de los que estoy hablando son los siguientes:

Antes de nada voy a intentar hacer un repaso de cada uno de ellos, por orden alfabético, y al finalizar intentar poner un ejemplo de cómo debería construirse una página en base a estas informaciones.

address

Este elemento cambió radicalmente su concepto entre HTML 4 y HTML 5, y en esta última versión mantiene este nuevo sentido. El address representa la información de contacto del article más cercano (o padre) o del body en sí. Si se encuentra en el body sin un contenedor padre, se aplica a todo el documento.

El elemento address no debe representar una dirección postal, sino que debe aportar información de contacto relevante (por ejemplo el nombre, dirección de correo, un twitter, una dirección de facebook o similar), del autor del contenido en el que se encuentra. Este elemento sólo debe usarse para esta acción, la de dar información de contacto.

article

El elemento article representa de forma completa un contenido que podría ser reutilizado de forma independiente. Para poner un ejemplo claro, en una página de un periódico de papel, cada noticia sería un artículo por sí mismo, ya que tiene independencia completa de cualquier otro.

El elemento article puede contener otros article (o sea, es anidable), lo que significa que cada uno de esos elementos “pequeños” son independientes, pero conjuntamente pueden formar otro gran contenido.

En caso de querer indicar la información del autor de un article hay que utilizar el elemento address, y este es sólo aplicable a los extremos (es decir, no funciona en elementos contenedores, sino en los contenidos).

aside

El elemento aside representa una zona de la página con contenido “tangencialmente relacionado” al contenido principal de la página, pero que puede considerarse separado del mismo.

Volviendo al ejemplo de los periódicos, vendría a ser esos pequeños textos que suele haber en una noticia pero que no son la noticia en sí. Este bloque puede ser para dar información en otro tipo de tipografía, anuncios, grupos de enlaces y navegación o similar, que pueden considerarse independientes del contenido principal de la página.

body

El elemento body representa el contenido del documento, y por tanto sólo puede haber uno en cada página. Este es uno de los elementos más históricos del HTML, por lo que no creo que necesite mucha explicación.

div

El elemento div no tiene un significado especial, es simplemente un contenedor que permite agregarle información semántica no implícita. Es uno de los elementos “comodín”.

Por ejemplo, si tuviéramos una noticia en la que hay varios fragmentos de texto en varios idiomas, podríamos usar este elemento para indicar dicho idioma, pero no afectaría a, por ejemplo, que en un article haya varios div, a nivel semántico.

footer

Este es otro de los elementos que se añadió en la anterior versión y que tiene algunas diferencias con lo que habitualmente se tiene presente. Este elemento no es para simplemente dar formato al pie de página, sino que tiene muchos otros significados.

El footer representa el pie de su elemento superior (ya sea uno de los contenedores o de todo el body). En general el footer incluye información del autor, enlaces a documentos relacionados, copyright y similares.

Cuando encontramos que en el footer tenemos secciones enteras, podemos considerar que representan índices, licencias y contenidos por el estilo.

La información del autor, aunque se encuentre dentro del footer habría que integrarla en el elemento address (aunque sea en el footer mismo). En general este elemento se podría intercambiar con el header, aunque suele dejarse para ampliar o dar interpretaciones del autor a los elementos principales.

También hay que tener en cuenta que el footer no tiene que encontrarse obligatoriamente al final de un contenedor.

header

El elemento header representa el contenido introductorio del contenedor en el que se aloja. En general encontramos elementos introductorios o navigacionales.

En general aquí encontramos elementos como encabezados (los h1h6), aunque también podría ser una “tabla de contenidos”, una caja de búsqueda o el logo.

Al igual que ocurre con el footer, se suelen utilizar únicamente como la cabecera y pie de una página (body) pero no se les da un uso habitual y debido en los article o section.

Este elemento no puede estar anidado en sí mismo, pero sí sobre sus diferentes padres, lo que permite que haya varios en una página.

main

Este es quizá uno de los elementos más esperados en HTML, y que se complementa de forma perfecta con los elementos incorporados en HTML 5.

El elemento main representa el contenido principal de un body. Digamos que el main es el contenido principal de la página, donde se encuentra la chicha, donde se encuentra la zona principal de la aplicación.

Hay que tener en cuenta que este elemento no permite ser parte de otros elementos como article o section, aunque sí del body, y que sólo puede haber un main por página.

El elemento main debería incorporar el contenido principal de la página, incluyendo elementos como los datos del autor, copyright, enlaces, logos, buscador, etc… siempre y cuando tengan relación con el contenido principal del documento.

nav

El elemento nav representa una zona de la página en la que hay enlaces a otras páginas o a otras zonas de la página.

Hay que tener en cuenta que esto, en principio, no debería ser un listado de elementos, sino una zona de navegación. Esto significa que no todos los enlaces de una página han de encontrarse dentro de este elemento.

Los sitios más habituales donde encontraremos este elementos son al final de la página, dentro de un footer, donde se va a los términos y condiciones, a la página principal… También los podemos encontrar de forma habitual dentro de los aside, enlaces relacionados con el contenido principal.

section

El elemento section hace referencia a cada uno de los bloques genéricos de un gran contenido. Por ejemplo, dentro de la noticia de un periódico que tenemos un titular (probablemente con un h1) y varios subtítulos (seguramente con varios h2h6), cada uno de estos bloques probablemente sea un section.

Ejemplos variados podrían ser los distintos capítulos, diferentes pestañas dentro de una página o las distintas partes de una tesis. En una página web podría ser la introducción, las noticias y la información de contacto.

En general el section queda bastante relegado al elemento article que le da más sentido al contenido en sí. La gran diferencia entre section y article es que el section forma parte de algo, y el article es el algo en sí mismo.

Llegados a este punto…

…podríamos decir que ya tenemos claro los distintos elementos contenedores que podemos encontrar en un documento HTML, y en general quedaría claro cómo organizar una página.

Un ejemplo sencillo es el de un blog. Un blog suele tener dos páginas principales para nuestro caso: los listados y los artículos. El caso de los listados la página debería tener algo como:

  • body
  • header
  • /header
  • main
  • section
  • /section
  • section
  • /section
  • section
  • /section
  • section
  • /section
  • section
  • /section
  • /main
  • section
  • nav
  • /nav
  • /section
  • footer
  • nav
  • /nav
  • /footer
  • /body

Tenemos un body principal que hace referencia a todo el documento. En él tenemos una cabecera header que sería el titulo del blog, un cajetín de búsqueda, logos, publicidad, etc…

A partir de aquí tenemos el contenido principal main que es el listado de los artículos, que vendían representados por cada uno de esos section. Dependiendo del formato de cada uno de estos, podríamos considerar añadir su propia cabecera (header), pie (footer) y otros elementos (aside, nav…), aunque teniendo en cuenta que, por norma general los listados no contienen los artículos completos como en su propia página, no tendría sentido.

Tras esto tendríamos otra sección section que puede corresponder al menú lateral de navegación, opciones o como lo queramos llamar, en el que entre otras cosas podemos tener un menú de navegación nav (o varios) a otros listados (últimos artículos, últimos comentarios, publicidad, etc…).

Para acabar tenemos un pie de página en el que indicar cierta información, por ejemplo legal, además de un bloque de enlaces a distintas zonas de la página, y finalmente cerramos el contenido de la página.

Siguiendo con el mismo ejemplo, en este caso ya sí que de la entrada en concreto, podríamos tener los siguientes elementos:

  • body
  • header
  • /header
  • main
  • article
  • header
  • /header
  • section
  • /section
  • aside
  • /aside
  • section
  • /section
  • footer
  • address
  • /address
  • nav
  • /nav
  • /footer
  • /article
  • section
  • /section
  • /main
  • section
  • nav
  • /nav
  • /section
  • footer
  • nav
  • /nav
  • /footer
  • /body

Al igual que en el caso anterior, tenemos el cuerpo del documento, con su cabecera (igual que en el listado) y me voy a enfocar en este caso sólo a la parte principal main que es lo que cambia.

En este caso tenemos el contenido principal main que incluye un artículo article en el que existe una cabecera header (con el título del documento, la fecha de creación… entre otras cosas) y un primer bloque de información section.

Junto a esto tenemos otro bloque de contenido relacionado aside, dentro del mismo artículo, y otra sección, al que se finaliza con un pie de artículo footer en el que se incluye información del autor address además de enlaces a otras etiquetas nav, una zona para compartir el artículo.

Cuando se acaba la entrada article tenemos un bloque de comentarios section.

A partir de aquí ya tenemos lo mismo que en la plantilla de los listados, un menú lateral y un pie de página general.

Conclusión

Sin duda los elementos que añadió HTML 5, más el elemento main añadido en HTML 5.1 hacen que a nivel de organización de una plantilla, de una página o de cualquier tipo de documento generado en HTML se disponga de un significado semántico que si se aplica correctamente ayuda de forma elegante a las máquinas a comprender qué queremos destacar dentro de cada documento.

Personalmente creo que teniendo un poco de cuidado, principalmente con la anidación de elementos, y no haciendo un uso abusivo de ellos, se pueden conseguir grandes mejoras a la hora de desarrollar para Internet.