WAMP: Problemas de acceso a PHPMyAdmin

Algunos usuarios reportan un error de permisos al intentar acceder a PHPMyAdmin. Generalmente se debe a que el programa viene configurado para autologin pero no permite contraseñas en blanco.

Para corregirlo vamos a necesitar dos cambios:

• Establecer una clave en MySQL si no existe (no estrictamente necesario pero muy recomendable).
• Configurar PHPMyAdmin para que solicite usuario y clave al entrar.

Ambas acciones aumentan considerablemente la seguridad de nuestro sistema.

Establecer la clave del usuario root en MySQL

Accederemos a la base de datos MySQL ejecutando mysql (en Windows y Linux) desde un path accesible. Si nos aparece el siguiente error:

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
significa que el usuario root ya tiene clave. Si por el contrario nos permite acceder hasta la cocina es que tenemos ese usuario sin clave y debemos establecerla:

Estableceremos la clave de root con el siguiente comando:

 

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('MiNuevaContraseña');

 

 

Configurar PHPMyAdmin para que solicite las credenciales de acceso

Debemos configurar el fichero config.inc.php situado en el directorio raíz de PHPMyAdmin. Es posible que este archivo no exista y tengamos que crearlo a partir del archivo de ejemplo config.sample.inc.php.

 

Añadiremos la siguiente línea:

 

$cfg['Servers'][$i]['AllowNoPassword'] = false;

 

De este modo PHPMyAdmin nos solicitará las credenciales de acceso cada vez que queramos iniciar sesión.

PHPPgAdmin: administrador web de PostgreSQL

Continuando con la serie de tutoriales de PostgreSQL vamos a dedicar un post a PHPPgAdmin.

PHPPgAdmin es una herramienta web para la administración de bases de datos PostgreSQL (del mismo modo que PHPMyAdmin lo es para MySQL). Está compuesto por una serie de scripts PHP que serán ejecutados por un servidor web y estarán accesibles desde un navegador.

Requisitos previos

Necesitamos un servidor con las siguientes características instaladas:

• Base de datos PostgreSQL 8.4 o superior (las versiones inferiores quedan fuera del soporte y desarrollo futuro, puede funcionar bajo nuestra responsabilidad)
• Servidor web con soporte a PHP5.0 o superior

Proceso de instalación

• Descargaremos los archivos fuentes de la página del desarrollador: http://phppgadmin.sourceforge.net/doku.php?id=download
• Descomprimimos los fuentes en un directorio accesible del servidor web

Si trabajáis con un sistema operativo linux lo tenéis disponible en los repositorios de software.

Configuración

Existen dos archivos de configuración que debemos modificar: config.inc.php (configuración propia de PHPPgAdmin) y  apache.conf (con la configuración de los permisos de acceso al directorio que aloja los scripts php)

En el fichero config.inc.php configuramos las siguientes líneas con la dirección de nuestro servidor (generalmente localhost) y el puerto de conexión (por defecto el 5432)

$conf['servers'][0]['host'] = 'localhost';
$conf['servers'][0]['port'] = 5432;

Si queremos acceder con el usuario root a PHPPgAdmin (no recomendado) debemos desactivar la directiva extra_login_security en la línea:

$conf['extra_login_security'] = false;

Guardamos el fichero y abrimos apache.conf. Para permitir el acceso desde cualquier IP tendremos que habilitar la directiva allow from all. Si queremos que esté activa sólo desde una subred podemos indicarlo.

<Directory /usr/share/phppgadmin/>

DirectoryIndex index.php

Options +FollowSymLinks
AllowOverride None

order deny,allow
deny from all
#allow from 127.0.0.0/255.0.0.0 ::1/128
allow from all

<IfModule mod_php5.c>
  php_flag magic_quotes_gpc Off
  php_flag track_vars On
  php_value include_path .
</IfModule>

</Directory>

Reiniciamos Apache y ya tendremos accesible PHPPgAdmin desde nuestro navegador:

[Editado 18/09/2014]

En la versión 9.3 de PostgreSQL el archivo de configuración se encuentra en /etc/apache2/conf.d/phppgadmin

Igual que en el caso anterior comentaremos las líneas que impiden todos los accesos excepto el local:

