Diseño centrado en el usuario
Me encuentro con semejante atrocidad en el periódico “El Día” después de recibir un aviso via e-mail de una amiga: http://www.eldia.es/2007-08-02/criterios/criterios3.htm
(dado que me huelo que pueden borrar o modificar el original en un ataque de cobardía aqui estará para la eternidad - o casi - la página para descargar: Página Web Completa)
En respuesta les he enviado el siguiente correo a la dirección eldia@eldia.es
Hola,
dado que no sé a quien dirigirme, puesto que el que tuvo la “gran” desfachatez de escribir semejante artículo ( http://www.eldia.es/2007-08-02/criterios/criterios3.htm ) no tuvo al menos el valor de firmarlo con su nombre y apellidos, le escribo en general a la redacción del periódico “El Día”.
Me parece casi cómico el hecho de llamar “Gran Canaria” simplemente “Canaria”. Gran Canaria, se llama Gran Canaria. Eso es así y no hay más. Parece que el autor tiene algún problema de complejo de inferioridad o similar, viendo el presente artículo. Personalmente no tengo nada contra “Santa Cruz de Tenerife” teniendo en cuenta que no soy católico. Y podrán decir ¿y eso que tendrá que ver (lo de ser católico, por si hay alguno espeso de mente)? Pues bien, eso mismo me preguntaba yo leyendo su artículo. Que no tiene ni pies ni cabeza.
“Don Paulino, además de por el fuego, Tenerife está que arde y no es bueno que la isla mayor y más importante del Archipiélago esté sufriendo vejaciones sin cuento. No se sume usted a los partidos estatalistas, que todos tiran para la tercera isla. Sea usted un verdadero nacionalista de las siete islas y si tiene que elegir alguna no olvide lo que ya le hemos dicho, la primera y principal es Tenerife.”
Me parece realmente mentira que alguien tenga la grandísima carota, de quejarse del NOMBRE (porque no es otra cosa) de una isla, y luego tenga la poca vergüenza de llamar a lo que supongo será su propia isla “la isla mayor y más importante”, “la primera y principal”. ¿En qué quedamos? ¿Igualdad o no?
Realmente no espero ninguna respuesta, porque alguien que escribe algo así y un periódico que hospeda tales artículos, no es que coseche demasiada credibilidad.
Un pequeño matiz respecto a mi post anterior…
___________________________________________________
One small but important update:
Redirect permanent /gallery2 http://www.kondado.com/gallery
Redirect permanent / http://www.kondado.com/gallery/
Notice the trailing slash in the second line. It has to be there or else you’ll have problems when accesing single documents on that URL. Don’t ask me why.
It doesn’t seem to be needed when redirecting from a directory. To be precise you shouldn’t put that slash after the 1st line. Or else you’ll get double slashes after redirecting. Weird thing.
___________________________________________________
PD: En cuanto pueda traduciré este artículo al español.
Well here it is!
Short version: You only need
- One directory where Gallery2 is installed (in my case /var/www/htdocs/gallery)
- One directory where you will put a .htaccess file to redirect to the correct directory (in my case /var/www/htdocs/gallery2/.htaccess)
The access file could look something similar to:
Redirect permanent /gallery2 http://www.kondado.com/gallery
Redirect permanent / http://www.kondado.com/gallery
This will redirects requests like…
http://www.kondado.com/gallery2/
http://www.kondado.com/gallery2/main.php
http://gallery.kondado.com
… to …
http://www.kondado.com/gallery/
And the very best thing is: you will be able to use URL rewrite!!
Gallery will use /gallery/ (which is the “real” folder) as root for URL rewriting — you can check it if if you want to by looking directly into the file. It’s near the start of the file.
The only extra tweaks you need to make something like this work are done in the /var/www/conf/httpd.conf file (or wherever it’s placed on your server).
This are just examples, you will have to read the documentation for more precise instructions!
NameVirtualHost *:80<VirtualHost *:80>
DocumentRoot /htdocs
ServerName kondado.com
</VirtualHost><VirtualHost *:80>
DocumentRoot /htdocs
ServerName www.kondado.com
</VirtualHost><VirtualHost *:80>
DocumentRoot /htdocs/gallery2
ServerName gallery.kondado.com
</VirtualHost>
The following is to allow the .htaccess file in the “redirection folder” (/var/www/htdocs/gallery2/) to become active. You may not need this depending on how secure or unsecure your security policies on your server are set. In OpenBSD it should be needed by default, since it nearly doesn’t allow any “Overrides” of the apache server — which in fact is a good thing since it improves security.
<Directory “/var/www/htdocs/gallery2″>
AllowOverride FileInfo
</Directory>
If you should need a better Redirection style — i.e. that the URL shouldn’t change after a redirection, you will have to read through the mod_rewrite possibilities. Like if you don’t want the URL in the users browser change from gallery.example.com to www.example.com/gallery … This would require a bit more work in the .htaccess file — although not too much I think.
Since it doesn’t really matter to me at this time I’ll leave it as it is for now.
__________
Also don’t forget to change the following anytime you change the directory name of your gallery!! I was quite annoyed first by this, since gallery didn’t recognize that mod_rewrite was active, while checking it through its interface (admin). The cause was I had changed the dir. name and didn’t update this.
<Directory /htdocs/GALLERY_DIR_NAME>
AllowOverride Options FileInfo
</Directory>
PD: En cuanto pueda traduciré este artículo al español.
Esto es un pequeño añadido al post anterior sobre awstats. Viendo que el mío estaba contando las visitas, el tráfico y todo lo demás de mi red interna y además juntándolo con las estadísticas de las conexiones del exterior decidí cambiar esto.
Para ello he separado los logs en tres, como sigue
# The following enviroment variables establish to not log
# local requests.
#
# Mark requests from the loop-back interface
SetEnvIf Remote_Addr “127\.0\.0\.1″ dontlog
# Mark requests from the local network
SetEnvIf Remote_Addr “192\.168\.0\.” dontlog#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a <VirtualHost>
# container, they will be logged here. Contrariwise, if you *do*
# define per-<VirtualHost> access logfiles, transactions will be
# logged therein and *not* in this file.
#
CustomLog logs/access_log combined env=!dontlog
CustomLog logs/intranet_log combined env=dontlog
CustomLog logs/complete_log combined
Primero establezco variables de entorno que marcan las direcciones de interés (127.0.0.1 y 192.168.0.*) con la variable “dontlog”. Ya con eso puedo separar qué es lo que quiero log-ear. Con lo que tengo un log (access_log) que contiene el tráfico SÓLO de fuera, un intranet_log que hace lo propio con el de dentro y uno con el tráfico de dentro y de fuera — complete_log.
Esto da un gran juego, ya que además si queremos podemos crear más variables y más logs, y filtrarlos con distintas configuraciones para el awstats. Podríamos tener las estadísticas del interior y del exterior por separado, por poner un ejemplo básico. A mi personalmente las de dentro apenas me interesan, pero en una empresa podría resultar interesante. ![]()

Antes que nada avisar que este micro-HowTo es sólo para OpenBSD. ¿Porqué? Pues porque OpenBSD tiene por defecto al Apache metido entre rejas. Con esto me refiero al servidor de HTTP/WWW, por si había dudas
El apache httpd de OpenBSD (concretamente hablamos de la 3.6 a la 4.1 que son las que he usado si no recuerdo mal, aunque en el resto probablemente sea muy parecido) está en un ‘chroot’ (change root) para que en caso de ser ‘exploit’eado los daños al resto del sistema sean lo menor posible — aunque esto tampoco garantiza una seguridad 100%, pero cuantas más capas de seguridad molesten a los atacantes mejor.
La desventaja intrínseca de esto es que todo lo que lance el propio servidor, que suele funcionar bajo el usuario ‘www’, tendrá como su raíz (root) al directorio que se le haya asignado previamente — normalmente suele ser /var/www/. Por tanto tendremos que copiar todos los binarios y las librerías de los que dependen estos al chroot. Según las dependencias esto puede ser algo relativamente complicado (como ejecutar amavisd-new en ese mismo chroot). Sin embargo estamos de suerte y para que funcione awstats bajo el chroot sólo hará falta instalar los binarios de perl.
Normalmente perl ya viene con la instalación por defecto de OpenBSD en las recientes versiones. En caso de que no esté … pues no sé, tocará pelearse con CPAN o algo por el estilo. No es normal que no esté en el sistema, como se puede observar en esta página.
Teniendo perl en el sistema bastará con copiar sus binarios tal cual están en su estructura de directorios y hacer lo propio con sus librerías correspondientes. Hay que tener siempre en mente que para el httpd el directorio /var/www es su raíz, por tanto lo ve como el directorio / de la jerarquía — ahi acaba su mundo.
Copiamos pues los binarios:
# cp /usr/bin/perl /var/www/usr/bin/
# cp /usr/bin/perl5.* /var/www/usr/bin/
Ahora tocar copias las librerías:
# cp -R /usr/local/libdata/perl5 /var/www/usr/local/libdata/
# cp -R /usr/libdata/perl5 /var/www/usr/libdata/
# for i in /var/www/usr/bin/*; do ldd $i; done | grep ‘lib’ | cut –c 41-80 | sort -n | uniq > /tmp/libs
# for i in `cat /tmp/libs`; do cp $i /var/www$i; done
Lo que hacen las 2 últimas lineas tan crípticas es simplemente editar la salida de un “ldd” sobre cada uno de los archivos de binarios para luego poder copiarlos en el directorio correspondiente bajo /var/www. Esto equivale a hacer un “ldd” (list dynamic object dependencies) sobre cada uno de los binarios de perl, mirar la lista que devuelve sobre sus dependencias de librerías dinámicas y copiar cada una de esas librerías a mano.
Teniendo perl funcionando en el chroot ya deberíamos ser capaces de ejecutar un CGI (no es otra cosa que un programa ejecutable que lo arranca el httpd y luego muestra su salida (STDOUT) en una página web o en texto). Para esto como mucho debería hacer falta activar la directiva ScriptAlias en el /var/www/conf/httpd.conf.
ScriptAlias /cgi-bin/ “/var/www/cgi-bin/”
Aparte habría que hacer un pequeño programa en perl (o copiarlo de cualquier web), darle permisos de ejecución (chmod u+x /var/www/cgi-bin/programa.pl) y ya podríamos lanzarlo desde http://www.tudominio.com/cgi-bin/programa.pl
Si ya sabemos que nos funciona perl desde el servidor sólo queda “instalar” — entre comillas porque básicamente sólo es copiar de un sitio a otro — los archivos de AWStats. Para ello basta con ir a esta pagina y descargar el último .tar.gz estable (o no) que haya. Lo más simple es descargarlo directamente a nuestro servidor con (pkg_add) wget o algo por el estilo y descomprimirlo en /var/www/awstats.
De lo que se descomprime sólo nos interesa en realidad el directorio /var/www/awstats/cgi-bin los otros (doc, tools, etc.) los podemos borrar o mejor copiar a otro sitio.
Ahora tendremos que copiar el archivo awstats.model.conf a uno que se llame awstats.MIDOMINIO.conf (para este sitio sería awstats.kondado.conf), aunque lo podemos llamar como nos dé la gana en realidad. Esta configuración es para un solo dominio. Para configuraciones multidominio y otras deberán mirar la documentación.
Las variables más importantes dentro del awstats.dominio.conf que se deben tocar son las que están bajo el apartado “MAIN SETUP SECTION (Required to make AWStats work)”. Las instrucciones que están en el mismo archivo deberían ser suficients para saber como configurarlo a nuestro gusto. Lo más importante es indicar la directiva LogFile. Dado que estamos en el directorio /var/www/awstats/cgi-bin/ y nuestro archivo de configuración está en ese mismo directorio, la directiva deberá ser
LogFile=”../../logs/access_log”
Por último habrá que añadir las siguientes lineas al archivo /var/www/conf/httpd.conf
#
# Directives to add to your Apache conf file to allow use of AWStats as a CGI.
# Note that path “/usr/local/awstats/” must reflect your AWStats Installation pa
th.
#
Alias /awstatsclasses “/var/www/awstats/classes/”
Alias /awstatscss “/var/www/awstats/css/”
Alias /awstatsicons “/var/www/awstats/icon/”
ScriptAlias /awstats/ “/var/www/awstats/cgi-bin/”
#
# This is to permit URL access to scripts/files in AWStats directory.
#
<Directory “/var/www/awstats”>
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Además hay que buscar la linea de access_log y dejarla como sigue para que awstats disponga de un log combinado que contiene muchas más informaciones útiles que el estándar:
CustomLog logs/access_log combined
Antes de que se me olvide, la directiva DirIcons deberá ser
DirIcons=”/awstatsicons”
para que encuentre correctamente los iconos al generar la página de estadísticas.
Si queremos permitir la acutalización manual desde la misma página web deberemos activar la opción
AllowToUpdateStatsFromBrowser=1
Finalmente bastará con actualizar la base de datos (en realidad es simplemente otro tipo de archivo log que pueda manejar mejor). Esto se puede hacer a mano “awstats.pl -config=kondado -update” o desde la dirección http://www.tudominio.com/awstats/awstats.pl?config=kondado&update=1. Recomiendo hacerlo desde la página web teniendo la opción de actualización activada, ya que de forma manual me ha parecido que puede dar problemas. En todo caso al hacerlo a mano es mejor lanzar el comando desde el propio directorio de awstats.pl — por si las moscas.
Espero que no falte nada. Y si falta, haganmelo saber. Saludos.
PD: Para realizar la actualización de forma manual bastará realizar lo siguiente
# chroot /var/www /awstats/cgi-bin/awstats.pl -update -config=kondado
Esto le hará creer al awstats.pl que se está ejecutando como desde el apache, es decir en su chroot. Así funcionará correctamente.
Esto es un pequeño relato que escribí en su momento. Se titula “Semana Santa - Santa Paciencia” y trata de porqué es mejor quedarse en casa en Semana Santa — o algo así.
La historia es completamente real y no hay nada inventado, así que si están aburridos ahi tienen algo para leer.
semana-santa-santa-paciencia.pdf
Hay problemas con este post — intentaré corregirlo en breve.
______________________________________________________________________
Algo tan básico como conectar dos ordenadores a Internet através de bluetooth puede resultar relativamente complejo si los manuales existentes son pésimos o bien no muestran un ejemplo concreto.
Lo que quería era conectar mi portatil con bluetooth al bluetooth de mi ordenador “normal” (torre) y através de este conectar el portatil a internet. Después de probar distintas conexiones y acabar mareado con tanta sigla — DUN, PAN, LAN, LAP — conseguí el milagro que al final resultó ser lo más tonto del mundo.
Lo primero es activar en el ordenador “pasarela” (el que tiene bluetooth y conexión a la LAN (red interna) y por tanto también a internet - en mi caso el ordenador “normal”) el servicio de PAN (Private o Personal Area Network). Para eso nos vamos a la ‘Ventana de Servicio’.
Ahi hacemos click derecho sobre el icono de ‘Personal Area Network’ y pulsamos en ‘Propiedades…’. Veremos esta ventana
Ahi bastará con elegir el adaptador de red que tenga conexión a la red interna/internet. En mi caso es la integrada a mi placa base nvidia/nforce. Este paso obviamente desactiva el DHCP y lo demás de PAN de bluetooth.
Ahora bastará con elegir en el o los ordenadores ‘cliente’ — en mi caso el portatil — al ordenador que vamos a usar de pasarela, pinchar en su icono
y luego en el icono de PAN
Puede ocurrir que tengamos activado el servicio de PAN en el ordenador cliente, por lo que saldrá una ventana preguntandonos en un español más que pésimo (¿o puede que fuera hindú?) si queremos desactivar el PAN en el cliente para poder conectarnos al del otro ordenador. En tal caso responderemos que sí.
El paso definitivo es permitirle la conexión en el ordenador que hará de pasarela (no es exactamente esta la ventana, pero es muy parecida)
Puede sonar todo relativamente complejo aunque se puede hacer en 3 minutos.
PD: Algunas fotos pueden no verse 100% correctas en las páginas en las que se muestran. Esto es cosa del WordPress. Para ver la imágen original simplemente vuelvan a hacer clic en ella una vez la estén viendo en su página aparte.
PPD: Me acabo de dar cuenta, que al parecer BlueSoleil requiere en ambos ordenadores tener permisos de Administrador — lo cual en mi humilde opinión es extremadamente cutre, pero es lo que hay por ahora.
Primer y por ahora único post que escribo directamente desde el móvil. A ver si llega el día en el que yoigo tenga cobertura decente en toda la isla de gran canaria. Por ahora sólo hay cobertura de banda “semi-ancha” en la capital. En el resto hay cobertura de unos 64 k y sólo al aire libre, es decir si no estás en un recinto cerrado. Bueno esto es todo por ahora, que con el móvil uno se deja los dedos… Quién pudiera permitirse un teclado de estos que funcionan con el móvil por bluetooth…
Bienvenid@s al Blog de Kondado.
Por ahora no tengo nada interesante que pueda publicar, ya tocará …
Mientras tanto pueden disfrutar de la galería de Fotos >> Blogroll >> Galeria.