Developers

Copiando Archivos por SSH

Para esto usaremos el comando scp (secure copy), que es parte de la suite openssh. Para ser exactos scp usa ssh para la transferencia de datos, con las mejoras que eso conlleva, seguridad. Pero podrán decirme y rcp (remote file copy) pues este no solicita password alguno, o alguna manera de identificarnos, así que solo puede ser usado en una red de confianza, obviamente las prestaciones que nos brinda ssh, y por ende scp, opacan su labor, o mejor dicho, dependerá en que entorno poder usarlo sin riesgo.

Vale mencionar que al copiar un archivo [origen] en un archivo [destino] existente, scp reemplazará el contenido del archivo [destino] (manteniendo el inodo). Si todavía no existiera el archivo [destino], se crea un archivo vacío con el nombre de archivo [destino], luego se llena con el contenido del archivo fuente.

Formato

  • De maquina local a remota
scp «ruta_archivo_origen» user@host2:«ruta_archivo_destino»
  • De maquina remota a local
scp user@host2:«ruta_archivo_origen» «ruta_archivo_destino»

Hasta aquí todo bien para archivos pequeños, pero para grandes volúmenes de archivos, que mejor que hacerlo recursivamente (-r) y limitando (-l) el uso de ancho de banda en Kbit/s, y claro, porque no cifrarlo (-c) o mejor dicho, especificar el tipo.

scp -r «ruta_archivo_origen» user@host2:«ruta_archivo_destino» -l 20 

Súper sencillo no. Más información, visiten esta entrada sobre OpenSSH 🙂

Hasta aquí este post, buenas vibras lectores.

Anuncios

OpenPLC Project

Es el primer controlador lógico programable (PLC) totalmente opensource, citado en la web del proyecto, creado por «Thiago Rodrigues Alves», con la “simple” intención de ser un vinculo entre la industria automatizada y el hogar. Ampliando las opciones para las personas del mundo académico de todas las edades, para estudiar conceptos, crear nuevas tecnologías y compartir recursos. Inclusive apunta a ser una solución de bajo costo para proyectos de automatización pequeños e inclusive para la creación rápida de prototipos.

Este proyecto esta basado en el procesador ATMEga2860, ademas de tener la opción de poder ampliar sus funcionalidades I/O, colocando tarjetas de expansión, gracias a un BUS board, se pueden insertar estas tarjetas sucesivamente.

(más…)

I lov3 CLI : Editores (III)

Para finalizar la serie sobre editores: GNU Emacs, por muchos definido no como un editor si no como un “estilo de vida” ya que gracias a sus extensiones puede ser más que un todo terreno, calendario, email, planificador de proyectos, navegador web, cliente IRC y mucho más. Claro que esto implica una curva de aprendizaje alta, pero para los que logren llegar a la cima de esta empinada cumbre, pueden alcanzar el  Valhalla, Shangri-la (Shamballa) o Eden, de la iglesia de Emacs bendecidos por San iGNUcius, claro esta.

Por cierto los capítulos anteriores de la serie, nano y vim, en los links a continuación  I lov3 CLI : Editores (I) y I lov3 CLI : Editores (II).

(más…)

PULPino – microprocesador open-hardware

Es un sistema microcontrolador de código abierto, basado en un pequeño núcleo RISC-V(nueva arquitectura de conjunto de instrucciones – ISA, diseñado originalmente para apoyar la investigación y educación de la arquitectura computacional y ahora se convertirá en una arquitectura abierta para las implementaciones estándar de la industria, bajo la atenta mirada de la RISC-V Foundation) basado y optimizado de 32 bits desarrollado por la ETH Zurich y por la Universita di Bologna. El núcleo tiene un IPC cercano a 1, soporte completo para el conjunto de instrucciones de enteros de base (RV32I), instrucciones comprimido (RV32C) y el soporte parcial para la ampliación del conjunto de instrucciones de multiplicación (RV32M). Se implementa varias extensiones ISA como: bucles de hardware, el posterior incremento de carga y las instrucciones de almacenamiento, operaciones ALU y MAC, lo que permite que aumente la eficiencia del núcleo en aplicaciones de procesamiento de señales de baja potencia.

