1.- Instalamos sql server 2005 express. Ya que esta version no dispone de herramienta grafica para sentencias SQL podemos instalar también “Sql server 2005 express management studio” o la que queramos para conectarnos en remoto o local.

 2.- Creamos una instancia llamada “openwiki” con usuario sa y el password. Propietario de la bbdd (dbo)

 3.- Descargamos el base de openwiki (yo me he bajado openwiking_20060322.zip). Esto es un zip que podemos convertir en ejecutable con NDIS seleccionando el zip.

 4.- Instalamos el ejecutable en la ruta que queramos

5.- Editamos el fichero “owconfig_default.asp” con atencion a:

OPENWIKI_DB_SYNTAX = DB_SQLSERVER
OPENWIKI_DB = "Driver={SQL Server};server=localhost;uid=sa;pwd=root;database=openwiki"

6.- Editamos el fichero “owconfig_db.asp”

OPENWIKI_DB = "openwiking"

7.- Por defecto la instalacion de SQL server Express viene con algunos servicios deshabilitados. Desde Configuracion de superficie de SQL Server habilitamos el browser (obligatorio) y permitimos conexiones remotas TCP/IP. Reiniciamos aambos servicios.

 8.- Accediendo al SQL Server configuration manager vamos a SQL Native Client Configuration -> Client Protocols -> TCP/IP, vemos que escucha por el puerto 1433 (default port). Si hacemos un netstat, veremos que no esta levantado.

 9.- No tenemos que asignar a nuestra interfaz de red: SQL Server 2005 Network Configuration -> Protocols -> TCP/IP -> IP Adresses -> (IP All) -> (TCP Port)

 10.- Reiniamos ambos servicios

 11.- Creamos nuestra bbdd en SQL con los scripts adjunto sen el zip de openwiki. Los datos de conexion a la BBDD deberan de ser los correspondientes a esta base de datos.

 12.- Creamos el conector ODBC en Windows que se conectara al configurado en la linea anterior. El nombre sera el valor que nos indica anteriormente “openwiking”. Prestando atencion a marcar el puerto 1433 para la conexion.

 13.- Creamos un sitio web ( en el IIS 5 debe ser el por defecto) para luego asignar un directorio virtual asignado a la carpeta “ow”. Nos aseguramops delos permisos de la carpeta. Que tenemos habilitado ASP.NET.

 14.- Lo exploramos con el navegador.

En versiones anteriores de IIS como la version 4 y 5, la configuracion del IIS se guardaba en un fichero binario que no era posible de editar.

Claramente solo se podian hacer modificacion en en la configuracion del IIS mediante la consola (inetmgr).

Pero en la version 6 DEL iis la configuracion se parsea en un fichero xml facil de editar. Esta localizado en : C:\WINDOWS\system32\inetsrv\

Ademas desde la consola tenemos la posibilidad de seleccionar que este fichero se pueda editar mmientras el IIS esta corriendo para que no sea necesario pararlo y entorpecer elk servicio.

Cada vez que se modifica el fichero XML de la metabase, el IIS automaticamente guarda una copia de seguridad en la carpeta C:\WINDOWS\system32\inetsrv\History

Seguramente muchos de los sitios web que usamos no requieran un app pool, ya que no usaran ASP.NET al ser unicamente html’s estaticos.

Backup manual de IIS

Suponemos que queremos disponer de los mismos directorios virtuales y pasarlos de un IIS a otro de otra maquina.

En los IIS version 6 existe un fichero xml que tiene etiquetada la configuracion del IIS. Como en un principio solo vamos a migrar los directorios virtuales, pued editaremos este fichero y copiaremos unicamente lo que nos haga falta en este caso.

Lo ideal seria al migrar copiar unicamente los virtual directories, excluyendo el sePlugin

El fichero esta esn: D:\WINNT\system32\inetsrv\MetaBase.xml

  Hacer un backup antes!.

1.- Llamada al web site:

<IIsWebServer        Location ="/LM/W3SVC/278075026"
                AuthFlags="0"
                LogPluginClsid="{FF160663-DE82-11CF-BC0A-00AA006111E0}"
                ServerAutoStart="TRUE"
                ServerBindings="192.168.0.33:80:"
                ServerComment="Web_Cuenta_Site"
        >
