Blog

Perfecto. Aquí tienes la entrada pensada para que puedas copiarla directamente en el editor Gutenberg de WordPress. Usa bloques de párrafo, encabezado y código para mantenerlo limpio y claro.

🧪 Tarjetas de prueba para entornos de desarrollo

Este es un conjunto de datos ficticios que puedes usar en tu entorno de pruebas. No funcionan en producción ni están vinculados a ninguna cuenta real. Son útiles para simular operaciones normales y fallidas.

✅ Tarjeta de prueba válida

Número:        4548 8120 4940 0004  
Caducidad:     12/22  
CVV2:          123  
Código CIP:    123456

❌ Tarjeta que genera operación denegada

Número:        1111 1111 1111 1111  
Caducidad:     12/22

🔐 Clave de cifrado (solo para pruebas)

qwertyasdf0123456789

Y ya está. Sin complicaciones. Pruébalo, verifica tus flujos y asegúrate de que todo responde como debería antes de pasar a producción.

La diferencia principal entre los comandos wget -q -O - [URL] y wget -q --spider [URL] radica en qué hacen con la URL solicitada y cómo manejan el contenido descargado.

Diferencias principales de usar "--spider«

1. wget -q -O - [URL]

Este comando:

• Descarga el contenido de la URL especificada.
• Muestra el contenido en la salida estándar (normalmente en la terminal), gracias a -O -.
• -q (quiet): Ejecuta el comando de forma silenciosa, sin mostrar mensajes de progreso.

📌 Uso típico:
Cuando deseas obtener y procesar el contenido de una página o archivo directamente desde la web.
Por ejemplo, para descargar y analizar el contenido HTML de una página o alimentar la salida a otro comando:

wget -q -O - https://example.com/page.html | grep "titulo"

2. wget -q --spider [URL]

Este comando:

• No descarga el contenido de la URL.
• Verifica si la URL está disponible (comportamiento similar a un «ping» web).
• --spider: Hace que wget actúe como un «araña web» (web spider), comprobando la existencia del recurso sin descargarlo.
• -q (quiet): Silencia la salida, aunque seguirá utilizando el código de retorno para indicar éxito o fallo.

wget -q --spider https://example.com/page.html && echo "Disponible" || echo "No disponible"

🔍 Diferencias clave:

💡 ¿Cuándo usar cada uno?

• Usa wget -q -O - cuando necesites el contenido del recurso (por ejemplo, descargar un JSON desde una API para procesarlo).
• Usa wget -q --spider cuando solo quieras saber si el recurso existe o está disponible sin descargarlo (por ejemplo, verificar enlaces válidos antes de iniciar una descarga masiva).

Aclarando el comportamiento de «--spider«

🔍 ¿Por qué --spider ejecuta la tarea?

Aunque --spider se describe como una opción para «comprobar la existencia de un recurso», en la práctica realiza una solicitud HTTP completa, incluyendo una solicitud GET (por defecto) al servidor, pero sin descargar el cuerpo de la respuesta.

Esto significa:

• Si la URL apunta a un script en el servidor (como un controlador en PrestaShop para importar pedidos), el código del servidor se ejecutará porque el servidor maneja la solicitud antes de decidir qué parte de la respuesta devolver.
• La única diferencia es que wget con --spider no descargará el contenido de la respuesta.

Por eso tu tarea se ejecuta si usas --spider: el servidor procesa la solicitud aunque wget no guarde ni muestre la respuesta.

✅ Forma más adecuada para llamar a una URL en una tarea programada

Quieres un cronjob que:

1. Llame a una URL de tu dominio para ejecutar una tarea.
2. No genere salida (ni archivos, ni mensajes en pantalla).
3. Ejecute efectivamente el código (es decir, que el servidor procese la solicitud).

💡 La mejor opción sería:

wget -q -O /dev/null "https://tudominio.com/ruta/a/tu/script.php?token=seguro"

💬 ¿Por qué esta opción es la más adecuada?

• -q: Silencia toda la salida de wget.
• -O /dev/null: Descarta cualquier salida de la respuesta redirigiéndola a /dev/null, lo que garantiza que:
  • No se generen archivos.
  • No se muestre información en pantalla.
