Categoría: Administración

  • Una introducción a Logical Volume Management

    La mayoria de las distribuciones de Linux modernas soportan los dispositivos LVM durante la fase de instalación y la mayoría de estas distribuciones los configuran por nosotros de forma automática. En las instalaciones tradicionales, podemos ver una particición del tipo Linux, la cual se formatea con un sistema de ficheros y se monta en un directorio del sistema. Una instalación normal. Cuando usamos LVM, necesitamos asignar la partición a un tipo Linux LVM y entonces usar las herramientas apropiadas para crear y manejar estos dispositivos. GParted no soporta particiones LVM, necesitamos otras herramientas. Si usas openSUSE, hay una excelente herramienta de configuración de LVM como parte de YaST. Hay un módulo del kernel que se requiere así como unas herramientas en línea de comandos. Es necesario instalar dichas herramientas con nuestro sistema de paquetes. El ejemplo de abajo lo hace bajo Debian.

    # modprobe dm-mod ; apt-get install lvm2

    (más…)

  • Instalación de VirtualBox en Debian / Ubuntu

    vbox_logo2_gradientSimplemente tendremos que incluir la siguiente linea en el /etc/apt/sources.list.

    deb http://download.virtualbox.org/virtualbox/debian etch non-free

    Una vez incluida hacemos aptitude update para actualizar la lista de paquetes.

    Posíblemente tengamos un error porque no tenemos guardada una clave publica del repositorio. Para solucionarlo ejecutaremos:

    wget -q http://download.virtualbox.org/virtualbox/debian/sun_vbox.asc
    -O- | sudo apt-key add -
    aptitude update

    Y por último instalaremos el paquete virtualbox

    aptitude install virtualbox

    Y ya tenemos instalado en nuestro sistema Debian VirtualBox.

    Entrada recogida de José Manuel Ruiz

  • Proxy caché: squid

    Si tienes un servidor de ficheros (Samba), ftp, de impresión, Web, etc., y quieres aprovechar todavía mas tu hardware, le pueden añadir un servidor proxy caché: squid.

    Una aplicación común de los Servidores Intermediarios (Proxies) es funcionar como caché de contenido de Red (principalmente HTTP), proporcionando en la proximidad de los clientes un caché de páginas y ficheros disponibles a través de la Red en servidores HTTP remotos, permitiendo a los clientes de la red local acceder hacia éstos de forma más rápida y confiable.

    La configuración inicial para que tu squid funcione como caché de páginas no difiere mucho de la configuración inicial con la que se instala por defecto squid.

    Instalación de squid

    Para nuestro ubuntu server bastará:

    #apt-get install squid

    Configuración básica

    Varios parámetros influyen en la configuración básica de squid.

    Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su editor de texto simple preferido. Existen un gran número de parámetros, de los cuales recomendamos configurar los siguientes:

    http_port
    cache_dir
    Al menos una Lista de Control de Acceso
    Al menos una Regla de Control de Acceso

    El puerto en el que escucha squid se especifica en el parámetro:

    #
    #    You may specify multiple socket addresses on multiple lines.
    #
    # Default: http_port 3128
    http_port 3128

    Controles de acceso.

    Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas máquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid. Procedamos a entender como definir unas y otras.

    Listas de control de acceso.

    Regularmente una lista de control de acceso se establece con la siguiente sintaxis:

    acl [nombre de la lista] src [lo que compone a la lista]

    Si se desea establecer una lista de control de acceso que abarque a toda la red local, basta definir la IP correspondiente a la red y la máscara de la sub-red. Por ejemplo, si se tiene una red donde las máquinas tienen direcciones IP 192.168.1.n con máscara de sub-red 255.255.255.0, podemos utilizar lo siguiente:

    acl miredlocal src 192.168.1.0/255.255.255.0

    También puede definirse una Lista de Control de Acceso especificando un fichero localizado en cualquier parte del disco duro, y la cual contiene una lista de direcciones IP. Ejemplo:

    acl permitidos src "/etc/squid/permitidos"

    El fichero /etc/squid/permitidos contendría algo como siguiente:

    192.168.1.1
    192.168.1.2
    192.168.1.3
    192.168.1.15
    192.168.1.16
    192.168.1.20
    192.168.1.40

    Lo anterior estaría definiendo que la Lista de Control de Acceso denominada permitidos estaría compuesta por las direcciones IP incluidas en el fichero /etc/squid/permitidos.

    Reglas de Control de Acceso.

    Estas definen si se permite o no el acceso hacia Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda:

    #
    # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
    #

    La sintaxis básica es la siguiente:

    http_access [deny o allow] [lista de control de acceso]

    En el siguiente ejemplo consideramos una regla que establece acceso permitido a Squid a la Lista de Control de Acceso denominada permitidos:

    http_access allow permitidos

    También pueden definirse reglas valiéndose de la expresión !, la cual significa no. Pueden definirse, por ejemplo, dos listas de control de acceso, una denominada lista1 y otra denominada lista2, en la misma regla de control de acceso, en donde se asigna una expresión a una de estas. La siguiente establece que se permite el acceso a Squid a lo que comprenda lista1 excepto aquello que comprenda lista2:

    http_access allow lista1 !lista2

    Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe denegar el acceso.

    Aplicando Listas y Reglas de control de acceso.

    Una vez comprendido el funcionamiento de la Listas y las Regla de Control de Acceso, procederemos a determinar cuales utilizar para nuestra configuración.

    Caso 1.

    Considerando como ejemplo que se dispone de una red 192.168.1.0/255.255.255.0, si se desea definir toda la red local, utilizaremos la siguiente línea en la sección de Listas de Control de Acceso:

    acl todalared src 192.168.1.0/255.255.255.0

    Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:

    Listas de Control de Acceso: definición de una red local completa

    #
    # Recommended minimum configuration:
    acl all src 0.0.0.0/0.0.0.0
    acl manager proto cache_object
    acl localhost src 127.0.0.1/255.255.255.255
    acl todalared src 192.168.1.0/255.255.255.0

    A continuación procedemos a aplicar la regla de control de acceso:

    http_access allow todalared

    Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:

    Reglas de control de acceso: Acceso a una Lista de Control de Acceso.

    #
    # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
    #
    http_access allow localhost
    http_access allow todalared
    http_access deny all

    La regla http_access allow todalared permite el acceso a Squid a la Lista de Control de Acceso denominada todalared, la cual está conformada por 192.168.1.0/255.255.255.0. Esto significa que cualquier máquina desde 192.168.1.1 hasta 192.168.1.254 podrá acceder a Squid.

    Caso 2.

    Si solo se desea permitir el acceso a Squid a ciertas direcciones IP de la red local, deberemos crear un fichero que contenga dicha lista. Genere el fichero /etc/squid/listas/redlocal, dentro del cual se incluirán solo aquellas direcciones IP que desea confirmen la Lista de Control de acceso. Ejemplo:

    192.168.1.1
    192.168.1.2
    192.168.1.3
    192.168.1.15
    192.168.1.16
    192.168.1.20
    192.168.1.40

    Denominaremos a esta lista de control de acceso como redlocal:

    acl redlocal src "/etc/squid/listas/redlocal"

    Habiendo hecho lo anterior, la sección de listas de control de acceso debe quedar más o menos del siguiente modo:

    Listas de Control de Acceso: definición de una red local completa

    #
    # Recommended minimum configuration:
    acl all src 0.0.0.0/0.0.0.0
    acl manager proto cache_object
    acl localhost src 127.0.0.1/255.255.255.255
    acl redlocal src "/etc/squid/listas/redlocal"

    A continuación procedemos a aplicar la regla de control de acceso:

    http_access allow redlocal

    Habiendo hecho lo anterior, la zona de reglas de control de acceso debería quedar más o menos de este modo:

    Reglas de control de acceso: Acceso a una Lista de Control de Acceso.

    #
    # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
    #
    http_access allow localhost
    http_access allow redlocal
    http_access deny all

    La regla http_access allow redlocal permite el acceso a Squid a la Lista de Control de Acceso denominada redlocal, la cual está conformada por las direcciones IP especificadas en el fichero /etc/squid/listas/redlocal. Esto significa que cualquier máquina no incluida en /etc/squid/listas/redlocal no tendrá acceso a Squid.

    En un momento dado se requerirá tener salida transparente hacia Internet para ciertos servicios, pero al mismo tiempo se necesitará re-direccionar peticiones hacia servicio HTTP para pasar a través del el puerto donde escucha peticiones Squid (8080), de modo que no haya salida alguna hacia alguna hacia servidores HTTP en el exterior sin que ésta pase antes por Squid. No se puede hacer Servidor Intermediario (Proxy) Transparente para los protocolos HTTPS, FTP, GOPHER ni WAIS, por lo que dichos protocolos tendrán que ser filtrados a través del NAT.

    Re-direccionamiento de peticiones a través de la opción REDIRECT en Shorewall.

    La acción REDIRECT en Shorewall permite redirigir peticiones hacia protocolo HTTP para hacerlas pasar a través de Squid. En el siguiente ejemplo las peticiones hechas desde la zona que corresponde a la red local serán redirigidas hacia el puerto 8080 del cortafuegos, en donde está configurado Squid configurado como Servidores Intermediario (Proxy) transparente.

    #ACTION		SOURCE		DEST	PROTO	DEST
    REDIRECT	loc		8080	tcp	80

    Si no usamos el proxy transparente anterior y tenemos un cortafuegos montado en el servidor, debemos habilitar este para que nuestros ordenadores de la red local accedan a este proxy en el puerto 3128.

    Mas información en Linux para Todos

  • Configurar los niveles de ejecución en Ubuntu o Debian

    P. Bajo Red Hat o Cent OS el comando chkconfig provee una herramienta simple para el mantenimiento de la jerarquía del directorio /etc/rc[0-6].d facilitándole al administrador la tarea de manipular directamente los numerosos links simbólicos que aparecen en estos directorios. ¿Cómo puedo controlar o mantener el arranque/parada de los servicios de mi Ubuntu (o Debian) desde la línea de comandos?

    R. chkconfig es el comando para Redhat y similares. Debian o Ubuntu Linux ofrece un comando distinto para la misma tarea.

    Tarea: Línea de comandos para manejar servicios / Ubuntu runlevel

    El comando update-rc.d automaticamente actualiza los links del Systema V situados en el directorio /etc/rcrunlevel.d/NNname a scripts /etc/init.d/name. Estos scripts se ejecutan por el sistema init cuando cambian los niveles de ejecución y generalmente se usan para comenzar o parar estos servicios. Por ejemplo, para activar el servicio ssh desde el terminal hay que teclear:
    # update-rc.d ssh defaults

    O

    $ sudo update-rc.d ssh defaults

    Tarea: Eliminar un servicio

    De nuevo hay que usar el comando update-rc.d:
    # update-rc.d SERVICE-NAME remove

    O

    $ sudo update-rc.d SERVICE-NAME remove

    Tarea: Usar un GUI basado en texto como herramienta de configuración de Runlevel para añadir o eliminar servicios

    rcconf es la herramiento de configuración de los niveles de ejecución que estamos buscando. Rcconf te permite controlar qué servicios están iniciados cuando el sistema arranca o se reinicia. RcConf muestra un menú de todos los servicios que deberían estar iniciados en el arranque de la máquina.  Los que están configurados para arrancar estan marcados y puedes cambiarlos individualmente para que arranquen o no lo hagan. Si rcconf no está instalado en tu sistema, usa el comando apt-get siguiente:
    # apt-get install rcconf

    O

    $ sudo apt-get install rcconf

    Ahora ejecuta rcconf y sigue las instrucciones que te aparecerán en pantalla:
    # rcconf

    Link original en inglés: cyberciti.biz

  • Debian / Ubuntu tasksel: Instalar grupos de software (tasks) tales como DNS / Web Server en un simple click

    lt;a href=»http://www.quantcast.com/p-25K88fxDSEn9Y» target=»_blank»><img src=»http://pixel.quantserve.com/pixel/p-25K88fxDSEn9Y.gif» style=»display: none;» border=»0″ height=»1″ width=»1″ alt=»Quantcast»/></a>

    debianlogoEstoy buscando un comando comoyum groupinstall group‘ para mi Ubuntu. ¿Cómo instalo un grupo de software como DNS o LAMP con un simple comando?

    Necesitamos una comando como tasksel. Este comando una parte integral del instalador de Debian y también está disponible para Ubuntu. Agrupa varios paquetes por tareas y ofrece al usuario un camino fácil para instalar los paquetes para esta tarea. Provee la misma funcionalidad que los convencionales metapaquetes.

    ¿Cómo usar tasksel?

    tasksel se ha incluído como parte de la instalación base bajo Debian y Ubuntu . tasksel muestra todas la taread y permite al usuario seleccionar las que desee para instalarlas. Simplemente escriba tasksel como usuario root en un terminal:
    $ sudo tasksel
    O
    # tasksel
    Deberías ver el siguiente menú de selección:

    debian-tasksel-command

    Fig.01: comando tasksel en acción

    Puedes seleccionar el grupo requerido pulsando la barra espaciadora y seleccionando el botón OK. (más…)

  • Análisis del ancho de banda

    linux-logoSurfeando por la web conocí la página de vicente navarro que como vereis tiene una filosofía verdaderamente interesante en su forma de postear.

    Resumo aquí brevemente un artículo sobre el análisis del ancho de banda no solamente de internet sino también de una red local. El artículo original está aquí.

    La situación pasa por querer medir la transferencia entre dos ordenadores a través de la red (local o internet). El paquete utilizado es iperf. A través de una apt-get install iperf, cualquier versión de ubuntu lo instalará. La ventaja de este paquete es que hace por sí mismo una transferencia entre los ordenadores implicados de tal manera que no es necesario hacer una transferencia con cualquier otro programa para el test.

    En uno de los ordenadores pondremos:

    debian $ iperf -s
    ------------------------------------------------------------
    Server listening on TCP port 5001
    TCP window size: 85.3 KByte (default)
    ------------------------------------------------------------
    [  4] local 192.168.69.69 port 5001 connected with 192.168.69.33 port 53490

    Esto no dejará este ordenador en modo espera en el puerto por defecto 5001.

    En el otro ordenador será:

    ubuntu $ iperf -c debian
    ------------------------------------------------------------
    Client connecting to debian, TCP port 5001
    TCP window size: 16.0 KByte (default)
    ------------------------------------------------------------
    [  3] local 192.168.69.33 port 53490 connected with 192.168.69.69 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.1 sec    116 MBytes  96.3 Mbits/sec
    [  4]  0.0-10.3 sec    116 MBytes  94.1 Mbits/sec

    De esta manera podemos comprobar la transferencia entre ambos sin utilizar ningún software adicional.

    Este comando admite la opción -p xxxx donde xxxx es el puerto a utilizar.

  • rdiff-web

    Este programa surge de la necesidad de usar rdiff-backup. Recordemos que rdiff-backup es un programa para hacer copias de seguridad que permite las copias incrementales. Pero ahora bien, una vez hechas las copias incrementales, ¿cómo accedemos a ellas para una restauración? Rdiff-backup permite hacerlo en modo comando (consola) pero rdiff-web nos permite hacerlo desde un interfaz web muy sencillo y cómodo.

    La información aquí expuesta está extraida de su wiki.

    Installation

    Prerequisites

    Install CherryPy 3.0 for the testing version, or 2.x for the stable version.

    Install rdiffWeb

    $ tar zxf rdiffWeb-0.6.0.tar.gz
    $ cd rdiffWeb-0.6.0
    $ python setup.py build
    $ sudo python setup.py install

    Configure rdiffWeb

    rdiffWeb can either be configured from the command line, or via a web interface.

    Command Line

    $ rdiff-web-config

    Web Interface

    Just open a web browser to http://localhost:8080
    This creates a basic configuration in /etc/rdiffweb/rdw.conf, that can be tweaked.

    Start rdiffWeb

    $ /etc/init.d/rdiff-web start

    Automatically start rdiffWeb on system startup

    If we start the server/machine in graphic mode then we are probably using runlevel 5:
    ln -s /etc/init.d/rdiff-web /etc/rc5.d/S50rdiff-web

  • ssh desatendido (clave dsa) (II)

    Buscando soluciones para hacer copias de seguridad con rdiff-backup (que utiliza ssh) tuve que buscar una solución para acceder al servidor de copias con ssh sin que preguntara todas las veces la contraseña.

    Hay varias soluciones. La primera probada con éxito la conseguí de esta web:

    Desde el ordenador que va a conectar al otro y con el usuario que conectará ponemos:

    ssh-keygen -t dsa -f ~/.ssh/id_dsa -N ''

    Esto nos va a generar un conjunto de pares de clave pública y clave privada.

    Ahora y desde el mismo ordenador:

    cat ~/.ssh/id_dsa.pub | ssh x_usuario@ip_servidor_ssh ' cat - >> ~/.ssh/authorized_keys'

    donde x_usuario es el usuario que conectará con el ordenador remoto y ip_servidor_ssh es el propio ordenador remoto.

    Después de esto podemos probar con un simple ssh al ordenador destino que ya no nos pedirá claves.

    En mi caso me ocurrió que el ordenador remoto no tenía el directorio .ssh creado. Lo creé y el fichero autorized_keys se creó solo. Este comando lo que hace es añadir la clave pública del ordenador cliente al fichero de claves autorizadas del ordenador destino.

  • Herramienta de backup definitiva hasta ahora.

    Desde hace mucho tiempo he ido buscando una herramienta de backup simple pero que a su vez cubriera mis necesidades:

    1. Debería hacer copias locales y remotas rapidamente y de forma segura.

    2. de linux o windows.

    3. Restauración de ficheros individuales de forma fácil.

    Hasta el momento la herramienta que he usado ha sido rsync pero siempre he sentido el gusanillo de usar otra herramienta para mí mas potente: rdiff-backup.

    rdiff-backup tiene la característica fundamental que hace copias incrementales en su funcionamiento básico, es decir, la primera vez que se usa hace un mirror del directorio pero la segunda y posteriores solo hace una copia de los ficheros añadidos o cambiados pero de forma trasparente. Tendremos pues un clon de Time Machine del Macos pero en modo consola para nuestros linux.

    El problema que siempre ví en este proceso era que no había una forma de navegar por los distintos backups que, recordemos tienen fecha variadas, para recuperar un fichero o directorio a una fecha concreta. Pues bien he descubierto rdiff-web que no es mas que un front-end o gui para que esta labor de recuperación sea mucho más amigable.

    En sucesivas entradas explicaré el uso de rdiff-backup básico (tal como yo lo uso), la forma de usar el rdiff-backup de forma desatendida (recordemos que este script usa ssh y por tanto nos pide usuario y contraseña) y para terminar la serie, cómo instalé rdiff-web en un ubuntu server.

  • Entrar por ssh desatendido (clave rsa).

    Una característica importante de las conexiones ssh es la seguridad. Pero también es cierto que para hacer ssh desatendidos a un servidor ssh es muy molesto tener que teclear las claves del usuario y la contraseña. Siguiendo este tutorial conseguimos que el terminal ssh se dé a conocer al servidor ssh de forma definitiva.

    Tenemos que generar una pareja de claves publica y privada, para despues añadir la clave pública en el fichero ~/.ssh/authorized_keys de la cuenta que se encuentra máquina a la que queremos acceder.

    1. Generar las claves

    miguel@terminal:~$ ssh-keygen -t rsa -b 1024

    Con esto se generará en ~/.ssh/ dos ficheros, id_rsa(clave privada) y id_rsa.pub(clave pública)

    2. Copiar la clave pública en la cuenta de la máquina que queremos acceder.

    miguel@terminal:~$ssh miguel@servidor «cat >>~/.ssh/authorized_keys» <~/.ssh/id_rsa.pub

    3. Realizar un ssh

    miguel@terminal:~$ ssh miguel@servidor

    si todo ha ido bien, habrás accedido a la máquina remoto si que te pida el password.

    Este proceso lo he cogido de este post de BULMA.