Mostrando entradas con la etiqueta MySQL. Mostrar todas las entradas
Mostrando entradas con la etiqueta MySQL. Mostrar todas las entradas

El creador de MySQL lanza MariaDB, el sustituto de MySQL

¡Así es! El creador de MySQL Michael Wideniur, anunció en su blog personal el lanzamiento de un nuevo producto, un motor de bases de datos basado en el mismo MySQL y nos invita a testearlo.
En el sitio oficial, se puede ver toda la documentación de este nuevo motor de bases de datos. Aunque hay que tener en cuenta que este aplicativo no fue desarrollado desde cero ya que como hemos mencionado está basado en MySQL.

Leer entrada completa: Programando ideas

La clase MySQLi

Hoy mismo hablé sobre el uso de mysql_connect pero ahora quiero hablaros de la clase MySQLi que un user de CUH (p3ll3) comentó sobre ella y yo no la habia tenido en mente.

Un código básico de MySQLi:

<?php
$con 
= new MySQLi('host', 'usuario', 'pass', 'db');
$query = $con->Query("SELECT algo, otro FROM tabla WHERE id = 1");

while (
$q = $query->fetch_object()) {
    echo 
"Hola soy ".$q->algo." y ". $q->otro;

}
$query->close(); $con->close();
?>


Como se puede comprobar es bastante sencillo, creamos un objeto con la sentencia new, le decimos que se trata de MySQLi y le pasamos los parámetros de conexión: host, usuario, contraseña y base de datos, aquí ya se nota una mejora por el hecho de no tener que usar mysql_select_db().

Luego para ejecutar una consulta simplemente tomamos el objeto y le indicamos la acción Query seguida de la consulta.

Para accesar a los datos lo hacemos igual que con mysql_query solo que en el while en ves de poner mysql_fetch_array() ponemos la variable y fetch_object().

A la hora de acceder a los datos normalmente lo hariamos como un array $q['algo'] pero con MySQLi se hace así $q->algo.

Eso es todo referente a MySQLi

La Función mysql_connect

No hace mucho publiqué el siguiente artículo en el foro de CUH, el cual se ve que agradó y me solicitaron un poco mas de información, así que os dejo el post completo por si es de ayuda para alguno.

Para establecer una conexión a una base de datos mysql utilizaremos myql_connect().

Esta función se suele almacenar en una variable ya que en futuras acciones debemos decirle cual es la conexion.

Sintaxis:

$variable = mysql_connect([$host],[$usuario],[$password],[$nuevolink],[$flags])

todo es muy simple... un ejemplo de variables sería:

<?php

$host
="localhost"; $usuario="root"; $password=""; //sin pass $nuevolink=true; $flags=MYSQL_CLIENT_SSL  
?>


Todos los parámetros de esta función son opcionales... y direis: COMO???, así no hay forma de saber donde conectar...

Bien, hay un detalle que parece ser que mucha gente no usa en cuanto a $host $usuario y $password...

Existe ese maravilloso PHP.ini que tiene unas directivas especialmente para esta función, y en caso de que no se pase un parámetro conectará mediante dichas directiva. Las directivas son:

mysql.default_host =
mysql.default_user =
mysql.default_password =


si les ponemos valores a estas directivas ya no hará falta especificar datos de conexión.

$nuevolink

Por defecto es false y su utilidad en true es que si hacemos otra llamada con los mismos argumentos no establecerá un nuevo link sino que utilizará el que ya se habia creado previamente, por eso no se suele usar..

$flags

Las flags de mysql_connect son:

MYSQL_CLIENT_COMPRESS
Protocolo de compressión

MYSQL_CLIENT_IGNORE_SPACE
Permitir espacios después de nombres de funciones

MYSQL_CLIENT_INTERACTIVE
Permitir los segundos interactive_timeout (en ves de wait_timeout) de inactividad antes de cerrar la conexión

MYSQL_CLIENT_SSL
Encriptación SSL

