Estas en: Home > servidor

Entradas etiquetadas con servidor

Dominando el comando SCP en Linux para transferir archivos: Una guía para usuarios iniciados

0

En el vasto mundo de la administración de sistemas y la transferencia de archivos, el comando «scp" (Secure Copy Protocol) emerge como una herramienta fundamental. Si eres nuevo en el mundo de la administración de sistemas o simplemente estás comenzando tu viaje en el mundo de la línea de comandos, «scp" es una herramienta que pronto se convertirá en tu mejor aliado. En este artículo, exploraremos qué es «scp«, cómo funciona y cómo puedes empezar a usarlo para transferir archivos de forma segura entre sistemas remotos.

¿Qué es SCP?

«scp» es un comando utilizado en sistemas basados en Unix y Unix-like que permite la transferencia segura de archivos entre sistemas locales y remotos a través de SSH (Secure Shell). Utiliza el mismo protocolo de autenticación y encriptación que SSH, lo que garantiza que tus datos se transfieran de manera segura a través de redes inseguras como Internet.

Sintaxis Básica de SCP

La sintaxis básica de «scp" es bastante sencilla. La estructura general del comando es la siguiente:

scp [opciones] origen destino
  • origen: Especifica la ubicación del archivo o directorio que deseas transferir. Puede ser un archivo local o remoto.
  • destino: Especifica la ubicación a la que deseas transferir el archivo o directorio. Al igual que el origen, puede ser una ubicación local o remota.

Ejemplos Prácticos

Copiar un Archivo Local a un Servidor Remoto

Para copiar un archivo desde tu sistema local a un servidor remoto, puedes usar el siguiente comando:

scp archivo.txt usuario@servidor:/ruta/destino

Esto copiará el archivo «archivo.txt" al servidor remoto especificado en la ruta «/ruta/destino«, autenticándote con el nombre de usuario usuario.

Copiar un Archivo Remoto a tu Sistema Local

Si deseas copiar un archivo desde un servidor remoto a tu sistema local, simplemente invierte el orden del origen y el destino:

scp usuario@servidor:/ruta/archivo_remoto.txt /ruta/destino_local

Esto copiará el archivo «archivo_remoto.txt" del servidor remoto a la ruta local «/ruta/destino_local«.

Opciones Útiles de SCP

scp ofrece una variedad de opciones que puedes utilizar para personalizar tu experiencia de transferencia de archivos. Algunas de las opciones más útiles incluyen:

  • -r: Permite la copia recursiva de directorios y sus contenidos.
  • -P puerto: Especifica el puerto SSH a utilizar en lugar del puerto estándar (22).
  • -v: Habilita el modo verboso, lo que proporciona una salida detallada para depurar problemas.
  • -C: Habilita la compresión durante la transferencia para mejorar el rendimiento en conexiones lentas.

Conclusiones

«scp" es una herramienta poderosa y fácil de usar para transferir archivos de forma segura entre sistemas remotos y locales. Con su integración con SSH, puedes estar seguro de que tus datos se transfieren de manera segura en todo momento. A medida que te familiarices más con la línea de comandos y la administración de sistemas, «scp» se convertirá en una herramienta indispensable en tu caja de herramientas.

Subversion y Apache, corregir el error 413 Request Entity Too Large

0

Algunas veces, cuando realizamos commits con muchos archivos, Subversion no es capaz de procesar el commit y nos devuelve el error «413 Request Entity Too Large». Este error se produce porque el commit que estás realizando tiene un tamaño superior al que tiene configurado Subversion al hacer la petición.

Para corregirlo hay que añadir los siguientes parámetros al virtual host del servidor de Subversion:

[codesyntax lang=»apache»]

LimitXMLRequestBody 0
LimitRequestBody 0

[/codesyntax]

Con estos dos parámetros eliminarás el límite impuesto por Subversion.

Si lo deseas, en vez de eliminar el límite puedes aumentarlo a 64MB,256MB, etc.

 

Cómo crear un servidor REST en PHP

0