• La URL se solicita normalmente (igual que cuando visitas la URL en el navegador), asegurando que el código PHP se ejecute en el servidor.

🚀 Ejemplo completo del cronjob:

Edita el cron del usuario adecuado con crontab -e y añade:

* * * * * wget -q -O /dev/null "https://tudominio.com/ruta/a/tu/script.php?token=seguro"

Este ejemplo se ejecutará cada minuto (cambia la periodicidad según tus necesidades).

🔒 Recomendaciones extra de seguridad

Si la URL que dispara la tarea es sensible:

• Usa un token secreto en la URL (como en el ejemplo) para evitar que cualquiera pueda llamarla.
• Configura el servidor para que solo acepte llamadas desde direcciones IP de confianza si es posible.
• Valida el token en el código PHP antes de ejecutar la tarea.

⚡ ¿Por qué no --spider en este caso?

Aunque --spider funciona en tu contexto porque el servidor ejecuta el script, su propósito principal es comprobar la existencia del recurso. Dado que:

• No necesitas su semántica de «verificación».
• Prefieres claridad en el código.

Es mejor usar -O /dev/null, que expresa más claramente:
👉 «Llama a esta URL, ejecuta lo que tenga que ejecutar, pero descarta cualquier salida.»

En ocasiones nos encontramos con problemas para realizar algunas acciones en el servidor, ya sea local y un hosting. Casos como por ejemplo que no podamos subir una base de datos, o algún script que acaba dando un error 500.

Pues bien, gran parte de estos problemas se pueden deber a las limitaciones que PHP impone en su configuración. Limitaciones creadas para evitar colapsos y males mayores dentro de nuestro servidor.

Sin embargo, hay ocasiones en las que necesitamos modificar esos límites para poder trabajar adecuadamente.

¿Dónde se encuentran estas limitaciones?

Las limitaciones que comentamos están definidas en los parámetros que contiene el fihcero de configuración de PHP llamado php.ini.

¿Cuáles son los parámetros principales que nos interesan?

A continuación vamos desglosar los principales parámetros que necesitamos cambiar para resolver estas limitaciones:

memory_limit: La cantidad máxima de memoria que un script de PHP puede utilizar durante su ejecución

El parámetro memory_limit en el archivo php.ini establece la cantidad máxima de memoria que un script de PHP puede utilizar durante su ejecución. Esto significa que si un script intenta consumir más memoria de la permitida, PHP detendrá su ejecución y emitirá un error fatal. Este límite es fundamental para evitar que scripts mal optimizados o con fugas de memoria afecten negativamente el rendimiento y la estabilidad del servidor.

post_max_size: El tamaño máximo de datos que se pueden enviar mediante una solicitud POST

El parámetro post_max_size en el archivo «php.ini» define el tamaño máximo de datos que se pueden enviar mediante una solicitud POST. Esto incluye no solo el contenido de los campos del formulario, sino también los archivos subidos. Si se supera este límite, PHP no procesará los datos y la variable $_POST quedará vacía. Es importante configurarlo adecuadamente para evitar problemas en el envío de formularios y en las cargas de archivos, y suele usarse en conjunto con otros parámetros como upload_max_filesize para controlar de manera integral las transferencias de datos.

Si le asignamos el valor 0 desactivamos su líimite.

upload_max_filesize: El tamaño máximo permitido para cada archivo que se sube al servidor mediante formularios HTML

El parámetro upload_max_filesize en el archivo php.ini define el tamaño máximo permitido para cada archivo que se sube al servidor mediante formularios HTML. Si un usuario intenta cargar un archivo que excede este límite, PHP no lo aceptará y la operación de carga fallará. Este parámetro es fundamental para gestionar el uso de recursos del servidor y, generalmente, debe configurarse en consonancia con el valor de post_max_size, que establece el límite total para la solicitud POST.

Hurgando en el historial del VPS: qué hace cada comando — y por qué el técnico los lanzó

Cuando un sysadmin deja huellas en tu servidor, su historial de comandos puede convertirse en una clase magistral de diagnóstico. A continuación repaso, en clave de “entrada de blog”, los diez comandos que encontraste: qué hacen exactamente y la lógica que hay detrás de cada uno.

1. Filtro milimétrico por minuto y sin «notices»