Eso es todo para mysql_connect() normalmente se usan los 3 primeros parámetros así que si no entendeis el resto no os comais mucho la cabeza

Recuperar el Password MySQL en Linux

El mismo día que comentaba como recuperar el password Root de MySQL en windows, Dragon de DragonJar nos contaba como hacerlo desde linux.

Hoy entonces paso a explicar este proceso.


Primero detenemos el servicio

$ /etc/init.d/mysql stop

una ves que el servicio está apagado reiniciamos el servidor en modo seguro:

$ mysqld_safe --skip-grant-tables --skip-networking

acto seguido abrimos otra consola y entramos como root al servidor:

$ mysql -u root -p mysql

Ahora ya deberiamos tener el acceso a mysql, el siguiente paso es cambiar la contraseña:

$ mysql> UPDATE user SET Password=PASSWORD('unapassowrdnueva') WHERE User='root';
mysql> flush privileges;

El último paso es terminar el proceso mysql-safe y reiniciar el servidor SQL:

$ pkill mysql -safe
$ /etc/init.d/mysql start


Fuente original DragonJar: Como recuperar clave mysql

Cuando el administrador se duerme

A lo largo de mi "carrera", que no es larga precisamente he tenido la oportunidad de comprobar la verdad absoluta de un administrador web, "si te duermes te joden".

Cuando un admin dice "no tengo ganas de actualizar el soft", "una contraseña robusta es dificil de recordar" y todas esas frases que a los amantes de la seguridad nos da pánico escuchar es cuando se producen los mayores errores en la securisación del servidor.


Hoy vamos a hablar de un caso en especial, resulta que anoche estaba aburrido y me dirijí a la comunidad DragonJAR donde leí un paper de Shell Root sobre controlar un servidor via XAMPP, entusiasmado con la idea y con ganas de probar lo aprendido ideé una dork en google que, impresionantemente, el tercer resultado de esta tenia los valores por defecto de XAMPP es decir:

user: root
no password

Cuando lo vi me dió verguenza ajena....

Lo mas "divertido" de la página es lo que reza en su index:

The main objective of the MOMENT project is to design and implement a mediator architecture to offer a unified interface to all data bases and measurement facilities for IP traffic monitoring and service supervision. Thus its users will be able to submit advanced queries based on semantic access, with possible combinations of different data sources, with privacy protection mechanisms.

Y bien... para finalizar dejo un par de capturas del desastre

xammp owned

Se aprecia claramente que el usuario es root


Y el desastre de desastres... una shell subida...

Espero que a partir de ahora configuren con un mínimo de seguridad sus servidores!!

La mejor forma de administrar las fechas entre PHP y MYSQL

Luego de mucho tiempo trabajando con la función date(), creando campos INT en MySQL y luego usando una función para calcular a partir de ese INT la fecha que almacena (al mas puro estilo SMF) creo haber dado con la fórmula perfecta, al menos para mi, de trabajar con este dato.

El proceso va orientado a una web con sistema de noticias, comentarios, peticiones y demás por lo que es importante tener un registro de fechas y horas.

Empezamos montando la tabla de ejemplo

mysql> DESCRIBE horas;
+-------+-----------+------+-----+-------------------+--------------------------+
| FIELD | Type      | NULL | KEY | DEFAULT           | Extra
   |
+-------+-----------+------+-----+-------------------+--------------------------+
| hora  | timestamp | NO   |     | CURRENT_TIMESTAMP | ON UPDATE CURRENT_TIMESTA
MP |
+-------+-----------+------+-----+-------------------+--------------------------+
 
mysql> SELECT * FROM horas;
+---------------------+
| hora                |
+---------------------+
| 2010-01-28 15:38:26 |
| 2010-01-28 15:38:49 |
| 2010-01-28 15:38:54 |
+---------------------+
3 rows IN SET (0.00 sec)
 
