Etiqueta: apache

Despliegue Apache Hadoop sobre Debian

Despliegue de Apache hadoop sobre Debian con un nodo único.

Esta guía particulariza la instalación sobre un servidor Debian, actualizando las rutas y valores que en la guía original de Hadoop, es necesario cambiar para que funcione.

Instalación de paquetes previos

 sudo apt-get install -y ssh rsync

Instalación de los paquetes propios de Apache Hadoop 2.9 (versión estable:

wget http://apache.uvigo.es/hadoop/common/stable/hadoop-2.9.0.tar.gz ;
# Descomprimir:
tar -xvzf hadoop-2.9.0.tar.gz ;
# Moverlo a /usr/bin
sudo mv hadoop-2.9.0 /usr/bin/hadoop-2.9.0 ;
# Creo un enlace, para no tener que buscar las rutas:
sudo ln -s /usr/bin/hadoop-2.9.0/bin/hadoop /usr/bin/hadoop

Configuración del entorno

Cambiar en la configuración, la ruta donde tengamos en nuestro sistema java.

whereis java; 
medit /usr/bin/hadoop-2.9.0/etc/hadoop/hadoop-env.sh
# set to the root of your Java installation
 export JAVA_HOME=/usr/bin/java

Iniciar Hadoop

Al haber creado ya un enlace durante la instalación, es suficiente con invocar hadoop de la siguiente manera:

hadoop

Desinstalación

rm -rf /usr/bin/hadoop-2.9.0
rm -rf /usr/bin/hadoop

Más información: https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/SingleCluster.html

Puppet: Crear nuevos tipos para recursos

Un recurso (resource) en puppet es la unidad mínima de configuración.  Puppet viene con algunos recursos ya predefinidos (built-in) como son:

Los recursos, a la hora de instanciarse tienen un nombre propio de instancia, y se pueden invocar tantos como sean necesarios.

Es la diferencia más interesante respecto de una clase. La clase se aplica de forma única sobre el servidor; pero la clase puede tener N instancias de un recurso.

Vamos a ver cómo definir los recursos más simples, en el lenguaje declarativo de puppet.

Este ejemplo está sacado de puppetlabs:
# /etc/puppetlabs/puppet/modules/apache/manifests/vhost.pp
define apache::vhost (Integer $port, String[1] $docroot, String[1] $servername = $title, String $vhost_name = '*') {
  include apache # contains Package['httpd'] and Service['httpd']
  include apache::params # contains common config settings
  $vhost_dir = $apache::params::vhost_dir
  file { "${vhost_dir}/${servername}.conf":
    content => template('apache/vhost-default.conf.erb'),
      # This template can access all of the parameters and variables from above.
    owner   => 'www',
    group   => 'www',
    mode    => '644',
    require => Package['httpd'],
    notify  => Service['httpd'],
  }
}

Dado que está parametrizado, se pueden invocar N instancias distintas de vhost en nuestra clase.

Para invocar una instancia, es necesario ponerle un nombre y

<TYPE> { '<TITLE>':
  <ATTRIBUTE> => <VALUE>,
}

El ejemplo básico para el nuestro, sería en un servidor, pasar a definir varios vhosts distintos:

apache::vhost {'homepages':
  port    => 8081, # Becomes the value of $port
  docroot => '/var/www-testhost', # Becomes the value of $docroot
}


apache::vhost {'redmine':
  port    => 80, # Becomes the value of $port
  docroot => '/var/www/redmine', # Becomes the value of $docroot
}
 

Autenticación de apache con Directorio Activo. LDAP, NTLM

Queremos que una serie de máquinas con apache, usen el siguiente método de autenticación:

  1. Validar usuario en directorio activo
  2. Validar usuario local (si hay problemas con el directorio activo).

Instalamos los módulos de apache para aceptar ldap:

apt-get install -y libapache-authznetldap-perl  libapache-session-ldap-perl libapache2-mod-ldap-userdir

Activamos el módulo de ldap en apache

a2enmod authnz_ldap

Versión 1: Usuario válido en dominio

El excelente tutorial de adam.shand.net , nos propone una primera versión:
<Location /aplicacion1>
AuthType Basic
AuthBasicProvider ldap
AuthName "Restricted Directory"
require valid-user

AuthLDAPURL ldap://adserver.domain.com/dc=domain,dc=com?sAMAccountName?sub
AuthLDAPBindDN anonymous@domain.com
AuthLDAPBindPassword secretpassword
</Location>

Para probar la cadena de conexión, se puede usar Apache Directory Studio.

Versión 2: Usuario válido en dominio de un grupo concreto (member of)

Añadimos en el parámetro AuthLDAPURL, la consulta después de sub, para que coja los usuarios de un dominio concreto.

<Location /aplicacion1>
AuthType Basic
AuthBasicProvider ldap
AuthName "Restricted Directory"
require valid-user

AuthLDAPURL ldap://adserver.domain.com/dc=domain,dc=com?sAMAccountName?sub?(memberOf=CN=departmentA,CN=Users,DC=domain,DC=com)
AuthLDAPBindDN anonymous@domain.com
AuthLDAPBindPassword secretpassword
</Location>

Versión 3: Aceptar también usuarios locales

Cambiamos el comportamiento de la autenticación ldap, para que no sea la única opción, con AuthzLDAPAuthoritative off

Además, aceptamos también la configuración desde nuestro fichero local de usuarios

<Location /aplicacion1>
AuthType Basic
AuthName "Restricted Directory"
AuthBasicProvider ldap
require valid-user

# Configuracion contra directorio activo:
AuthLDAPURL
ldap://adserver.domain.com/dc=domain,dc=com?sAMAccountName?sub?(memberOf=CN=departmentA,CN=Users,DC=domain,DC=com)
AuthLDAPBindDN anonymous@domain.com
AuthLDAPBindPassword secretpassword

AuthzLDAPAuthoritative off

# Configuración local

AuthUserFile /etc/apache/.htpasswd
AuthGroupFile /dev/null

Para crear el archivo local de contraseñas en apache:

htpasswd -c .htpasswd user

 

Para editar las contraseñas de un usuario concreto:

 

htpasswd .htpasswd user

 

Versión 4: aceptando también ntlm

 

Para rizar el rizo, querríamos que acepte las credenciales de windows de forma directa, sin que el usuario tenga que introducir las credenciales.

Vamos a usar el módulo Apache2::AuthenNTLM

El problema es que no se verifica el grupo de dominio, cualquier usuario que exista en dominio, entra en el apache.

<Location /aplicacion1>
AuthType ntlm, Basic
AuthBasicProvider ldap
AuthName "Restricted Directory"
require valid-user

# Configuracion contra directorio activo:
AuthLDAPURL
ldap://adserver.domain.com/dc=domain,dc=com?sAMAccountName?sub?(memberOf=CN=departmentA,CN=Users,DC=domain,DC=com)
AuthLDAPBindDN anonymous@domain.com
AuthLDAPBindPassword secretpassword

AuthzLDAPAuthoritative off

# Configuración local
# Configuración ntlm:
# domain pdc bdc
# pdc: primary domain controller
# bdc: backup domain controller
PerlAddVar ntdomain “name_domain1 name_of_pdc1”
PerlAddVar ntdomain “other_domain pdc_for_domain bdc_for_domain”

PerlSetVar defaultdomain wingr1
PerlSetVar splitdomainprefix 1
PerlSetVar ntlmdebug 1

AuthUserFile /etc/apache/.htpasswd
AuthGroupFile /dev/null

Versión 5: ntlm con módulo python

Legrandin  nos propone un módulo python para hacer más sencilla la integración con ntlm version 2.

El problema de este tipo de acceso, es que no permite autenticar sin el dominio. En caso de caida o aislamiento del dominio, no se puede recaer en los usuarios locales de nagios.

Existe opción de especificar grupos de dominios, aunque es experimental.

Instalar módulos que nos faltan:


sudo apt-get update
sudo apt-get install libapache2-mod-python python-crypto git
git clone https://github.com/Legrandin/PyAuthenNTLM2.git
cd PyAuthenNTLM2
sudo python setup.py install -f

La configuración de apache quedaría:

<Location /aplicacion1>
AuthType ntlm
AuthName "Restricted Directory"
require valid-user
# Configuración de autenticación ntlm:
PythonAuthenHandler pyntlm
PythonOption Domain adserver.domain.com
# pdc : Primary Domain Controller
PythonOption PDC 192.1.2.45
# bdc : Backup Domain controller.
PythonOption BDC 192.1.2.46
Require group grupo_dominio1,grupo_dominio2

Versión 6: libapache2-authenntlm-perl

Vamos a probar authenntlm-perl, que, según este tutorial es ridículamente fácil:

apt-get install libapache2-authenntlm-perl

Instalación en local Solr sobre Windows 7

Vamos a definir una instalación mínima de solr sobre windows 7. Dada la cantidad de información que hay en Internet, nos ha parecido importante hacer un resumen concreto de cómo montar una pequeña maqueta solr sobre windows 7. A partir de aqui, os recomendamos continuar vuestro periplo con solr a través de los siguientes tutoriales

Instalación de TomCat:

Descarga: http://tomcat.apache.org/download-70.cgi

PS > cd ‘.\Program Files (x86)’\apache-tomcat-7.0.42-windows-x64\apache-tomcat-7.0.42\bin\service.bat install

Instalación de Solr en local:

  1. Descarga la última versión https://builds.apache.org/job/Solr-Artifacts-4.x/
  2. Descompresión del archivo. Al ser un ejecutable JAVA no requiere instalación, pero sí requiere una instalación previa de la máquina virtual Java. (C:\Program Files (x86)\solr-4.5-2013-07-23_11-36-16\ )
  3. Para lanzar el motor de solr desde powershell, hay que cambiar la variable de entorno para la sesión:

    PS > $env:path += “;C:\Program Files (x86)\Java\jre6\bin\”

    PS > java.exe -jar .\start.jar

Esto es una instalación de pruebas, por ello, no se ha dado de alta como servicio de windows. Lo normal sería que el motor solr se inicie con el propio windows.

A partir de aquí, podemos añadir contenidos a Solr para indexación. El ejemplo que nos dan en solr sería:

  PS C:\Program Files (x86)\solr-4.5-2013-07-23_11-36-16\example\exampledocs> java -jar post.jar *.xml

Y para probar que hay contenidos:

http://localhost:8983/solr/collection1/browse?q=monitor