cat /var/log/httpd/domains/tiendaonline.com.error.log \
  | fgrep "Wed Jan 29 13:40:" \
  | fgrep -v "PHP message: PHP Notice:"

1. cat vuelca todo el archivo de error del vHost.
2. Primer fgrep conserva sólo las líneas cuyo prefijo de fecha-hora sea Wed Jan 29 13:40: (es decir, cualquier segundo dentro de las 13:40).
3. Segundo fgrep -v descarta las líneas que contienen el literal PHP Notice, limpiando avisos poco críticos para quedarse con errores “de verdad”.

Uso típico: centrar la lupa en el minuto exacto del fallo y eliminar la paja de los avisos de PHP.

2. El mismo minuto, pero sin filtrar avisos

cat /var/log/httpd/domains/tiendaonline.com.error.log | fgrep "Wed Jan 29 13:40:"

Aquí se repite el filtrado por minuto, pero sin la exclusión de notices. Suele hacerse antes (o después) del paso anterior para tener la foto completa y luego decidir qué descartar.

3 y 4. Afinando por segundos

# segundos del 20 al 29
cat ...error.log | fgrep "Wed Jan 29 13:40:2"

# segundo exacto 13:40:20
cat ...error.log | fgrep "Wed Jan 29 13:40:20"

La misma técnica llevada al detalle:

• Añadir 2 después de 13:40: acota a los segundos 20-29.
• Especificar 13:40:20 clava un único segundo.

¿Por qué tanto zoom? Para averiguar qué petición (o atacante) detonó el problema en un instante concreto.

5. Volver a la vista global del minuto

cat ...error.log | fgrep "Wed Jan 29 13:40:"

Una segunda pasada idéntica a la del punto 2. Tras jugar con segundos concretos, el técnico suele regresar a la panorámica para comprobar que nada se le escapó.

6. Siguiendo la pista a una IP sospechosa

cat ...error.log | fgrep "148.56.129.205"

Busca todas las entradas donde aparezca la IP 148.56.129.205—quizás un bot, un atacante o el mismo cliente detrás de la incidencia.

7. Rastreo por identificador interno

fgrep "seidivid" tiendaonline.com.error.log

Sin cat: fgrep lee el archivo directo. El literal seidivid podría ser:

• un nombre de usuario,
• una cookie de sesión,
• un parámetro GET/POST…

Sea lo que sea, el comando lista cada línea en la que salga para seguir el hilo del bug.

8. Otra franja horaria bajo la lupa

fgrep "Jan 29 08:4" tiendaonline.com.error.log

08:4 significa “cualquier segundo entre 08:40 y 08:49”. Probablemente el técnico quiso comparar la franja de la mañana frente a la de la tarde para descartar patrones.

9. Asomarse a lo más reciente

tail -100 tiendaonline.com.error.log

Tail muestra las últimas 100 líneas del log. Es la forma más rápida de ver qué pasó justo ahora, sin tener que abrir un archivo enorme con less.

Añadir -f (“follow”) convertiría el comando en un visor en tiempo real.

Conclusión

Revisar el historial de la terminal no es cotilleo: es un método excelente para aprender prácticas de depuración. Ahora ya sabes por qué tu proveedor lanzó cada línea y cómo aplicar tú mismo estos filtros la próxima vez que tu servidor se ponga rebelde. ¡Feliz logging!

Podemosa hacer esto usando el siguiente comando:

cat tiendaonline.com.log | awk '{print $1}' | sort -n | uniq -c | sort -n | tail -n 20 | awk '{printf $1"    ";system("csf -i "$2)}'

Este pipeline realiza lo siguiente, paso a paso:

1. cat tiendaonline.com.log
   Lee todo el contenido del fichero de log.
2. awk '{print $1}'
   Extrae el primer campo de cada línea (normalmente la dirección IP del cliente).
3. sort -n
   Ordena las IPs de forma numérica (para que las mismas queden agrupadas).
4. uniq -c
   Cuenta cuántas veces aparece cada IP consecutivamente (produciendo líneas con: <veces> <IP>).
5. sort -n
   Vuelve a ordenar esas líneas por el número de apariciones, de menor a mayor.