Se puede apreciar claramente que estamos utilizando el tipo timestamp y como valor por defecto CURRENT_TIMESTAMP.
Podemos apreciar que estas funciones guardan los datos en formato EEUU (2010-01-28 15:38:54), cosa que no nos interesa y por la cual normalmente buscariamos otro método, pero aquí viene lo interesante.

La función DATE_FORMAT

Con esta función nos podemos permitir el lujo de formatear las fechas a nuestro anotjo a la hora de hacer las consultas.

Un ejemplo:

mysql> SELECT DATE_FORMAT(hora, '%H:%i:%s %e/%m/%y') AS hora FROM horas;
+-------------------+
| hora              |
+-------------------+
| 15:38:26 28/01/10 |
| 15:38:49 28/01/10 |
| 15:38:54 28/01/10 |
+-------------------+

Como se aprecia en el ejemplo tenemos una hora y fechas perfectamente formatadas.

Tratando las fechas en PHP

Ahora ya solo importa como vayamos a utilizar esta información, para el ejemplo yo voy a comprobar que se haya escrito hace menos de una hora, hoy o ayer, en caso de no ser ninguno de estos casos muestro la fecha mas no la hora.

He agregado un valor y modificado dos para que se produzca cada caso, así que ahora tenemos:


mysql> SELECT DATE_FORMAT(hora, '%H:%i:%s %e/%m/%y') AS hora FROM horas;
+-------------------+
| hora              |
+-------------------+
| 15:38:26 28/01/10 |
| 13:38:49 28/01/10 |
| 22:38:54 27/01/10 |
| 22:38:54 25/01/10 |
+-------------------+
4 rows IN SET (0.01 sec)
 
El código encargado de tratar con las fechas es:

<?php

$con 
= mysql_connect('localhost','root','') or die(mysql_error());
mysql_select_db('z_test',$con) or die(mysql_error());