Un servidor REST es una aplicación que nos permite crear, actualizar, eliminar y recuperar datos de forma remota siguiendo el estandar de diseño REST. Lo habitual cuando programamos, por ejemplo peticiones ajax, es nombrar las urls como «/obtenerProducto», «/crearProducto», etc. En REST los verbos «obtener» o «crear» no se usan, ya que se utiliza una única url para todas las acciones, en nuestro ejemplo «/producto». Además, REST nombra a estas urls como recursos.

Para poder diferenciar la acción que se está realizando sobre un recurso concreto se utiliza un método u otro en la petición: GET, POST, PUT o DELETE.

(más…)

Icono del ide de Selenium en Firefox

Integración continua: Instalando la herramienta Selenium para ejecutar test funcionales

0

Selenium (http://www.seleniumhq.org/) es un conjunto de herramientas que permiten automatizar ciertas acciones en los navegadores. Esta automatización nos permite crear test funcionales, para probar formularios, enlaces, etc., tareas muy repetitivas y muy poco agradables de llevar a cabo.

Si lo único que necesitas es saber como crear y automatizar en local los test funcionales puedes usar el plugin de Firefox que explico en el apartado «Creando los test funcionales».

(más…)

Digital Ocean, servidores privados virtuales con discos SSD

0

Es curioso cómo ha avanzado el alojamiento web en los últimos diez años: de pasar a ofertas de hostings y servidores dedicados desatendidos o no, a disponer de una amplia oferta en la que tú decides cuántos núcleos del microprocesador quieres tener, cuanta RAM, cuanto espacio de almacenamiento, etc.

Si nos retrotraemos, podremos ver como la virtualización ha cambiado completamente la forma de ver y entender tanto el negocio del alojamiento web, como el desarrollo y despliegue de aplicaciones web.

Aplicaciones. Cuando yo empecé a programar eran páginas web o sites. Hasta el vocabulario que usamos en el día a día no está exento de evolución.

Nos profesionalizamos.

Y esa profesionalización implica adaptarse a los nuevos cambios, ya que o evolucionas o te extingues.

(más…)

Integración continua: instalando y configurando Jenkins

0

Ya vistes la checklist del último post: https://www.interadictos.es/2014/08/11/integracion-continua-primeros-pasos/, ahora vamos a empezar a instalar y configurar algunas herramientas, para ir poco a poco uniéndolas.

¿Qué es Jenkins?

Jenkins es nuestro servidor de integración continua. Es una aplicación que permite automatizar una lista de tareas que le indiquemos. Estas tareas pueden ser iniciadas de forma manual, pero lo habitual será llamar a la primera tarea de la lista cada vez que se realice un commit en el repositorio, e ir concatenando tareas hasta finalizar la lista completa. Tranquilo si no te haces aun a la idea, a medida que vayamos avanzando con esta guía lo iras entendiendo.

Instalando Jenkins

Primero descargamos la key del servidor de Jenkins, que nos permitirá añadirlo al archivo sources.list:

wget −q −O   class="external free" style="color: #663366;" href="http://pkg.jenkins−ci.org/debian/jenkins−ci.org.key" rel="nofollow">http://pkg.jenkins−ci.org/debian/jenkins−ci.org.key | sudo apt−key add 

A continuación lo añadimos al archivo sources.list. Puedes añadirlo de esta manera o añadirlo a mano:

sudo sh −c 'echo deb  class="external free" style="color: #663366;" href="http://pkg.jenkins−ci.org/debian" rel="nofollow">http://pkg.jenkins−ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'

Actuliazamos la lista de paquetes e instalamos:

sudo apt−get update
sudo apt−get install jenkins

Ahora necesitamos poder acceder a él a través de la red, para ello vamos a crear el subdominio jenkins.ic.net. Para poder acceder por el subdominio jenkins.ic.net es necesario crear un virtual host con proxy inverso, para ello instalamos varios módulos de Apache2 necesarios:

sudo a2enmod proxy
sudo a2enmod headers
sudo a2enmod deflate
sudo a2enmod proxy_http

Ahora creamos un virtualhost en /etc/apache2/sites-available llamado 001-jenkins.ic.net.conf (Podeis usar el nombre que quieras), con el siguiente contenido

 *:80>
        ServerName jenkins.ic.net  

         *>
                Order deny,allow
                Allow from all
         

        ProxyPreserveHost On
        ProxyPass /  class="external free" style="color: #663366;" href="http://localhost:8080/" rel="nofollow">http://localhost:8080/
        ProxyPassReverse /  class="external free" style="color: #663366;" href="http://localhost:8080/" rel="nofollow">http://localhost:8080/

La ruta habitual para acceder a Jenkins sería http://localhost:8080, si pudieramos acceder desde el mismo servidor de integración continua, si lo hicieramos desde fuera sería http://ic.net:8080. Para evitar tener que recordar el número de puerto utilizamos el archivo anterior. Nos facilitará la vida.

Ahora creamos un enlace simbólico de este archivo en /etc/apache2/sites-enabled.

sudo ln −s /etc/apache2/sites−available/001−jenkins.ic.net.conf /etc/apache2/sites−enabled/001−jenkins.ic.net.conf

Reiniciamos apache con:

sudo /etc/init.d/apache2 reload

En nuestro ordenador tendremos que editar el archivo hosts, para indicarle al pc a qué ip debe dirigirse para encontrar el alojamiento de jenkins.ic.net. Añadimos la siguiente línea al archivo (sustituye la IP por la de tu servidor de integración continua):

192.168.1.40 jenkins.ic.net

Ahora podrás escribir el subdominio en el navegador para acceder a la página principal de Jenkins.

A partir de aquí te recomiendo que explores todas las opciones de Jenkins, además de echarle un ojo a la documentación: https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins

En la administración de Jenkins puedes acceder al apartado de plugins, revísalos y podrás hacerte una idea de las posibilidades de esta herramienta.

Cambiando todo el hardware del ordenador en Debian 7 Wheezy

0

Después de unos cuantos años sin renovar el hardware del pc, este mes tocó renovación, y a lo grande. Principalmente por el final de soporte de Windows XP y que para algunos proyectos (y juegos… ejem, ejem) necesitaba más memoria RAM.

He dedicado bastantes horas a valorar que hardware comprar y que no se me fuese de presupuesto. Al final me decidí por lo siguiente:

Micro AMD FX 8350 Black Edition (8 nucleos)

Placa base ASUS M5A99FX PRO R2.0

Tarjeta gráfica ASUS GeForce NVIDIA GTX 780

– Fuente de alimentación Aerocool Strike-X 800

Y torre nueva: Aerocool Strike-X Advance

Los discos duros, aunque ya han superado su edad de vida media, aun funcionan, así que de momento no se tocan.

La instalación fue relativamente sencilla, aunque como ocurre siempre en un equipo de hace seis años, siempre hay algo que no funciona en el hardware nuevo. Uno de ellos fue uno de los discos duros, que por alguna extraña razón la placa no me lo reconocía. Por suerte solo era un disco para almacenar chorradillas que no se donde meterlas.

Una vez conectados los discos duros y que todo estuviera bien conectado, crucé los dedos y pulse el interruptor de la torre… se encendió a la primera, la placa base, los leds azules de la la torre, los ventiladores, el cooler, la gráfica, los discos duros,… espera… ¿Y ese pantallazo azul?… Mierda, Windows XP ha cascao, seguro que tenía alguna librería en el disco duro que no reconocía la placa, en fin, ¡Larga vida a Debian 7!

La verdad es que no fue un gran problema que Windows XP muriese en el proceso, al fin y al cabo llevaba tiempo queriendo cambiar definitivamente a Debian, así que fue una razón más para abandonar Windows por algo mucho mejor.

Aunque leí que cambiar el hardware en Debian no tenía por qué suponer un problema, es decir, que al entrar en el Sistema Operativo todo funcionaría igual; mi experiencia me decía que esto iba a cascar por todos lados.

Bueno pues me equivoqué a medias: el cambio de hardware hizo que se mostrasen algunos fallos (el módulo del kernel para la tarjeta de red, por ejemplo), pero solo fallo por un lado: la tarjeta gráfica, que impedía que se iniciase el servidor gráfico.

Y es que Debian 7 Wheezy no reconocía la gráfica debido a que los drivers de nvidia en Wheezy solo llegan hasta la 302, y para que me la reconociese necesitaba mínimo la 319, que es la que da soporte a la GTX 780.

¿Solución? Actualizar a Debian 8 Jessie, o lo que es lo mismo: pasar de stable a testing. He de decir que Jessie es bastante estable, y sabiendo que está previsto que se congele la inclusión de nuevos paquetes en esta rama hacia Noviembre de 2014, no había riesgo de que fallase por otro lado.

En primer lugar hay que editar el archivo /etc/apt/sources.list y sustituir la palabra «wheezy» por «jessie«, y «stable» por «testing«.

Hacemos un apt-get update, y si todo ha ido bien ejecutamos apt-get dist-upgrade, y a esperar que se descargue e instale todo.

Una vez instalado todo, seguiremos sin gráfica y sin servidor gráfico. Primero comprobamos que ahora sí reconoce la gráfica escribiendo en la consola el siguiente comando: lspci | grep «VGA».

Este comando nos debe mostrar el modelo de tarjeta gráfica que tenemos.

Y a partir de aquí es hora de configurar la gráfica. Para ello os voy a dejar un artículo que me ha ayudado muchísimo a la hora de configurarla y se merece que le enlace; los pasos a seguir ya sea en Debian 7 Wheezy o Debian 8 Jessie son los mismos, con lo que espero que este tutorial os valga tanto como me ha servido a mí:

Instalar los drivers nvidia privativos en Debian

Pasar un repositorio Subversion a otro servidor

0

Hay veces en las que es necesario pasar nuestro repositorio Subversion a otro servidor, bien por falta de espacio o recursos, bien por cambio de proveedor. Para ello subversion nos ofrece varios comandos para realizar el proceso.

Como esta información ya existe en la red prefiero enlazaros al contenido original (mientras sea legal en España), en el que está muy bien explicado y me fue de mucha utilidad en su momento:

http://blog.wlacruz.com.ve/2011/10/migrar-o-mover-repositorio-de.html

Papercut: Testear el envío de emails sin necesidad de un servidor SMTP

0

Papercut es un servidor SMTP simplificado para recibir emails, no para enviarlos. Esta aplicación nos permite probar el envío de emails desde los sistemas operativos Windows, quitándonos la tediosa tarea de tener que configurar un servidor SMTP.

Papercut dispone de una interfaz muy sencilla y cómodo, que nos permite comprobar todos los detalles del email que queremos testear: desde el contenido, hasta las cabeceras, pasando por los archivos adjuntos.

Muy útil ante la necesidad de probar el envío de emails de uno de nuestros proyectos de una forma rápida, o en un ordenador que no es en el que habitualmente trabajamos.

 

http://papercut.codeplex.com/

Logo Cassandra

Cassandra 1.x y PHP para desarrolladores SQL: Clusters

2

Cassandra permite crear anillos o clusters de servidores de una forma muy sencilla, esto nos permitirá levantar nuevos servidores dentro de un cluster en cuestión de varios minutos.

 

Para ello tendremos que modificar la configuración de la BD.

En /etc/cassandra modificamos el archivo cassandra.yaml. Buscaremos la siguiente línea:

- seeds: "localhost"

Y sustituimos localhost por la ip local del servidor, en mi caso 192.168.1.10.

- seeds: "192.168.1.10"

A continuación modificamos las siguientes líneas:

listen_address: localhost

[...]

rpc_address: localhost

Por:

listen_address: 192.168.1.10

[...]

rpc_address: 192.168.1.10

Guardamos y reiniciamos el servidor.

Ahora el servidor con esta configuración será al que se conecten el resto de servidores del cluster.

Para el resto de servidores la configuración es parecida. En seeds mantenemos la ip del servidor principal y en listen_address y rpc_address ponemos la ip del servidor a unir al cluster:

- seeds: "192.168.1.10"

[...]

listen_address: 192.168.1.103

[...]

rpc_address: 192.168.1.103

Utilizo la ip 192.168.1.103 ya que es la que tengo configurada en mi cluster de prueba, tu deberías poner la ip correspondiente a la máquina donde estés configurando Cassandra.

Guardamos y reiniciamos la BD.

Esto es todo lo que hay que hacer para crear un cluster con Cassandra

Ir arriba