(más…)

Debian Project: CIA get out of here…!!

Lunar, uno de los desarrolladores principales de los ReproducibleBuils , que sirve para garantizar que los archivos binarios entregados por Debian en sus repositorios estén totalmente limpios de código malicioso, el encargado reproduce el paquete binario byte por byte, tremendo trabajito; ha insinuado un agujero de seguridad grande que afectaría a todo el software de código abierto, incluyendo a la mayoría de distros. Potencialmente expone al usuario a un escrutinio por parte de terceros, incluyendo a las agencias de seguridad [Hi!!!].
En otras palabras un paquete binario que vemos a diario en la mayoría de las distribuciones podría estar contaminado con código malicioso, por ello es ventajoso que una tercera persona verifique ello. Paranoico o no, nunca esta demás estar seguros que “ingerimos” tecnológicamente hablando. Por esto y más la FSF nos dice: Por qué no avalamos otros sistemas.
Que conste que el desarrollador no puede estar ni siquiera enterado que su compilador esta comprometido, y que de ahí estos “Men in the middle” salen a cuidarle las espaldas, al menos esto es lo que sucede en el proyecto Debian.

«CompilationScheme-Spanish». Publicado bajo la licencia CC BY-SA 3.0 vía Wikimedia Commons – https://commons.wikimedia.org/wiki/File:CompilationScheme-Spanish.png#/media/File:CompilationScheme-Spanish.png.
Luego de las filtraciones de Snowden revelaran que la CIA esta buscando maneras de explotar estas debilidades para instalar software espía en cualquier dispositivo actual de consumo a nivel mundial, pues las alarmas sonaron.
En una reciente conferencia organizada por la CIA, un equipo de desarrolladores presentaron una prueba de concepto. Habían conseguido eludir los certificados digitales de Apple para producir una versión corrupta de XCode, compilador de propiedad de Apple. Este compilador se utiliza para los desarrolladores independientes para aplicaciones de OS X y iOS. La versión corrupta incrusta spyware en cualquier aplicación compilada por el desarrollador sin su conocimiento. Si esto pasa en Apple, Linux es mucho más tentador, ya que muchos los usuarios estamos consientes de los riesgos existentes en plataformas comerciales (más allá de que nos gusten o no) y de las fuertes características de seguridad; este universo de usuarios también incluye a personas que los organismos de seguridad están muy interesados ​​en espiar. La única manera de estar seguro de que un binario ejecutable no incluye ningún código inesperado es compilar el código fuente y comparar los dos archivos. Si el archivo recién compilado no coincide con el binario ejecutable bajo prueba, podría haber algo añadido en el código, posiblemente malware.

« Lunar » El código fuente de la mayoría de los paquetes de Linux está escrito de una manera tal que no siempre se compila para producir archivos binarios idénticos.

Razones hay muchas para que esto suceda, por ejemplo, marcas de tiempo incrustadas en el código, números de compilación incrementales, diferencias entre los distintos sistemas de archivos por lo que un binario compilado en mi equipo es diferente de un compilado al tuyo. Rutas de archivos de la máquina de construcción están incrustados en el binario – equipos diferentes podrían almacenar recursos y código en diferentes lugares, etcétera.
Por ello que el trabajo que se hace en ReproducibleBuilds es titánico, pero tiene que hacerse, Debian cuenta con más de 20000 paquetes y la mayoría debe ser revisado. Un solo paquete infectado puede resultar en muchos equipos infectados. Aunque aún esta en fase experimental se esta haciendo muchos progresos pero falta mucho para que se integre a la distribución principal.

Hasta otro post y buenas vibras lectores.