</IIsWebServer>

2.- Filtros del web site:

<IIsFilters        Location ="/LM/W3SVC/278075026/filters"
        >
</IIsFilters>

 3.- Directorios virtuales y su configuracion:

<IIsWebVirtualDir        Location ="/LM/W3SVC/278075026/root"
                AccessFlags="AccessRead | AccessScript"
                AppFriendlyName="Default Application"
                AppIsolated="2"
                AppRoot="/LM/W3SVC/278075026/Root"
                AuthFlags="AuthAnonymous | AuthNTLM"
                DirBrowseFlags="DirBrowseShowDate | DirBrowseShowTime | DirBrowseShowSize | DirBrowseShowExtension | DirBrowseShowLongDate | EnableDefaultDoc"
                Path="C:\Inetpub\wwwroot"
        >
</IIsWebVirtualDir>
<IIsWebVirtualDir        Location ="/LM/W3SVC/278075026/root/ArquitecturaE-bussines"
                AccessFlags="AccessRead"
                DirBrowseFlags="DirBrowseShowDate | DirBrowseShowTime | DirBrowseShowSize | DirBrowseShowExtension | DirBrowseShowLongDate | EnableDefaultDoc"
                Path="D:\WWW\Html"
        >
</IIsWebVirtualDir>
<IIsWebVirtualDir        Location ="/LM/W3SVC/278075026/root/BDPSCF_ENS"
                AccessFlags="AccessRead"
                DirBrowseFlags="DirBrowseShowDate | DirBrowseShowTime | DirBrowseShowSize | DirBrowseShowExtension | DirBrowseShowLongDate | EnableDefaultDoc"
                Path="D:\WWW\Html"
        >
</IIsWebVirtualDir>

Existe una consola grafica que permite hacer esta migracion: IIS6 Resource Kit

Este manual es basico de instalacion. Si quereis conocer la sintaxis una vez instalado lo mejor es buscar por google y editar una de las paginas de OpenWiki para ver como se trabaja con ella (enlaces, imagenes, letra en negrita…..)

Instalamos un Windows 2003 Server SP2 (en mi caso) con un IIS 6 y ASP.NET activado.

Descargamos el zip de OpenWiki http://www.openwiki.com/ow.asp?OpenWiki

Descargamos e instalamos el parser de XML’s de Microsoft

Los datos y cambios registrados de OpenWiki pueden ir en una base de datos local (.mbd) o en una BBDD externa como SQL Server. Yo lo he instalado en las dos, pero me quedo con esta ultima debido a su escalabilidad y mayor fiabilidad (con esta podemos hacer “buenos” backups).

Si elegimos SQL Server instalaremos el producto con sus parches y crearemos una BBDD en blanco con un usuario valido que luego pasaremos a OpenWiki para su acceso. Ademas debemos de ejecutar dentro las sentencias localizadas en el fichero: “C:\OpenWiki\data\OpenWiki-SqlServer.sql”

Descomprimimos en una carpeta temporal el zip de OpenWiki y accedemos a la ruta /openwiki/installer donde tenemos el instalador para Windows. Tambien se puede instalar a mano con un bat y “NSIS Installer”.

Ejecutamos el OpenWiki_078sp1.exe y nos pedira la ruta a instalar el producto. Durante la instalación nos crea un sitio web en el IIS que casi no hay que tocar para nada.

Ahora configuramos el acceso a la BBDD en el fichero C:\OpenWiki\owbase\ow\owconfig_defatult.asp

Configuramos lo siguiente:

Acceso a la BBDD si es SQL Server:

OPENWIKI_DB = “Driver={SQL Server};server=localhost;uid=sa;pwd=sa;database=openwiki2″

Acceso si es local de tipo “.mdb”:

OPENWIKI_DB = “Driver={Microsoft Access Driver (*.mdb)};DBQ=C:\OpenWiki\data\OpenWikiDist.mdb”

Configuracion de version del parser de xml’s:

MSXML_VERSION = 4 ‘ use 4 if you’ve installed MSXML v4.0

Configuracion adiccional:

OPENWIKI_DB_SYNTAX = DB_SQLSERVER ‘ Opcional, yo no lo he puesto

De seguridad:

gReadPassword = “pwd_lectura” ‘ use empty string “” if anyone may read
gEditPassword = “pwd_escritura” ‘ use empty string “” if anyone may edit

Hecho esto podemos reiniciar el IIS y acceder a la URL:

http://localhost/OpenWiki/

Pongo un enlace muy valioso a la URL de donde me base para instalarlo

export DISPLAY=192.168.0.33:0.0

/opt/IHS6/bin/ikeyman

Aqui crearemos una BBDD de tipo CMS:

y creamos una peticion de certificado:

El fichero generado “.arm”, lo editamos y sacamos su contenido.

Vamos a la web de verisign y nos registramos pidiendo una prueba (Pulsar en Free SSL Trial) para firmar nuestro certificado con la CA “Test” de Verisign.

En la web se nos pedira que peguemos el contenido de nuestro request que hemos guardado en el fichero con extension .arm

A continuacion nos pedira una clave de paso que se usara para abrir dicho certificado firmado. Al final se nos enviara un correo con la informacion para descargarse los cerfificados de las CA’s de Verisign Test y el contenido de nuestro certificado firmado.

Debemos descargarnos (copiar y pegar) el contenido de los certificados de las CA’s de Verisign Test que son dos: Una CA raiz y otra intermedia. Al final del arbol de estas dos CA’s estara nuestro certificado:

• Test Root CA Certificate.cer
• Trial SSL Intermediate CA certificate.cer
• linux.dominio.com.cer

Este ultimo fichero lo creamos vacio y copiamos el contenido de nuestro certificado firmado que ha sido enviado por correo. Si lo ejecutamos podemos ver el arbol de las entidades emisoras (las CA’s de Verisign Test).

Los tres ficheros los debemos de importar desde la herramienta de Ikeyman, subiendolos primero al servidor. En la pestaña desplegable de Signer Certificates importamos los dos certificados, pimero el raiz y luego el intermedio. En la pestaña de Personal Certificates importamos el cerfificado linux.dominio.com.cer el cual contiene la clave publica y privada que usara nuestro servidor y sitio web.

Ahora ya podemos modificar nuestro fichero de configuracion del IHS (httpd.conf) poniendo algo así:

LoadModule  ibm_ssl_module   modules/mod_ibm_ssl.so
Listen 443

<VirtualHost linux.dominio.com:443>
ServerName  linux.dominio.com
DocumentRoot /opt/IHS6/htdocs/en_US
SSLEnable
#SSLClientAuth  required
</VirtualHost>

SSLDisable
Keyfile /opt/IHS6/bin/key.kdb
SSLStashFile /opt/IHS6/bin/key.sth

y ejecutamos tal cual para arrancar:

/opt/IHS6/bin/apachectl -k start -f /opt/IHS6/conf/httpd.conf

Comprobamos con ps y netstat que esta corriendo el apache de IHS.

Hecho esto debemos de instalarnos los certificados root e intermedio de la CA Test en el navegador. Y finalmente accedemos al sitio web:

http://linux.dominio.com

donde nos pedira (si es la primera vez) que instalemos el certificado de servidor:

Si queremos permitir el acceso unicamente a los usuarios que dispongan de un certificado valido de autenticacion de cliente debemos de modificar un par de cosas:

Primero en el fichero de configuracion debemos de descomentar la linea:

SSLClientAuth  required

y despues exportar la clave del certificado personal desde Ikeyman. la exportamos como PKCS12:

Este certificado es el que debemos de instalar en nuestro navegador para que cuando accedamos al sitio web nos lo pida. Este certificado contendra la clave publica y privada que autentica con la del servidor.

Se pueden sacar estadisticas muy utiles y sobre todo de errores en una web con solo añadir el plugin a nuestro navegador.

Os pongo el enlace, lo he probado en Iexplorer y Firefox. Muy chulo.

El servidor seguro solo es accesible desde el servidor puente y queremos que asi lo sea. Si por ejemplo queremos subir un fichero al servidor seguro, tendremos que subirlo primero al servidor puente y desde ahí pasarlo. Pero si queremos hacerlo mediante un script de windows, el cual te sube unos ficheros automaticamente cada hora, pues tendremos un pequeño problema ya que tendremos que operar comandos en dos maquinas diferentes.