#deny for all
#allow from 127.0.0.0/255.0.0.0  ::1/128

Y añadimos la línea

allow from all

que permite el acceso desde cualquier dirección I.P. (dejando la seguridad a cargo de la autenticación de Postgre). Es recomendable revisar el log de accesos de vez en cuando para averiguar si tenemos intentos de acceso no autorizados y en ese caso podemos restringir el rango de IPs permitidas.

PostgreSQL: habilitar conexión remota

Si habéis trabajado con un servidor PostgreSQL con frecuencia habréis usado la herramienta PgAdmin para administrarlo en un entorno gráfico más manejable. Generalmente en la instalación por defecto el servidor sólo acepta conexiones desde la máquina local (para ofrecer un servicio web no necesitamos acceder desde fuera).

En ocasiones podemos necesitar habilitar una conexión remota al servidor (para administración remota desde PgAdmin o phppgadmin, conexiones desde otro servidor web diferente, etc...). En estos casos tendremos que configurar Postgre editando el archivo pg_hba.conf.

¿Cómo habilitamos el acceso desde una IP remota?

Al final del archivo encontraremos las siguientes líneas:

# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication     postgres

Y añadiremos:

host     all     all     192.168.1.3/24     md5

Los campos que aparecen en la línea son:

• Tipo: conexión local o remota (local o host)
• Bases de datos a las que permitimos acceso
• Usuarios que pueden acceder
• Direcciones IP o subredes que accederán

Aquí indicamos que habilitamos conexiones desde un host con la IP 192.168.1.3, para todas las bases de datos (all) y todos los usuarios (all). Desde este momento podremos conectar nuestro PgAdmin instalado en la máquina con IP 192.168.1.3 al servidor Postgre.

Si queremos algo más general podemos indicar una subred: 192.168.1.0/24 permitirá el acceso desde cualquier equipo de esa subred.

Después tendremos que indicar al servidor que escuche peticiones de cualquier dirección. Para ello editaremos el archivo postgres.conf y buscamos la línea listen_addresses. Debemos cambiar el valor: addresses = '*' para indicar que escuche desde cualquier dirección.

Por último no olvidéis reiniciar el servicio de PostgreSQL antes de intentar conectar en remoto. Un saludo

Backup de bases de datos PostgreSQL en línea de comandos

Para los que utilicéis bases de datos PostgreSQL es posible que este post os resulte de utilidad. Los que no lo conozcáis os animo a que le dediquéis un tiempo: actualmente es el gestor de bases de datos orientadas a objetos libre más potente del mercado.

Existen varias formas de hacer un backup de una base de datos PostgreSQL, aunque las más usadas son:

• En entorno gráfico con PgAdmin (software gratuito distribuido junto a PostgreSQL).
• Vía web si tenemos instalado PHPPgAdmin.
• Desde línea de comandos (el caso que nos ocupa).

¿Por qué desde línea de comandos? Si administráis servidores os interesará automatizar la tarea mediante un script, de modo que no tengáis que realizar la copia manualmente cada cierto tiempo. 

En la distribución de PostgreSQL existe un ejecutable llamado pg_dump que nos permite realizar la copia de una base de datos a un archivo. La sintaxis es la siguiente:

• Backup: pg_dump -i -h localhost -p 5432 -U usuario -f archivo.sql NombreBD
• Restore: psql -p 5432 -U usuario -d NombreBD -f archivo.sql

Estas sentencias presuponen un servidor local, el puerto 5432 (que podemos cambiar a nuestra conveniencia) y el resto de parámetros que modificaremos para conectar con nuestra base de datos (usuario, archivo.sql y NombreBD). Sobra decir que el usuario que utilicemos debe tener permisos en el servidor para realizar copias de seguridad y acceder a la base de datos (recomendamos utilizar el usuario postgres).

Si ejecutamos la sentencia de backup nos aparecerá un prompt para que ingresemos manualmente la clave. Para evitarlo y automatizar la tarea hay una alternativa: eliminar el parámetro -p y establecer temporalmente el valor de la variable PGPASSWORD con la clave del usuario que queramos utilizar (no olvidéis volverla a establecer a una cadena vacía una vez lanzada la sentencia en el script):

