25 de octubre de 2016

#CCNA 5.0 Nivel 1 Capítulo 2

Buenas tardes,

Aquí os traigo apuntes del curso CCNA 5.0 en español del nivel 1 continuando con el capítulo 2. Para que puedan disfrutarlos e ir más directo a las cosas importantes. Este capítulo suele tener muchos ejemplos, pero sobre todo contienen muchos comandos.

Este es el resumen de este capítulo
  • Explicar que tipo de SO tienen la mayoría de dispositivos Cisco
  • Como configurar dicho SO incluyendo nombre de dispositivo, mensaje del día...
  • Explicar cómo se comunican los dispositivos mediante red
  • Obtener una tabla con los diferentes tipos de modos de acceso jerárquico dentro de IOS
  • Conjunto de combinaciones de teclas para facilitar el trabajo en entornos CLI
Para descargarlo, tenéis acceso a dos repositorios de git llamados #ptlabs. Tengo un archivo CHANGELOG que registra todos los cambios del repositorio, es decir, si hay alguna modificación de alguna errata, información extra...etc queda registrado en él.

También dispongo de un fichero CHECKSUM para que puedan ustedes comprobar la integridad del archivo en caso de que se os haya descargado mal, saberlo fehacientemente.
Recuerden que si queréis practicar con el software Packet Tracer y no os arranca el programa, pueden optar por utilizar mi script válido para openSUSE Leap, Debian, Fedora y Gentoo.

9 de agosto de 2016

RPM, gestor y formato de paquetes #LPIC

Como ya hemos hablado anteriormente sobre qué es un gestor de paquetes no nos meteremos mucho en ello en la presente entrada.

Hoy vamos ha hablar del gestor de paquetes RPM para comprender uno de los capítulos fundamentales de la LPIC, además de, que, si se utiliza una distribución con formato de paquetes .rpm, saber afrontarlo con menor problema y mayor desenvoltura con el siguiente post.

Historia y antecedentes


Los orígenes del gestor de paquetes RPM (Red hat Package Manager) se remonta en el año 1997. Cuando Marc Ewing, Erik Troan y el resto de desarrolladores de Red Hat lo sacaron como mejora de los gestores de paquetes que existían en aquella época como es el caso de: PMS (Package Management System) desarrollado por Rik Faith, Doug Hoffman y Kevin Martin para su distribución llamada BOGUS en el año 1993; o RPP (Red Hat Software Program Packages) que vio la luz en 1994 en las primeras distribuciones beta de las versión Red Hat Commercial Linux (RCL) y por último, en 1994 también, Ian Murdock fundador de la distribución Debian GNU/Linux, saca a la luz DPKG.

4 de agosto de 2016

Mantenimiento de software en Linux #LPIC alert

Hoy en día, la forma en la que se desarrolla y se distribuye el software ha aumentado y cambiado tanto que alcanza ritmos realmente vertiginosos. Esto ha supuesto una modernización en cuanto al mantenimiento del mismo en todas las distribuciones de GNU/Linux y otros sistemas UNIX-like tipo FreeBSD.

Si antiguamente, para instalar un software, teníamos o bien que tener el código fuente y someterlo a un proceso de compilación el cuál, había que esperar a que saliera bien para añadirlo a nuestro sistema; o bien teníamos que tener el software ya previamente pre-compilado, adherirlo al sistema y esperar a que también funcionase.

Todo esto ha conllevado a que se desarrollen mecanismos que permitan gestionar ese software de una forma más cómoda y rápida. Sin tener que estar pasando por tanto make install clean. Este tipo de situaciones a menudo incómodas se ha podido solventar gracias a la llegada de los gestores de paquetes.

El gestor de paquetes, es un programa o un conjunto de herramientas que permiten el mantenimiento y gestión del software que se encuentre en nuestro sistema, apoyado por una base de datos permite obtener resultados de nuestro software instalado en poco tiempo, además de poder exportarla por si existen problemas en un futuro. También posibilita la instalación de software adicional.

El software no se encuentra en un comprimido con código fuente listo para compilar, el software se encuentra en un archivo comprimido con una extensión específica, la cuál identifica que sistema de paquetes está utilizando como es el caso de .deb o .rpm. Dentro de ellos, se encuentran los binarios listos para utilizarse además de información adicional como un historial de cambios, descripciones, scripts... a este archivo comprimido se le denominan paquetes de software.

Gracias a estos gestores podemos trabajar con los paquetes y mantener así una mayor integridad en todo el sistema al registrar todos los programas, scripts... que instalemos. Con la vieja forma, no sabemos que tenemos instalado a menos que indaguemos o efectuemos la instalación de forma manual y nos acordemos.

Sin embargo, los gestores de paquetes que se desarrollaron en un principio como es el caso de dpkg por parte de la rama de Debian, ó rpm por parte del mundo de Red Hat. No facilitaban tareas como la resolución de dependencias, algo clave y muy sustancial. Porque esto ahorra hasta un 99% cuando se pretendía instalar multitud de paquetes que requerían de dependencias que no estuvieran instaladas en el sistema.

Para ello se elaboraron los gestores de paquetes de alto nivel. Éstos permiten una flexibilidad enorme y le sacan el potencial oculto a los gestores de paquetes de bajo nivel como es el caso de rpm y dpkg. Permiten buscar dependencias de cualquier paquete que se desee instalar, siempre y cuando los encuentre en los servidores que distribuyan los paquetes, los cuáles reciben el nombre de repositorios.

Entre otras cosas también permite buscar fácilmente paquetes instalados o disponibles en dichos repositorios, y la posibilidad de exportar las bases de datos con las que suelen trabajar para generar copias de seguridad de los mismos y generar puntos de retorno para usar rollbacks (vuelta de estado anterior de la DB), entre muchas más cosas.

En los próximos artículos, iré explicando el uso de los 2 gestores de bajo nivel como es el caso de dpkg y rpm además de los gestores de alto nivel como la suite APT y aptitude; o YUM y DNF.

Licencia y responsabilidades

Licencia Creative Commons
netSys blog por Álvaro Castillo se encuentra bajo una Licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.

El propietario de este blog no se responsabiliza de los daños que puedan generarse u ocurrir por la información expuesta aquí, en caso de ser utilizada la responsabilidad recae bajo quién la use.

Se les informa de posibles publicaciones donde queden expuestas imágenes a terceros o marcas comerciales que siempre tendrán sus fuentes, y sus atribuciones.

Por último, en caso de confusión por la temática que se trate de los artículos, tutoriales...etc dejaremos claro que este sitio Web no colabora directamente con ningún proyecto de forma oficial.