6. tail -n 20
   Toma las 20 últimas líneas de esa lista, es decir, las 20 IPs que más peticiones han hecho (las de mayor recuento).
7. awk '{ printf $1" "; system("csf -i "$2) }'
   Para cada una de esas 20 líneas:
   • Imprime el contador ($1) y unos espacios.
   • Ejecuta csf -i <IP> (comando de ConfigServer Firewall) para mostrar información detallada sobre esa IP (por ejemplo, si está bloqueada, su reputación, reglas aplicadas, etc.).

En resumen:
Extrae las 20 direcciones IP más activas del log tiendaonline.com.log, muestra cuántas peticiones ha hecho cada una y, acto seguido, invoca csf -i para consultar el estado o detalles de configuración del firewall para cada IP.

Estas son las máximas para un correcto etiquetado:

• %Y%m%d corresponde al año, mes y día: 20250122
• %H%M%S corresponden a la hora, minuto y segundo: 102642
• @DATABASE@ es el nombre de la base de datos
• @TABLE@ es el nombre de la tabla

Al exportar bases de datos

%Y%m%dT%H%M%S_@DATABASE@

Al exportar tablas

Se le incluye @TABLE@ al final, separado por un _ guión bajo.

El formato de las exportaciones está definido en el FAQ 6.27 de phpMyAdmin y por la documentación de la función strftime de PHP

En ocasiones nos encontramos con un mensaje de error similar a este cuando tratamos de importar una base de datos muy grande a phpMyAdmin:

«Tiempo de ejecución del script agotado; si desea completar la importación, reenvíe el mismo archivo y la importación continuará.»

¿Cómo resolverlo?

Lo que hay que hacer es editar el archivo de configuración de phpMyAdmin que se llama config.inc.php. Para ello, dirígete a la ruta de tu phpMyAdmin, haz una copia de seguridad de dicho archivo de configuración y luego procede a editarlo:

Lo que debes hacer es agregar la siguiente línea, en caso de no existir:

/*https://docs.phpmyadmin.net/en/latest/config.html#cfg_ExecTimeLimit*/
$cfg['ExecTimeLimit']=0;

En donde 0 se refiere a deshabilitar el tiempo límite, ya que por defecto esta variable está fijada a 300.

Con la siguiente consulta puedes ver el tamaño de todas las tablas de tu base de datos.

En mi caso tengo presente el uso de LIMIT, ya que hay bases de datos que pueden tener cientos de tablas, y quizás podría ser extenuante para el servidor realizar tamaña consulta.