• Linux: PGPASSWORD=miclave

PGPASSWORD=postgres 

pg_dump -U postgres -h localhost basedatos > /mnt/backup/linuxPgbasedatos.sql

PGPASSWORD=

• Windows: SET PGPASSWORD=miclave

SET PGPASSWORD=miclave

 pg_dump -i -h localhost -p 5432 -U postgres -f c:\backup\windowsPgbasedatos.sql basedatos

SET PGPASSWORD=

Luego ya sólo queda lanzar el script desde el cron (Linux) o el programador de tareas (Windows) y tendremos automatizado el backup de la base de datos.

[Actualizado 06/05/2014]

Si necesitáis transferir el fichero de backup a otro equipo vía FTP no olvidéis establecer el flujo de datos a binario (comando binary de FTP).

Convertir juegos de caracteres latin1 a UTF-8

Un problema frecuente que nos encontramos al diseñar o migrar bases de datos es la elección del juego de caracteres. Para el castellano nos encontramos con varias alternativas, destacando dos principalmente:

• Latin1 o ISO 8859-1 es una norma de la ISO (Organización Internacional para la estandarización) que comprende todos los alfabetos latinos para Europa Occidental (con tildes, caracteres especiales como "ñ" o "ç",etc...).
• UTF-8 (8-bit Unicode Transformation Format) es un formato de codificación de caracteres Unicode e ISO 10646.

 Las normas ISO utilizan distintos juegos de caracteres que superponen conjuntos de símbolos (por ejemplo, el decimal 243 que corresponde a "ó" en latin1 puede corresponder a otro símbolo en cualquier otra norma ISO).

Una de las principales ventajas de UTF es que no superponen conjuntos de símbolos: el símbolo "ó" será el mismo valor independientemente del UTF que utilicemos (8, 16...).

¿Entonces UTF-8 es mejor que Latin1?

No queremos que los adeptos a uno de los dos sistemas se líen a pedradas con nosotros, así que no entraremos en polémicas ;-). Cada sistema tiene sus ventajas e inconvenientes (UTF-8 es más universal pero, ¿vamos a trabajar con alfabetos diferentes a latin1 como para justificar el mayor tamaño de almacenamiento de los datos?).

El problema

Es posible que hayáis encontrado una base de datos en un juego de caracteres que queráis migrar al otro. Si lo hacéis directamente os quedan caracteres que no tienen correspondencia exacta con el otro (no se representan bien los caracteres especiales del castellano como las "Ñ" y las tildes).

Una solución

Hablo de "una" solución porque afortunadamente existen muchas soluciones para este problema. Esta es la que yo utilizo por su sencillez. Os voy a describir el proceso para el paso de tablas en latin1 a UTF-8, el proceso inverso es similar.

El único software que vamos utilizar (además del propio de nuestra base de datos) es un editor de texto plano capaz de guardar cambiando el juego de caracteres. Yo trabajo con una versión de evaluación de Textpad, aunque el propio Notepad de Windows o el Notepad++ también pueden hacerlo, como casi cualquier editor de texto plano.

Entrando en faena, lo que debemos hacer es:

1) Exportamos

Hacemos una exportación (o dump) de la(s) tabla(s) de la base de datos de origen en texto plano (a un archivo sql). En el ejemplo que os muestro se trata de una tabla de municipios de España exportada en latin1.

2) Editaremos ese archivo exportado:

 Como podéis ver, en la sentencia SQL de creación de la tabla se especifica el juego de caracteres en dos puntos.  Vamos a eliminar el juego de caracteres de la columna y cambiaremos el general por defecto de la tabla a UTF-8 manualmente:

 Por último pulsamos sobre guardar cómo para poder cambiar el juego de caracteres:

3) Importamos el archivo editado

Al importar a nuestra base de datos de destino tenemos que especificar que se trata de un archivo en UTF-8.

En nuestro caso utilizamos una base de datos MySQL con phpMyAdmin:

Si sois de los que preferís utilizar la línea de comandos:


mysql -u mi_usuario -p  db_destino   --default-character-set=utf8 < archivo_editado_utf8.sql


Et voilá, tendremos nuestra tabla importada con sus caracteres correctos sin artefactos en las tildes, "ñ", "ç"...