Una pequeña solucion (ñapa) es utilizar stunnel.

En el servidor seguro:

el cual tendra abierto el servicio/puerto ftp mediante el paquete vsftp. O para cualquier otro paquete que necesitemos utilizar con stunnel. Arrancaremos el servidor ftp.

1.- Instalar stunnel:

rpm -i stunnel-4.16-20.i586.rpm

Generamos una clave para la comunicacion entre los dos servidores:

openssl req -x509 -newkey rsa:1024 -days 365 -keyout stunnel.pem -out /etc/stunnel/stunnel.pem

2.- editamos /etc/hosts.allow ya que hemos compilado Stunnel con soporte para la libreria “libwrap”. Esto crea un servicio el cual llama al servicio que configuraremos en stunnel.conf:

sslvsftp : ALL : ALLOW

3.- Editamos stunnel.conf, el cual usa el certificado stunnel.pem y el servicio sslvsftp, el cual a su vez acepta conexiones y paquetes de datos desde el puerto 273 (puerto libre en el servidor) y reenvia paquetes descifrados a ftp por el puerto 21. Esto es como una redireccion de firewall, pero actuando como cifrador y descifrador de paquetes:

pid = /etc/stunnel/stunnel.pid

cert = /etc/stunnel/stunnel.pem
client = no
[sslvsftp]
accept = 273
connect = 21

4.- ejecutamos stunnel y nos pide la palabra de paso definida en el certificado stunnel.pem:

firewall:/etc/stunnel # stunnel -start
Enter PEM pass phrase: xxxxxxxxxxxx

En el servidor puente:

1.- Instalar stunnel. Copiamos la clave stunnel.pem del servidor seguro en el directorio /etc/stunnel  del servidor puente

2.- editamos /etc/hosts.allow ya que hemos compilado Stunnel con soporte para la libreria “libwrap”. Esto crea un servicio el cual llama al servicio que configuraremos en stunnel.conf:

sslvsftp : ALL : ALLOW

3.- Editamos stunnel.conf y añadimos lo siguiente (ver que no es la misma configuracion)

pid = /etc/stunnel/stunnel.pid

cert = /etc/stunnel/stunnel.pem
client = yes
[sslvsftp]
accept = 21
connect = 192.168.0.5:273

4.- ejecutamos stunnel y nos pide la palabra de paso definida en el certificado stunnel.pem:

firewall:/etc/stunnel # stunnel
Enter PEM pass phrase: xxxxxxxxxxxx

Bien, todo listo. En el servidor seguro tendremos el servidor ftp y stunnel como servidor, el cual aceptara todas las conexiones al puerto 273 que llegan por stunnel, y lo reenviara al puerto ftp. Este seria el estado de los puertos a la escuha:

tcp        0      0 0.0.0.0:273             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN

Tambien se ve la conexion stunnel desde l servidor puente al servidor seguro:

tcp        0      0 192.168.0.34:273        192.168.0.35:54696      ESTABLISHED

Ahora si desde nuestra maquina nos conectamos al ftp del servidor puente, nos renviara de forma segura al servidor seguro. Esta bien saber los riesgos que esto puede conllevar al usar ftp, pero podriamos tunelizar cualquier otro servicio y utilizar stunnel para securizarlo.

1.- Configuracion del LDAP de Windows 2003 Server

Disponemos de un servidor Windows 2003 server instalado por defecto con el DNS y Active Directory. Este es el estado actual del servidor:

Comprobamos cual es el puerto del LDAP (por defecto 389) y que esta escuchando:

2.- Instalacion de Apache

Hemos descargado el ultimo apache hasta donde yo escribí esto en su momento: httpd-2.2.8.tar.gz

tar -xvzf httpd-2.2.8.tar.gz
cd httpd-2.2.8/
./configure –prefix=/usr/local/apache2 –enable-module=so –enable-ldap –enable-authnz-ldap

Donde activamos los dos modulos que vamos a utilizar ldap y authnz-ldap. Compilamos e instalamos:

make
make install