$query = mysql_query("SELECT DATE_FORMAT(hora, '%H:%i:%s %e/%m/%y') 

                     AS hora FROM horas;",$con);

while ($list = mysql_fetch_array($query)) {
   
$all = explode(' ', $list['hora']);
   
$data = explode('/', $all[1]);
   
$time = explode(':', $all[0]);

   echo 
'<br />Publicado: ';
   
   if (
date('H') - $time[0] <= 1 && date('d') == $data[0])
      echo 
'Hace una hora';
   else if (
date('d') == $data[0])
      echo 
'Hoy';
   else if (
date('d') - $data[0] == 1)
      echo 
'Ayer';
   else
      echo 
$all[1];
}

?> 



Y para finalizar la salida de la página:

Publicado: Hace una hora
Publicado: Hoy
Publicado: Ayer
Publicado: 25/01/10

Espero que os sirva para un futuro.

Bug en Mysql en tipos BINARY, VARCHAR, CHAR

Como un artículo anterior este viene de la mano de ^Tifa^ y como su descubridora todos los méritos a su persona.

El escenario




mysql> CREATE TABLE ejemplo(
    -> nombres BINARY(20));
Query OK, 0 rows affected (0.39 sec)
 
mysql> INSERT INTO ejemplo VALUES('Juan'),('Pepe'),('Jose');
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows IN SET (0.00 sec)
 
 
Ese es el escenario.
Ahora una actualización de datos:
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = hex('Juan');
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = 'Juan';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
mysql> DELETE FROM ejemplo WHERE nombres = 'Pepe';
Query OK, 0 rows affected (0.00 sec)
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows IN SET (0.00 sec) 

Como se aprecia ni se actualiza ni se borra...

Intentamos solucionar el tema con un alter:

 
mysql> DESCRIBE ejemplo;
+---------+------------+------+-----+---------+-------+
| FIELD   | Type       | NULL | KEY | DEFAULT | Extra |
+---------+------------+------+-----+---------+-------+
| nombres | BINARY(20) | YES  |     | NULL    |       |
+---------+------------+------+-----+---------+-------+
1 row IN SET (0.00 sec)
 
mysql> ALTER TABLE ejemplo MODIFY nombres varchar(25);
Query OK, 3 rows affected (0.45 sec)
Records: 3  Duplicates: 0  Warnings: 0
 
mysql> UPDATE ejemplo SET nombres = 'Carlos' WHERE nombres = 'Juan';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
mysql> DELETE FROM ejemplo WHERE nombres = 'Pepe';
Query OK, 0 rows affected (0.00 sec)
 
mysql> SELECT * FROM ejemplo;
+----------------------+
| nombres              |
+----------------------+
| Juan                 |
| Pepe                 |
| Jose                 |
+----------------------+
3 rows IN SET (0.00 sec)
 
 
ni por ahí...
Esto también se aplica también a tablas con datos tipo char, varchar,etc 
si se altera a binary.
 
mysql> CREATE TABLE ejemplo2(
    -> nombres varchar(20));
Query OK, 0 rows affected (0.38 sec)
 
mysql> INSERT INTO ejemplo2 VALUES('pepe'),('Juan'),('pedro'),('luis');
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+---------+
| nombres |
+---------+
| pepe    |
| Juan    |
| pedro   |
| luis    |
+---------+
4 rows IN SET (0.00 sec)

Un ejemplo con varchar funcionando perfectamente

mysql> UPDATE ejemplo2 SET nombres = 'Cucu' WHERE nombres = 'pepe';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+---------+
| nombres |
+---------+
| Cucu    |
| Juan    |
| pedro   |
| luis    |
+---------+
4 rows IN SET (0.00 sec)
 
 
Ahora alteramos a Binary
mysql> ALTER TABLE ejemplo2 MODIFY nombres BINARY(20);
Query OK, 4 rows affected (0.27 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> SELECT * FROM ejemplo2;
+----------------------+
| nombres              |
+----------------------+
| Cucu                 |
| Juan                 |
| pedro                |
| luis                 |
+----------------------+
4 rows IN SET (0.00 sec)
 
mysql> UPDATE ejemplo2 SET nombres = 'Marta' WHERE nombres = 'Cucu';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
 
se jodió la tabla...
volvemos a varchar
 
mysql> ALTER TABLE ejemplo2 MODIFY nombres varchar(20);
Query OK, 4 rows affected (0.10 sec)
Records: 4  Duplicates: 0  Warnings: 0
 
mysql> DESCRIBE ejemplo2;
+---------+-------------+------+-----+---------+-------+
| FIELD   | Type        | NULL | KEY | DEFAULT | Extra |
+---------+-------------+------+-----+---------+-------+
| nombres | varchar(20) | YES  |     | NULL    |       |
+---------+-------------+------+-----+---------+-------+
1 row IN SET (0.00 sec)
 
mysql> UPDATE ejemplo2 SET nombres = 'Marta' WHERE nombres = 'Cucu';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0
 
Como se aprecia gracias al Changed: 0
no se actualizaron los datos pese a su tipo varchar.
 
 
Fuente original: Mini-Bug en Mysql 

Recuperar el password de MySQL en Windows

La información me llega desde elhacker.net de la mano de ^Tifa^.

Una de las posibles maneras de recuperar una contraseña en MySQL.

Lo vamos a explicar bajo una plataforma Windows.

Necesario:

- Ser administrador o privilegios de administrador.


Proceso:

- Inicio > ejecutar > cmd o win+R cmd

- Detenemos el Proceso de MySQL, esta parte depende de cada uno... si es un Cpanel o nuestro windows.

En windows puede hacerse así por ejemplo:
C:\> net stop mysql

- nos dirijimos a la carpeta de mysql/bin o si tenemos el path para usar mysql desde cualquier dirección (Tutorial aquí), escribimos:

c:\>cd path/to/bin

- ejecutamos la siguiente sentencia:
c:\> mysqld.exe -u root --skip-grant-tables

donde root es el usuario, pero va especialmente orientado a root.

- Ahora abrimos otra cmd y escribimos

c:\> mysql

- ya deberiamos haber logueado sin ningún tipo de problema.

- ahora ejecutamos una query para ver si el usuario existe realmente.
mysql> select user from mysql.user;

- y updateamos el campo password
mysql> update mysql.user set password = password('TU_NUEVA_CONTRASENA') where user = 'root';

- por último
mysql> flush privileges;

- ahora ya cerramos la anterior cmd e iniciamos el proceso mysql

c:\>net start mysql

Usar mySQL desde consola de comandos msdos

Bueno lo haremos con un XAMPP pero la idea es básicamente encontrar donde está el mysql.exe y hacer los mismos pasos.


Paso 1 Buscar myql.exe

Yo uso XAMPP instalado por default así que está aquí:

C:\xampp\mysql\bin
Paso 2: Agregar a variables de entorno

una ves con esta ruta vamos a:

inicio - mipc - propiedades - opciones avanzadas - variables de entorno

seleccionamos PATH y damos a modificar.

agregamos un ; y la ruta anteriormente citada a mi me quedaria así:


C:\Archivos de programa\Nmap;C:\xampp\mysql\bin
Aceptamos todo, y abrimos una cmd.


Paso 3: comandos básicos

Para entrar en MYSQL escribimos:


mysql -u usuario -p
(si no hay password no ponemos -p)

ya estamos en mysql modo consola

voy a listar una serie de comandos básicos de mysql, mas adelante pondré mas.

show databases;
muestra todas las BD


mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| cdcol              |
| main               |
| mydb               |
| mysql              |
| pbxt               |
| phpmyadmin         |
| scam               |
| smf_test           |
| users              |
| website            |
| z_test             |
+--------------------+
12 rows in set (0.00 sec)
use nom_db;
seleccionamos una DB.


mysql> use z_test;
Database changed
show tables;
mostramos todas las tablas.


mysql> show tables;
+------------------+
| Tables_in_z_test |
+------------------+
| monsters         |
| mvp              |
| players          |
+------------------+
3 rows in set (0.00 sec)
describe tabla;
hace una descripción de la tabla


mysql> describe monsters;
+-----------+--------------+------+-----+---------+----------------+
| Field     | Type         | Null | Key | Default | Extra          |
+-----------+--------------+------+-----+---------+----------------+
| id        | int(11)      | NO   | PRI | NULL    | auto_increment |
| monster   | varchar(100) | YES  |     | NULL    |                |
| dead      | int(11)      | YES  |     | NULL    |                |
| id_player | int(11)      | YES  |     | NULL    |                |
+-----------+--------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)
select * from tabla;
vemos todo los datos de la tabla.


mysql> select * from monsters;
+----+-----------+------+-----------+
| id | monster   | dead | id_player |
+----+-----------+------+-----------+
|  1 | monster 1 |    0 |         1 |
|  2 | monster 2 |    5 |         1 |
|  3 | monster 2 |    4 |         2 |
|  4 | monster 1 |    0 |         2 |
+----+-----------+------+-----------+
4 rows in set (0.02 sec)
exit;
salir

mysql> exit
Bye
A partir de aquí simplemente hacemos consultas SQL. Hay algunos comandos interesantes pero lo dejaremos para otra ocasión.

No os olvideis de poner el punto y coma al final de las sentencias.

Solución al error de codificación para PHP/MySQL

Bueno... hoy he estado un buen rato "haciendo nada", nunca mejor dicho... uno de esos problemillas que nunca sabemos porque suceden.. y que todo el mundo en la web encuentra solución menus tu -.-"

Bueno el tema estaba en un problema con la codificación, se veia el tipico rombo negro con un ? que te saca de quicio....

Lo mas divertido es que tenia el meta con utf8, la bd con utf8_general_ci y todas las tablas sin contar que la BD guardaba los datos correctamente y que solo habia problemas al mostrarlos, pero, oh! si escribias un echo "ó"; en el php se ve perfectamente!

Enfin que tras 2 horas buscando en los archivos de configuración de Apache y MySQL, pues el error tenia que estar en la transferencias de estos, me encontré con un artículo interesante y que me solucionó el problema.

La broma se trata de agregar

<?php
@mysql_query("SET NAMES 'utf8'");
?>


directamente después del mysql_select_db()

Por lo que un code de ejemplo será:

<?php
//Consultas a la BD   
   
$con = db_connect();
   
mysql_select_db($db, $con) or die(mysql_error());
   @
mysql_query("SET NAMES 'utf8'"); //totalmente necesario -.-"
?>


y ya tenemos una codificación perfecta en nuestra web...
eso si, con una hora menos para trabajar en lo realmente importante...

enfin me voy a la ducha xD

Diferencias entre Myisam y InnoDB

Me encuentro diseñando un par de aplicaciones y este es un tema que siempre te planteas, cual tengo que utilizar?

Una forera de elhacker.net (^Tifa^) me recomendó un servidor con InnoDB para consultas Insert y Update y otro con Myisam para Select, pero claro... no todos podemos permitirnos tal cosa, y yo menos.

Así que en base a ciertos valor tendremos que "jugarnosla" por uno de ellos.
Vamos a exponer los principales puntos que se comentan en la red, que no todos, pues no soy ningún experto.

InnoDB:
- En general se recomienda para consultas Insert y Update por su integridad a la hora de guardar datos
- Lo que lo convierte en mas lento
- Pero mas seguro (bajo cortes de luz, por ejemplo, si la consulta no se ejecutó completamente no se guarda y así no recibimos la mitad de los datos corruptos)
- También tiene las Foreng Keys (FK), lo cual lo hace muy util para una base de datos optimizada

Myisam:
- Se recomenda para aquellos diseños en los que suele haber mas SELECT que no Insert o Update
- No garantiza la integridad de nuestros datos,
- lo cual lo convierte en mas rapido
- pero menos seguro a lo que datos se refiere
- Quizá su mayor desventaja es que no tiene las preciadas FK
- Los Text se indexan con mayor desempeño, lo cual permite crear una "specie de buscador" mas eficiente que en InnoDB

A grandes rasgos quizá esto sea lo mas importante a destacar

Conclusión propia:

Mi conclusión es siempre decantarme por InnoDB (si necesito FK), soy un negado del SQL si algún dia le meto mas tiempo y aprendo a usar los TRIGGERS quizá mi visión del mundo cambie. De momento prefiero utilizar InnoDB y sus amadas FK para mis base de datos relacionales.

Conclusión de otras entidades:
Otros blogs, web, docuemntos, dicen que si tu sitio es mas propenso a recibir datos que no a mostrarlos, tu motor es InnoDB, como el caso no se suele producir frecuentemente, por regla general el motor a usar es myisam.
Quizá lo lógico, bajo esa perspectiva, es tener alguna tabla tipo un log de acciones con un motor InnoDB y el resto usando myisam.

En definitiva, cada uno escoja lo que mas le convenga de acuerdo a su necesidad o gustos. El post pretende ser una guia para empezar a tomar conciencia de que es cada motor y en que se diferencian. A partir de este punto queda investigarlos un poco mas y tomar la decisión de cual de ambos necesita nuestra aplicación.

Posible 0Day para MySQL 5.x

Leyendo hoy el blog de Security By Default me entero de que posiblemente tengamos una preocupación más todos los webmasters que utilizamos MySQL.

Aunque SbD ni afirma ni desmiente que el 0Day sea verdadero, la empresa detrás del 0Day, intevydis, parece ser de fiar

Dicha empresa comercializa un 'pack' de exploits para Canvas y ha colgado un video que muestra el 0Day para MySQL en versiones 5.x

Fuente: SbD