SELECT 
     table_schema as `Database`, 
     table_name AS `Table`, 
     round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB` 
FROM information_schema.TABLES 
ORDER BY (data_length + index_length) DESC;

Para exportar tu base de datos MySQL desde la terminal usando mysqldump sigue estos pasos:

Exportación sin contraseña en el comando (como root)

Si estás logueado como root en el sistema y MySQL no te solicita contraseña al acceder con mysql -u root, puedes hacer la exportación con:

mysqldump -u root tienda_ps > tienda_ps_backup.sql

Exportación con usuario y contraseña

Si deseas hacer la exportación usando las credenciales del usuario tienda_ps, el comando es:

mysqldump -u tienda_ps -p tienda_ps > tienda_ps_backup.sql

Después de ejecutar el comando, te pedirá la contraseña. Ingrésala y presiona Enter.

Exportación con contraseña en el comando (no recomendado)

Si deseas incluir la contraseña directamente en el comando (por ejemplo, en scripts automáticos), puedes usar:

mysqldump -u tienda_ps -p'a1b2c3d4e5f6' tienda_ps > tienda_ps_backup.sql

Opciones útiles de mysqldump

Puedes mejorar la exportación agregando algunas opciones:

mysqldump -u tienda_ps -p --routines --events --single-transaction --quick --add-drop-database --databases tienda_ps > tienda_ps_backup.sql

• --routines: Incluye procedimientos almacenados y funciones.
• --events: Guarda eventos de la base de datos.
• --single-transaction: Mejora la consistencia en bases de datos grandes.
• --quick: Reduce el consumo de memoria.
• --add-drop-database: Agrega la instrucción DROP DATABASE antes de la creación.

Verificación de la exportación

Después de la exportación, verifica que el archivo se haya creado correctamente con:

ls -lh tienda_ps_backup.sql

Si necesitas revisar el contenido del archivo:

head -n 20 tienda_ps_backup.sql

Con esto deberías tener una copia segura de tu base de datos.

Ahora vamos a comprimir tu archivo de exportación desde la terminal. Puedes elegir entre tar.gz o zip según prefieras.

1️⃣ Comprimir en formato .tar.gz

Este formato es más eficiente en términos de compresión y es ampliamente usado en Linux.

tar -czvf tienda_ps_backup.tar.gz tienda_ps_backup.sql

• -c → Crea un nuevo archivo.
• -z → Comprime con gzip.
• -v → Muestra el progreso en la terminal.
• -f → Especifica el nombre del archivo.

Después de ejecutar este comando, tendrás el archivo tienda_ps_backup.tar.gz en la misma carpeta.

Para verificar que el archivo fue creado:

ls -lh tienda_ps_backup.tar.gz

Si deseas listar los archivos dentro del .tar.gz sin descomprimirlo:

tar -tzvf tienda_ps_backup.tar.gz

2️⃣ Comprimir en formato .zip

Si prefieres .zip, usa:

zip tienda_ps_backup.zip tienda_ps_backup.sql

Para verificar que el .zip fue creado correctamente:

ls -lh tienda_ps_backup.zip

Para listar los archivos dentro del .zip:

unzip -l tienda_ps_backup.zip

📌 Nota: Borrar el archivo SQL después de la compresión (opcional)

Si ya no necesitas el archivo .sql sin comprimir, puedes eliminarlo con:

rm tienda_ps_backup.sql

Con eso, tu respaldo estará comprimido y listo para ser almacenado o transferido.

Para exportar sólo una o varias tablas concretas de tu base de datos MySQL usando mysqldump, los pasos son muy similares a los que ya viste:

🔹 1. Exportar una sola tabla

Como root (sin contraseña)

Si estás logueado como root y no se te pide contraseña:

mysqldump -u root tienda_ps nombre_de_la_tabla > tabla_backup.sql

Con usuario y contraseña (prompt)

Usando tu usuario tienda_ps y que te pida la contraseña:

mysqldump -u tienda_ps -p tienda_ps nombre_de_la_tabla > tabla_backup.sql

Al ejecutar, te pedirá la contraseña; introdúcela y pulsa Enter.

Con contraseña inline (menos seguro)

Para scripts automáticos (¡ojo al historial!):

mysqldump -u tienda_ps -p'a1b2c3d4e5f6' tienda_ps nombre_de_la_tabla > tabla_backup.sql

🔹 2. Exportar varias tablas a la vez

Basta con listarlas separadas por espacio tras el nombre de la base de datos:

Sin contraseña (root)

mysqldump -u root tienda_ps tabla1 tabla2 tabla3 > tablas_backup.sql

Con prompt de contraseña

mysqldump -u tienda_ps -p tienda_ps tabla1 tabla2 tabla3 > tablas_backup.sql

Con contraseña en el propio comando

mysqldump -u tienda_ps -p'a1b2c3d4e5f6' tienda_ps tabla1 tabla2 tabla3 > tablas_backup.sql

🔧 Opciones útiles adicionales

Puedes combinar con opciones para mayor consistencia y rendimiento:

mysqldump -u tienda_ps -p \
  --single-transaction \
  --quick \
  --lock-tables=false \
  tienda_ps tabla1 tabla2 \
  > tablas_backup.sql

• --single-transaction: exporta sin bloquear lecturas en InnoDB.
• --quick: vuelca fila a fila, minimiza uso de memoria.
• --lock-tables=false: evita bloqueos de tablas (con InnoDB y --single-transaction suele bastar).

🗜️ 3. Comprimir el volcado

• Formato .tar.gz

tar -czvf tablas_backup.tar.gz tablas_backup.sql

Verificar:

ls -lh tablas_backup.tar.gz

• Formato .zip

zip tablas_backup.zip tablas_backup.sql

Verificar:

ls -lh tablas_backup.zip

Eliminar SQL sin comprimir (opcional):

rm tablas_backup.sql

Con esto podrás extraer únicamente la(s) tabla(s) que necesites y mantener tus respaldos más ligeros y específicos.