3.- Configuracion de Apache

Vamos a /usr/local/apache2/conf/ y editamos httpd.conf

Por defecto apache apunta al directorio /usr/local/apache2/htdocs/ donde hay un index y donde podemos cargar las paginas de nustro servidor web. Para direcrenciarlo me he creado un directorio /usr/local/apache2/htdocs2/ donde he introducido el index.html modificado:

<html><body><h1>Funciona el LDAP</h1></body></html>

Fichero que coge por defecto en:

<IfModule dir_module>
DirectoryIndex index.html
</IfModule>

Al final del archivo httpd.conf me he creado un directorio virtual, que al estar en el mismo puerto por defecto de apache 80, sobreescribe la configuracion del mismo y nos apuntara al directorio donde he incluido mi index.html. Los cambios introducidos al final del fichero httpd.conf son los siguientes:

NameVirtualHost *:80

<VirtualHost *:80>
ServerAdmin ismael@dominio.local
DocumentRoot “/usr/local/apache2/htdocs2/”
ServerName web-ldap.dominio.local
ErrorLog “logs/ldap-error_log”
CustomLog “logs/ldap-access_log” common
<Directory “/usr/local/apache2/htdocs2″>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
AuthType Basic
AuthBasicProvider ldap
AuthName “Autenticacion LDAP”
AuthLDAPURL “ldap://192.168.0.2:389/CN=Users,DC=dominio,DC=local?sAMAccountName?sub?(objectClass=*)”
#AuthLDAPURL “ldap://192.168.0.2:389/CN=Users,DC=dominio,DC=local?sAMAccountName?sub?”
#AuthLDAPURL “ldap://192.168.0.2:389/CN=Users,DC=dominio,DC=local?sAMAccountName?”
AuthLDAPBindDN “CN=Administrador,CN=Users,DC=dominio,DC=local”
AuthLDAPBindPassword “**Password de Administrador**”
AuthzLDAPAuthoritative on
Require valid-user
</Directory>
</VirtualHost>

Arrancamos el apache:

/usr/local/apache2/bin/apachectl start

y accedemos ala URL http://192.168.0.18 o http://web-ldap.dominio.local

Nos pedira un usuario que este dentro de la unidad organizativa Users.
4.- Errores comunes y pruebas

Si metemos mal la URL nos saldra un error como el que sigue:

suse:/usr/local/apache2/logs # tail -f ldap-error_log
[Sun Jun 01 13:18:04 2008] [warn] [client 192.168.0.11] [14765] auth_ldap authenticate: user administrador authentication failed; URI / [ldap_search_ext_s() for user failed][No such object]
[Sun Jun 01 13:18:04 2008] [error] [client 192.168.0.11] user administrador not found: /

Esto nos puede pasar en varias cosas:

• Mal puesto el dominio. En mi caso dominio.local fallaria si pongo “…DC=domain,DC=local…”
• Mal puesto el nombre “OU”,”CN”,”Dc” : En mi caso y por defecto de haber hecho una instalacion de windows 2003 hay que poner CN para la unidad organizativa y no OU. Como vemos en la imagen del Active Directoru hay una unidad organizativa llamada “usuarios”. Si quisiesemos usarla si que deberiamos de poner OU.
• Mal puesto el filtro del LDAP. Me ha funcionado tambien con:

AuthLDAPURL “ldap://192.168.0.2:389/CN=Users,DC=dominio,DC=local?sAMAccountName?”
AuthLDAPURL “ldap://192.168.0.2:389/CN=Users,DC=dominio,DC=local?sAMAccountName?sub?”
AuthLDAPURL “ldap://192.168.0.2:389/CN=Users,DC=dominio,DC=local?sAMAccountName?sub?(objectClass=*)”

esto es configuracion basica de LDAP.

Un servidor por defecto de Windows 2003 viene el ldap configurado para que nos pida credenciales de autenticacion en el ldap del dominio. Si quitasemos las directivas AuthLDAPBindDN y AuthLDAPBindPassword no funcionaria y nos saldria el siguiente error en el navegador:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@dummy-host2.example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.

y el log:

suse:/usr/local/apache2/logs # tail -f ldap-error_log
[Sun Jun 01 13:14:39 2008] [warn] [client 192.168.0.11] [14684] auth_ldap authenticate: user administrador authentication failed; URI / [ldap_search_ext_s() for user failed][Operations error]

Si metemos mal el usuario nos saldra un log como este, en el que ya no nos dice que el usuario administrador no se encuentra:

suse:/usr/local/apache2/logs # tail -f ldap-error_log
[Sun Jun 01 13:10:58 2008] [warn] [client 192.168.0.11] [14612] auth_ldap authenticate: user administrador authentication failed; URI / [ldap_simple_bind_s() to check user credentials failed][Invalid credentials]
[Sun Jun 01 13:10:58 2008] [error] [client 192.168.0.11] user administrador: authentication failure for “/”: Password Mismatch

Eso es todo, es bueno instalarlo uno mismo y ver como funciona sobre todo provoccando errores y mirando el log.

Instalacion en windows:

Nos descargamos el .exe y lo ejecutamos. Se nos quedara instalado en D:\Archivos de programa\Cherokee

Ejecutamos el fichero: D:\Archivos de programa\Cherokee\cherokee.bat el cual llama al ejecutable (.exe) con el fichero de propiedades:

@echo off
cd “D:\Archivos de programa\Cherokee”
start “Cherokee” /min .\cherokee.exe -C “D:\Archivos de programa\Cherokee\cherokee.conf”

El fichero de propiedades es como sigue. Puerto por defecto le podemos poner el que queramos, viendo el fichero de configuracion enseguida intuimos que es muy sencillo de manejar:

Port 8081
DocumentRoot “D:\Archivos de programa\Cherokee\www\”

DirectoryIndex index.html

Directory / {
Handler common
}
Directory /images {
Handler file
}
Extension php {
Handler phpcgi {
Interpreter C:\PHP\php-cgi.exe
}
}

En Linux:

Podemos descargar el tar.gz y compilarlo: wget http://www.cherokee-project.com/download/x.y/x.y.z/cherokee-x.y.z.tar.gz

Nos descargamos un rpm:cherokee-0.6.0b700-14.3.i586.rpm

Instalamos y se nos crea el dicectorio /etc/cherokee donde estan los archivos de configuracion. Si vemos el paquete de linux es mas completo:

rpm -ivh cherokee-0.6.0b700-14.3.i586.rpm

web:/etc # cd cherokee/
web:/etc/cherokee # ls
cherokee.conf              mime.types      sites-available
cherokee.conf.perf_sample  mods-available  sites-enabled
mime.compression.types     mods-enabled    ssl

Nos crea un ejecutable en /usr/sbin y en /etc/init.d

Lo lanzamos con el comando:

cherokee-admin
Cherokee Web Server 0.6.0 (Jun 12 2007): Listening on port 9090, TLS disabled
IPv6 disabled, using epoll, 1024 fds limit, 5 threads, 204 fds in each
standard scheduling policy

Tambien vemos que dispone de mas comandos y funcionalidades que en windows.

Descargamos boa:

wget http://www.boa.org/boa-0.94.13.tar.gz
tar -xvzf boa-0.94.13.tar.gz

ordenamos, configuramos y compilamos:

mv boa-0.94.13 /etc/boa
cd /etc/boa/src/

./configure

make

Si nos da un error editamos src/compat.h y cambiamos la linea:

#define TIMEZONE_OFFSET(foo) foo##->tm_gmtoff

por esta otra:

#define TIMEZONE_OFFSET(foo) foo->tm_gmtoff

El error conocido es:

Problems you may meet during installation
Bug [ 927446 ] boa-0.94.13 build fails with gcc 3.3.1
Symptom:
Running configure results in an error: util.c:100:40: pasting “t” and “->” does not give a valid preprocessing token
Resolution:
The problem comes from line 120 in src/compat.h: #define TIMEZONE_OFFSET(foo) foo##->tm_gmtoff Changing line 120 into : #define TIMEZONE_OFFSET(foo) foo->tm_gmtoff resolves the problem.

Que mal rollo teniendo que estar con errores conocidos desde el principio. Editamos boa.conf y modificamos los parametros a nuestro antojo:

Port 8081
ErrorLog /your/path/to/public-html/logs/error_log
AccessLog /your/path/to/public-html/logs/access_log
DocumentRoot /your/path/to/public-html/htdocs
ScriptAlias /cgi-bin/ /your/path/to/public-html/cgi-bin/

apuntando por ejemplo al apache que ya tenemos montado:

Port 8081
User nobody
Group nogroup
ErrorLog /var/log/boa/error_log
AccessLog /var/log/boa/access_log
DocumentRoot /srv/www/htdocs
ScriptAlias /cgi-bin/ /srv/www/cgi-bin/

Ordenamos boa (por ejemplo):

mkdir /etc/boa
mv /src/boa /etc/boa -> (el ejecutable)
mv boa.conf /etc/boa

Arrancamos boa

cd /etc/boa

./boa -c /etc/boa/ (path apuntando donde esta erl fichero de configuracion).

Finalmente accedemos a http://192.168.0.18:8081

Tenemos un servidor web sencillo pero limitado

Con Apachetop, es necesario descargarse los binarios y tener instalado y configurado las librerías de “ncurses”, “readline”, el procesador de macros “m4″ yun compilador. Una vez extraído el fichero configuramos la instalacion:

./configure –with-logfile=/var/log/httpd/access_log

El parametro “with-logfile” sirve para que coja un fichero de logs por defecto.

Compilamos:

make

y ya dispondremos del binario en la ruta src/apachetop. Las opciones de configuracion son mas extensibles, solo hay que buscar la ayuda de Apachetop.

La forma más sencilla de ejecutar nuestro monitor de mensajes es la siguiente:

apachetop -f  [fichero de mensajes access.log]

si hemos compilado el programa con la opción with-logfile, el parámetro f no es necesario. La ejecuccion del comando convertirá nuestra consola en algo similar a esto:

apachetop -f /usr/local/apache/logs/access_log

Como podemos observar, la similitud con el comando top es más que evidente. Las cinco primeras líneas presentan información interesante relativa a los procesos en curso.

last hit: 17:33:26         atop runtime:  0 days, 00:03:34             17:33:38
All:            4 reqs (   0.0/sec)       3598.0B (   24.0B/sec)     899.5B/req
2xx:       2 (50.0%) 3xx:       2 (50.0%) 4xx:     0 ( 0.0%) 5xx:     0 ( 0.0%)
R ( 30s):       2 reqs (   0.1/sec)       1799.0B (   60.0B/sec)     899.5B/req
2xx:       1 (50.0%) 3xx:       1 (50.0%) 4xx:     0 ( 0.0%) 5xx:     0 ( 0.0%)

La primera línea contienen la hora del último acceso, el tiempo de ejecución del comando y la hora actual.

last hit: 17:31:08         atop runtime:  0 days, 00:02:29             17:32:33

Las cuatro líneas siguientes presentan la información por pares:

En la segunda y tercera linea se contemplan los datos almacenados desde la ejecución del comando y en la curarta y quita se presenta la información actual en tiempo real, permaneciendo allí los datos durante un tiempo por defecto que se puede parametrizar.

Atendiendo al primer par, la segunda línea, de izquierda a derecha, contiene el total de solicitudes que el programa ha procesado desde su ejecución, el número de peticiones por segundo, el total de datos transferidos, el volúmen de transferencia de esos datos por segundo y, por último, una media de cantidad de datos por solicitud.

All:            4 reqs (   0.0/sec)       3598.0B (   24.0B/sec)     899.5B/req

La tercera línea presenta la información de respuesta del servidor por código y se divide en la cantidad de respuestas y, entre paréntesis, su porcentaje con respecto al total.

2xx:       2 (50.0%) 3xx:       2 (50.0%) 4xx:     0 ( 0.0%) 5xx:     0 ( 0.0%)

La cuarta y quienta línea muestran información idéntica al primer par, pero sólo se visualizará la media de los datos que se han leído desde el parámetro especificado durante la ejecución del programa. Por defecto, ese parámetro se establece en un valor treinta segundos. Mediante los parámetros H (hits) y T (time) podremos cambiar ese valor a nuestro antojo, lo cual reflejará distintos estados en el último par de líneas descrito.