Notas y recetas informáticas

Blog

  • Cómo decirle a Eclipse que el código es C++11

    En un proyecto C++ con Makefile, Eclipse no reconocía la parte de la librería estándar correspondiente a C++11.

    Abriendo el fichero /usr/include/c++/4.8.2/mutex se comprueba que el problema es el valor definido para __cplusplus que Eclipse proporciona al analizador del código.

    Para hacer que Eclipse le diga a su analizador que el código es C++11 hay que hacerlo en la configuración de rutas y macros del preprocesador (Project->Properties->C/C++ General->Preprocessor Include Paths, Macros, etc.: Pestaña «Providers»). Allí hay que añadir el parámetro -std=c++11 al comando utilizado para obtener las características del compilador.

    Una vez añadido, el valor de __cplusplus será 201103L, con lo que se activarán los includes de la librería estándar correspondientes a C++11.

    Edición 5 de enero de 2018:

    En los proyectos C++ con Makefile generado por Eclipse también es necesario indicar la versión C++ si esta no es ISO C++98. Si utilizamos código C++11 sin haber configurado el proyecto Eclipse para soportar esta versión nos dará el correspondiente error en la compilación:

    Para indicarle en esta ocasión al compilador (en el otro caso se indicaba explícitamente en el Makefile) que el código es ISO C++11 se debe acceder a la configuración de las herramientas de construcción del binario (Project -> Properties -> C/C++ Build ->Settings: Pestaña «Tool Settings»). Allí, hay una entrada para seleccionar el «dialecto» que debe entender el compilador, donde habrá que seleccionar ISO C++11 (-std=c++0x) o el que corresponda.

    Referencias:
    C++11 standard library indexing fails, __cplusplus recognized with wrong value

  • El extraño caso del bonding medio sordo

    Una técnica muy utilizada para proporcionar mayor disponibilidad y capacidad a la conexión entre dos equipos consiste en utilizar simultáneamente varios enlaces físicos entre ambos, formando un grupo de agregación de enlaces o LAG (Link Aggregation Group). LAG considero que es el término más correcto, aunque también son conocidos como port channel en el mundo de las redes o bonding en el mundo GNU/Linux. También, aunque de forma incorrecta en mi opinión, se les llama a veces trunk (de una tecnología propietaria llamada port trunking), esto a mí me resulta ambiguo, porque el uso más generalizado del término es para referrirse a un puerto de un switch por el que se permite tráfico de varias VLAN.

    El caso es que para proporcionar mayor ancho de banda a un nuevo servidor de ficheros se quiere establecer un LAG entre este y el correspondiente conmutador (bonito término castellano para un switch). Esto, en principio, es bastante sencillo, sobre todo teniendo en cuenta que el servidor corre un Red Hat Enterprise Linux 7.3 (suficientemente moderno, su núcleo es la versión 3.10 de Linux) y el switch es un Cisco que ha costado más de lo que amortizo de hipoteca en un año.

    Para establecer el LAG entre el servidor y el switch se va a utilizar el protocolo LACP (Link Aggregation Control Protocol), soportado por ambos.

    El switch se configura creando un nuevo interfaz del tipo PortChannel, que será un interfaz virtual que representa al grupo de agregación, y añadiendo los interfaces físicos a utilizar a dicho grupo.

    Aquí llamaremos al port channel port-channel1 (Po1 para los amigos) y añadiremos a su grupo los interfaces Ethernet1/1 al Ethernet1/4.

    interface Po1

interface Eth1/1 - 4
  channel-group 1

    Con esto es suficiente, ya que aunque hay varias formas de establecer el LAG, el modelo de switch utilizado usa el protocolo LACP por defecto. Como se verá más adelante, suponer que LACP era utilizado por defecto fue la causa del problema.

    En el servidor se hace de forma similar creando un ficheo de configuración para el bonding que llamaremos bond0 y cambiando la configuración de los interfaces físicos a añadir al LAG.

    /etc/sysconfig/network-scripts/ifcfg-bond0:

    TYPE=Bond
BOOTPROTO=none
NAME=bond0
DEVICE=bond0
ONBOOT=yes
BONDING_MASTER=yes
IPADDR=192.168.10.10
GATEWAY=192.168.10.1
PREFIX=24
BONDING_OPTS="mode=4 miimon=100 lacp_rate=1"

    Aquí es necesario indicar el modo del bonding, ya que soporta varios tipos de funcionamiento, el modo 4 utilizado es el que corresponde al protocolo 802.3ad, es decir LACP. El parámetro miimon indica cada cuantos milisegundos se debe comprobar si un interfaz del bonding tiene enlace, si se detecta que no tiene enlace será extraído del LAG inmediatamente. El parámetro lacp_rate indica cada cuantos segundos se envía un paquete de control de LACP (LACPDU).

    Los interfaces miembro del LAG se configuran así:

    /etc/sysconfig/network-scripts/ifcfg-eth0

    TYPE=Ethernet
BOOTPROTO=none
NAME=eth0
DEVICE=eth0
ONBOOT=yes
MASTER=bond0
SLAVE=yes

    Una vez configurados los interfaces del servidor (habrá que reiniciar los servicios de red) y el switch se debe establecer el LAG entre ambos.

    Para ver el estado del interfaz bond0 se puede consultar el fichero /proc/net/bonding/bond0, aunque también podemos obtener suficiente información con un simple listado de los interfaces:

    #ip link
...
8: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
9: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
10: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
...

    Aquí se ve que hay dos interfaces eth0 y eth1 en modo SLAVE (parte de un bonding) y que hay un interfaz en modo MASTER (el bonding), todos están UP (tienen enlace) y todos tienen la misma MAC (como debe ser), ya que todos los interfaces físicos actúan «en representación» del interfaz de bonding.

    En el switch también parece estar todo bien:

    #sh int Po1
port-channel1 is up
admin state is up,
  Hardware: Port-Channel, address: a4bd.c6db.aac9 (bia a4bd.c6db.aac9)
  MTU 1500 bytes, BW 20000000 Kbit, DLY 10 usec
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, medium is broadcast
  Port mode is access
  full-duplex, 10 Gb/s
  Input flow-control is off, output flow-control is off
  Auto-mdix is turned off
  Switchport monitor is off
  EtherType is 0x8100
  Members in this channel: Eth1/1, Eth1/2, Eth1/3, Eth1/4
  Last clearing of "show interface" counters never
  1 interface resets
  30 seconds input rate 2328 bits/sec, 1 packets/sec
  30 seconds output rate 2520 bits/sec, 1 packets/sec
  Load-Interval #2: 5 minute (300 seconds)
    input rate 12.83 Mbps, 1.02 Kpps; output rate 139.13 Kbps, 181 pps
  RX
    2705286 unicast packets  3316 multicast packets  3932 broadcast packets
    2712534 input packets  3986560464 bytes
    0 jumbo packets  0 storm suppression packets
    0 runts  0 giants  0 CRC  0 no buffer
    0 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  0 input discard
    0 Rx pause
  TX
    510610 unicast packets  29736 multicast packets  3699 broadcast packets
    544045 output packets  53042671 bytes
    0 jumbo packets
    0 output error  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble  0 output discard
    0 Tx pause

    En esta información lo importante es que el port channel está UP y que el ancho de banda del mismo es 20.000.000 Kbit. El ancho de banda indica que hay dos puertos, de los cuatro que son miembros del port channel, que están conectados (se trata de puertos de 10 Gbps).

    Viendo esto todo parece estar bien, sin embargo, al hacer un ping a otro equipo que se envía por dicho interfaz resulta que no hay respuesta:

    # ping 192.168.10.20
PING 192.168.10.20 (192.168.10.10) 56(84) bytes of data.
From 192.168.10.10 icmp_seq=1 Destination Host Unreachable
From 192.168.10.10 icmp_seq=2 Destination Host Unreachable

    Habrá que investigar, para ello lo primero comprobar qué pasa por el interfaz bond0:

    # tcpdump -nn -i bond0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:59:12.717212 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28
11:59:13.719184 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28

    Y así sucesivamente, es decir, los ARP no obtienen respuesta, pero eso ¿por qué? Indaguemos un poco más y veamos el tráfico en cada interfaz:

    # tcpdump -nn -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:01:53.985192 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28
12:01:54.987189 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28

    Vale, el bond0 está utilizando el interfaz eth0 para envíar las consultas ARP y no obtiene respuesta. Veamos entonces si hay algo extraño en el eth1:

    # tcpdump -nn -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:03:21.343287 ARP, Reply 192.168.10.20 is-at a0:d6:cf:d0:32:b0, length 46
12:03:22.940519 ARP, Reply 192.168.10.20 is-at a0:b6:cf:d0:32:b0, length 46

    Bueno, no es muy extraño, la política de reparto de carga entre los enlaces no es la misma en el switch que en el servidor, por lo que el servidor envía una consulta ARP por un interfaz y la recibe por el otro. A mí me parece normal.

    Entonces, ¿por qué no pasan las respuetas ARP del interfaz eth1 al bond0? Pues porque el bonding está medio sordo. Pero, ¿por qué está medio sordo el bonding?

    Comienza la investigación por el Interné: Google, a ver qué encuentras sobre esto: «Linux bonding medio sordo». Pero parece que nadie ha escrito aún sobre esto, bueno a ver en inglés: «Linux bonding half deaf». Tampoco.

    En fin, toca leer la documentación del módulo de bonding y relacionada. Así, que tras no encontrar nada muy claro y buscar de todo relacionado con el bonding y 802.3ad dí con el artículo que me dio la clave (aunque trataba de otro problema): [Linux Bonding] 802.3ad bond interface has shown RX dropped packets.

    En ese artículo hablaba de que el bonding, de manera premeditada y (en otros casos, desde luego) correcta, descartaba los paquetes recibidos por los interfaces no activos del bonding. Esto está muy bien cuando el modo del bonding es tal que unos interfaces están activos y otros no, que no es el caso del modo 4, 802.3ad o LACP.

    Lo importante es que daba la clave de como evitar eso, el parámetro all_slaves_active. Así, estableciendo ese parámetro a uno se puede hacer un apaño y permitir que los paquetes recibidos por el interfaz eth1 sean admitidos y lleguen como recibidos por el interfaz bond0.

    # echo 1 > /sys/class/net/bond0/bonding/all_slaves_active

    Pero, como he dicho, eso es solo un apaño, ya que el problema de fondo aún está ahí. ¿Y cuál es ese problema? Pues que el bond0 no considera activo el interfaz eth1, pasa de él, como se deduce de lo siguiente:

    # ethtool bond0
Settings for bond0:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

    El ancho de banda del interfaz es 10.000Mbps, es decir, lo que da un interfaz. Si estuviera utilizando los dos sería 20.000Mbps, como se vió en el estado del LAG en el lado del switch.

    Por tanto el switch ha activado ambos enlaces del LAG (como se ve al recibir tráfico por los dos interfaces en el servidor), pero el servidor solo ha activado uno.

    Mirando el detalle del estado del bonding se ve lo siguiente:

    # cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: a0:b6:cf:d0:2d:f8
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 1
        Actor Key: 13
        Partner Key: 1
        Partner Mac Address: 00:00:00:00:00:00

Slave Interface: eth0
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: a0:b6:cf:d0:2d:f8
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: churned
Actor Churned Count: 0
Partner Churned Count: 1
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 1
    port state: 77
details partner lacp pdu:
    system priority: 65535
    system mac address: 00:00:00:00:00:00
    oper key: 1
    port priority: 255
    port number: 1
    port state: 1

Slave Interface: eth1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: a0:b6:cf:d0:2d:fa
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: churned
Partner Churn State: churned
Actor Churned Count: 1
Partner Churned Count: 1
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 2
    port state: 69
details partner lacp pdu:
    system priority: 65535
    system mac address: 00:00:00:00:00:00
    oper key: 1
    port priority: 255
    port number: 1
    port state: 1

    Una mente avezada no hubiera pasado por alto (al contrario de como hice yo inicialmente) la discordancia en los «Aggregator ID» de ambos interfaces miembros del bonding. Estaba empeñado en que la culpa era de la configuración del bonding pero, preguntándole a Google por qué puede haber diferentes aggregator ID, me dice un par de cosas. En StackExchange ya me confirman algo que no terminaba de interpretar correctamente en la documentación del bonding, y es que los diferentes aggregator ID están destinados a hacer grupos de interfaces separados dentro del bonding, utilizando solo uno de ellos. Esto me hace pensar que, tal vez, el switch esté haciendo algo mal.

    La confirmación de esto la tuve en esta entrada del foro de CentOS, Only 1 NIC used in the bond, ahí se apuntaba a una entrada de un blog en la que se trataba otro síntoma, la MAC 00:00:00:00:00:00 del otro extremo. En esta entrada se remarca en negrita que lo que hay que hacer es comprobar que el port channel está en modo activo (LACP). Así que fui a hacer la comprobación:

    # show port-channel database
port-channel1
    Last membership update is successful
    4 ports in total, 2 ports up
    First operational port is Ethernet1/1
    Age of the port-channel is 0d:20h:20m:41s
    Time since last bundle is 0d:20h:20m:51s
    Last bundled member is Ethernet1/4
    Ports:   Ethernet1/1    [on] [up]
             Ethernet1/2    [on] [up] *
             Ethernet1/3    [on] [down]
             Ethernet1/4    [on] [down]

     Había supuesto erróneamente que el modo por defecto era LACP, cuando en realidad era ON. En el modo on el switch simplemente añade los puertos al port channel si tienen enlace, sin más. Por tanto para el switch los dos puertos conectados al servidor formaban parte del port channel y, consecuentemente repartía el tráfico de salida entre ellos. Pero como el servidor estaba en modo LACP y no lograba negociar la agregación con este protocolo, asigna cada interfaz a un grupo de agregación distinto y utiliza solo uno de los grupos, formado por un solo interfaz.

    La solución parecía ya al alcance de las manos.

    # configure terminal
(config)# interface Eth1/1 - 4
(config-if-range)# no channel-group 1
(config-if-range)# channel-group 1 mode active
LACP process needs to be started before configuring active or passive mode

    Resulta que ni siquiera estaba activada la capacidad LACP en el switch. En NX-OS la mayoría de capacidades del switch vienen desactivadas por defecto y hay que activarlas antes de utilizarlas. Activémosla pues y repitamos:

    (config)# feature lacp
(config)# interface Eth1/1 - 4
(config-if-range)# channel-group 1 mode active
(config-if-range)# sh port-channel database
port-channel1
    Last membership update is successful
    4 ports in total, 0 ports up
    Age of the port-channel is 0d:20h:34m:57s
    Time since last bundle is 0d:00h:00m:48s
    Last bundled member is Ethernet1/1
    Time since last unbundle is 0d:00h:04m:50s
    Last unbundled member is Ethernet1/4
    Ports:   Ethernet1/1    [active ] [up]
             Ethernet1/2    [active ] [up] *
             Ethernet1/3    [active ] [down]
             Ethernet1/4    [active ] [down]
(config-if-range)# copy running-config startup-config
[########################################] 100%
Copy complete, now saving to disk (please wait)...

    Ahora.

    Comprobemos el otro lado:

    # cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: a0:b6:cf:d0:2d:f8
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
        Actor Key: 13
        Partner Key: 110
        Partner Mac Address: 00:01:02:03:aa:fc

Slave Interface: p4p1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: a0:b6:cf:d0:2d:f8
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 1
Partner Churned Count: 2
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 1
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: 00:01:02:03:aa:fc
    oper key: 110
    port priority: 32768
    port number: 389
    port state: 61

Slave Interface: p4p2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: a0:b6:cf:d0:2d:fa
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 2
Partner Churned Count: 2
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 2
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: 00:01:02:03:aa:fc
    oper key: 110
    port priority: 32768
    port number: 385
    port state: 61
# ethtool bond0
Settings for bond0:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 20000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

    Todo listo, ambos interfaces en el mismo grupo de agregación, el ancho de banda de ambos interfaces agregado al bonding y la MAC del switch detectada.

    ¡El bonding ya no está medio sordo!

    Ya se puede desactivar el apaño del all_slaves_active, el LAG está ya funcionando correctamente (aunque esta configuración no era persistente).

    # echo 0 > /sys/class/net/bond0/bonding/all_slaves_active

    Otras referencias:

    Para entender el significado de los estados de los interfaces del bonding (port state) ver las definiciones AD_STATE_… en el código del fichero bond_3ad.c.

    El estado mostrado en /proc/net/bonding/bond0 es la representación en decimal del resultado de unir (OR) los valores que corresponden al estado del puerto según las definiciones encontradas en dicho código fuente. Es decir, cuando se estableció correctamente el LAG, el estado del bonding era 61 = 0x3d = 0x20+ 0x10 + 0x08 + 0x04 + 0x01 = DISTRIBUTING + COLLECTING + SYNCHRONIZATION + AGGREGATION + LACP_ACTIVITY.

    Antes, cuando el bonding estaba medio sordo, un interfaz del bonding estabe en estado 77 = 0x4d = 0x40 + 0x08 + 0x04 + 0x01 = DEFAULTED + SYNCHRONIZATION + AGGREGATION + LACP_ACTIVITY. El otro puerto estaba en estado 69 = 0x45 = 0x40 + 0x04 + 0x01 = DEFAULTED + AGGREGATION + LACP_ACTIVITY.

  • Conexión de interfaces de red entre distintos espacios de nombres con iproute2

    Llevaba ya algún tiempo con ganas de practicar con el comando ip y el otro día surgió la ocasión ideal al necesitar que dos aplicaciones (no preparadas para ello) recibieran un mismo flujo de información multicast en el mismo equipo.

    El problema surgió cuando se instaló en un equipo una aplicación que leía el mismo flujo multicast que otra ya instalada previamente, solo la primera en arrancar recibía el flujo, independientemente de cual fuera. Este comportamiento es consecuencia de que ambas aplicaciones abren el socket de recepción del tráfico multicast en modo exclusivo (no es que lo hagan explícitamente, es que es el modo por defecto). Si ambas aplicaciones hubieran establecido la opción SO_REUSEADDR en el socket de escucha antes de hacer bind(), ambas podrían recibir el mismo flujo, pero no era este el caso.

    La solución obvia es modificar las aplicaciones, así no presentarán este problema en futuros despliegues. Pero también hay otra solución más rápida y que puede utilizarse incluso con aplicaciones que no puedan modificarse por no disponer de su código fuente; hacer uso de los espacios de nombres (namespace) ofrecidos por el núcleo de Linux.

    Un espacio de nombres (namespace), o más concretamente, un espacio de nombres de red (network namespace) es un entorno particular dentro de una misma instancia del sistema operativo que tiene su propio conjunto de interfaces de red y tablas de enrutamiento, separado del de otros espacios de nombres de la misma instancia del sistema operativo.

    Por tanto, si creamos un espacio de nombres particular para una de las aplicaciones, mientras dejamos la otra en el espacio de nombres global del sistema operativo, ambas podrán abrir el socket de escritura sobre el mismo puerto sin cambiar su forma de hacerlo. Para ello se necesita crear un interfaz en el espacio de nombres adicional que reciba el flujo multicast al igual que lo hace el interfaz físico (o no) en el que escucha la otra aplicación en el espacio de nombres global.

    La idea estaba clara, ahora quedaba ponerla en práctica con las piezas que pone a disposición el conjunto de herramientas iproute2. No describiré el par de cabezazos que pegué por ir a pecho descubierto sin antes haber leído con cierto detalle la documentación del comando ip y, sobre todo, el funcionamiento de los distintos tipos de interfaces virtuales que se pueden crear.

    Una vez correctamente (no completamente) documentado, decidí aplicar la siguiente configuración con un interfaz de tipo bridge, que es una especie de switch (conmutador ya me parece demasiado aunque sea correcto), al que asociaría el interfaz donde se recibe el flujo multicast y uno de los extremos de un par de interfaces ligados entre sí a modo de tubería creados a partir de un dispositivo tipo veth. El otro extremo de esa tubería se coloca en el espacio de nombres particular para la otra aplicación y listo. A continuación una imagen que vale más que este párrafo:

    Una vez soltado todo el rollo puedo pasar ya a la chicha que son los comandos a ejecutar para realizar ese despliegue.

    En primer lugar se crea el espacio de nombres adicional:

    #ip netns add ns0

    Se crea la tubería que conectará los dos espacios de nombres:

    #ip link add type veth

    Esta orden crea automáticamente dos interfaces llamados veth0 y veth1 (en el caso de que sean los primeros). También se pueden crear dichos interfaces con los nombres que uno desee de la siguiente forma:

    #ip link add vethA type veth peer name vethB

    Se crea el puente y se conectan a él el interfaz que recibe el flujo y un extremo de la tubería:

    #ip link add dev br0 type bridge
#ip link set eth0 master br0
#ip link set veth0 master br0

    Se mueve el otro extremo de la tubería al espacio de nombres adicional y se le asigna una dirección IP y una puerta de enlace en la misma subred que el interfaz eth0:

    #ip link set veth1 netns ns0

    Una vez situado veth1 en el espacio de nombres ns0, todas las operaciones a realizar sobre él deben realizarse desde dicho espacio de nombres, de hecho, habrá ya desaparecido de la lista de interfaces que se puede consultar ejecutando ip link.

    Para facilitar las cosas se puede lanzar un intérprete de comandos en el espacio de nombres y todas las órdenes se ejecutarán en dicho espacio de nombres, pero para que quede más claro aquí pondré las órdenes a ejecutar desde el espacio de nombres global:

    #ip netns exec ns0 ip address add 192.168.1.11/24 dev veth1
#ip netns exec ns0 ip route add default vial 192.168.1.1 dev veth1
#ip netns exec ns0 ip link set veth1 up

    Y listo, aunque puede que se me haya olvidado levantar los interfaces br0 y veth0, por lo que añado estas dos líneas que, en cualquier caso, no hacen daño:

    #ip link set br0 up
#ip link set veth0 up

    Ahora.

    Algunas referencias:

    http://man7.org/linux/man-pages/man7/socket.7.html

    http://rg3.name/201504241907.html

    http://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/

    http://www.policyrouting.org/iproute2.doc.html

    El diagrama lo hice en 5 minutos con https://www.draw.io/

     

  • Instalando dvd::rip en Wheezy

    dvd::rip permite, entre otras cosas, extraer el contenido de un DVD y convertirlo a distintos formatos de video. Para eso lo utilizaba y ahora quería volver a instalarlo en Wheezy. Aunque el fichero que se descarga desde la web oficial contiene ya binarios precompilados, se necesita instalar varios módulos Perl para hacerlo funcionar.

    Éste es el mensaje mostrado al ejecutar el binario dvdrip si no se ha instalado previamente ningún módulo adicional de Perl:

    Can't locate Locale/TextDomain.pm in @INC (@INC contains: lib /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at ./dvdrip line 33.
BEGIN failed--compilation aborted at ./dvdrip line 33.

    En las instrucciones de instalación se indican los módulos  Perl necesarios. Para instalarlos se puede recurrir a los paquetes del sistema o hacer uso a su vez del módulo de CPAN. Los paquetes disponibles en el repositorio los instalamos desde ahí:

    # apt-get install libgtk2-perl libevent-perl libintl-xs-perl libanyevent-perl libevent-extra-2.0-5 libevent-rpc-perl

    Y los que faltan se instalarán mediante CPAN ejecutando como root el shell de CPAN:

    # perl -MCPAN -e shell

    Al ejecutar el shell de CPAN por primera vez solicitará su configuración, aunque esta puede realizarse de forma automática.

    Ahora se solicita la instalación del módulo Locale::TextDomain:

    cpan[1]> install Gtk2::Ex::FormFactory

    Aa continuación se pasa a la instalación de dvd::rip desde el código fuente:

    $ ./configure
$ perl Makefile.PL
$ make test
$ make
# make install

    Y ahora abrimos el binario dvdrip instalado (no el proporcionado en el tar junto con el código) y comprobamos que dvd::rip arranca pero no dispone de todos los comandos necesarios:

     Program Version 
 -------------------------------
 dvd::rip 0.98.11 
 transcode not installed
 ImageMagick 6.7.7 
 ffmpeg 0.8.15-6:0.8.15-1,
 xvid4conf not installed
 subtitle2pgm not installed
 lsdvd not installed
 rar not installed
 mplayer cvs 
 ogmtools not installed
 dvdxchap not installed
 mjpegtools not installed
 xine not installed
 fping not installed
 hal not installed
 -------------------------------

    Por tanto se pasa a la instalación de las utilidades externas necesarias que se encuentran en paquetes disponibles en el repositorio oficial:

    # apt-get install transcode lsdvd rar ogmtools xine-console xine-ui fping hal

    Al volver a probar, aunque han quedado por instalar xvid4conf, subtitle2pgm, dvdxchap y mjpegtools, dvd::rip no muestra ninguna dependencia, sin embargo en el menú Debug->Check dependencies… sí se muestran estas carencias, además de rar, ya que se requiere rar 2.x que se puede encontrar en:

    http://www.exit1.org/dvdrip/contrib/rarlnx271.sfx.bin

    Y configurar la ruta hacia el correspondiente rar en Edit->Preferences->Commands.

    Por último el resto de paquetes, excepto dvdxchap, (y el propio dvdrip 🙂 se pueden instalar desde los repositorios multimedia, para ello se añaden las siguientes líneas a /etc/apt/sources.list:

    # deb-multimedia.org
deb http://oktan.ls.fi.upm.es/deb-multimedia/ stable main
deb-src http://oktan.ls.fi.upm.es/deb-multimedia/ stable main

    Y se ejecuta

     # apt-get install xvid4conf mjpegtools subtitleripper

    Ahora ya está dvd::rip completamente configurado.

     

  • Ficheros de configuración de un servidor DNS local con BIND9

    Introducción

    A continuación se muestra el contenido del conjunto de ficheros de configuración que necesita BIND9 para ofrecer las funciones de DNS local sobre una zona de dominios de primer nivel «.dev» y en una red local 192.168.1.0/24, suponiendo que la dirección IP del servidor DNS es 192.168.1.10.

    Todos los ficheros se se sitúan en la ruta /etc/bind.

    named.conf:

    // This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the 
// structure of BIND configuration files in Debian, *BEFORE* you customize 
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

    named.conf.options:

    options {
    // all relative paths use this directory as a base
    directory "/var/cache/bind";

    // If there is a firewall between you and nameservers you want
    // to talk to, you may need to fix the firewall to allow multiple
    // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

    // If your ISP provided one or more IP addresses for stable 
    // nameservers, you probably want to use them as forwarders.  
    // Uncomment the following block, and insert the addresses replacing 
    // the all-0's placeholder.

    // forwarders {
    //     0.0.0.0;
    // };

    // By not providing a forwarder, root servers are used.
    //forwarders {
    //      192.168.1.1;
    //};

        //=====================================================================$
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //=====================================================================$
        dnssec-validation auto;

    auth-nxdomain no;    # conform to RFC1035
    // To listen only on certain interfaces list them here:
    //listen-on { 127.0.0.1; 10.0.0.1/24; };
    listen-on-v6 { any; };
    listen-on { any; };

    // This prevents bind from serving requests from IPs other than specified:
    allow-query-cache { 127.0.0.0/8; 192.168.1.0/24; };

    // version statement changed for security (to avoid hacking known weaknesses)
    version "not currently available";

    // This prevents bind from serving other than authoritative requests:
//    recursion no;
    // disables all zone transfer requests for performance as well as security reasons
//    allow-transfer { none; }; // The allow-transfer in each zone overrides this
//    dnssec-enable no; // zone not signed - yes by default since BIND 9.5
//    minimal-responses yes; // optional - improved performance
//    additional-from-auth no; // optional - improved performance
//    additional-from-cache no; // optional - minimal performance change
};

// ----------------------- Logging ----------------------- 
// log to /var/log/bind/bind9_info.log all events from info UP in severity (no debug)
// uses 3 files in rotation swaps files when size reaches 250K
// failure messages up to this point are in (syslog) /var/log/messages
logging {
  channel custom_log {
    file "/var/log/bind/bind9_info.log" versions 3 size 250k;
    severity info;
        print-time yes;
        print-category yes;
  };
  category default {
    custom_log;
  };

  // Debugging logging settings
//    category "default" { "debug"; };
    category "general" { "debug"; };
    category "database" { "debug"; };
    category "security" { "debug"; };
    category "config" { "debug"; };
    category "resolver" { "debug"; };
    category "xfer-in" { "debug"; };
    category "xfer-out" { "debug"; };
    category "notify" { "debug"; };
    category "client" { "debug"; };
    category "unmatched" { "debug"; };
    category "network" { "debug"; };
    category "update" { "debug"; };
    category "queries" { "debug"; };
    category "dispatch" { "debug"; };
    category "dnssec" { "debug"; };
    category "lame-servers" { "debug"; };

    channel "debug" {
    file "/var/log/bind/bind-dbg.log" versions 2 size 50m;
        print-time yes;
        print-category yes;
    };

};

    named.conf.local:

    //
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "dev" {
    type master;
    file "/etc/bind/db.dev";
//    allow-transfer { 10.0.0.1; }; // Slave server for the domain
    allow-update { none; }; // Don't allow updates from other servers
};

zone "1.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.1.168.192";
};

    named.conf.default-zones:

    // prime the server with knowledge of the root servers
zone "." {
    // a hint type means that we've got to look elsewhere
    // for authoritative information
    type hint;
    file "/etc/bind/db.root";
    // This file is maintained by InterNIC and made available at:
    // ftp://ftp.internic.net/domain/named.root
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
    // a master type means that this server needn't look
    // anywhere else for information; the localhost buck
    // stops here.
    type master;
    file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
    type master;
    file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
    type master;
    file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
    type master;
    file "/etc/bind/db.255";
};

    db.dev:

    ;
; BIND data file for dev local TLD
;
$ORIGIN dev.
$TTL    604800
@    IN    SOA    ns.dev. root.localhost. (
                  3        ; Serial
             604800        ; Refresh
              86400        ; Retry
            2419200        ; Expire
             604800 )    ; Negative Cache TTL
;
@    IN    NS    ns.dev.
@    IN    A    192.168.1.10
@    IN    AAAA    ::1

ns    IN    A    192.168.1.10
otro  IN    A    192.168.1.100

     

    db.1.168.192:

    ;; db.1.168.192 - Reverse lookup zone for domain-name
$TTL 2D
@    IN    SOA    ns.dev.    root.localhost. (
                  3        ; Serial
             604800        ; Refresh
              86400        ; Retry
            2419200        ; Expire
             604800 )    ; Negative Cache TTL
;

@    IN    NS    ns.dev.

10    IN    PTR   ns.dev.        ; The nameserver 192.168.1.10
100   IN    PTR   otro.dev.

     

    Referencias:

    http://blog.philippklaus.de/2011/04/get-your-own-dns-server-up-and-running-with-bind9-on-ubuntu-or-debian/
    http://www.server-world.info/en/note?os=Debian_6.0&p=dns
    http://www.cameratim.com/computing/linux/using-bind-as-a-local-dns-server
    http://www.zytrax.com/books/dns/ch8/aaaa.html

  • Sincronización con rsync entre distintos sistemas de ficheros

    Al sincronizar ficheros entre distintos sistemas de ficheros con rsync pueden surgir problemas con los nombres de fichero con caracteres especiales (?, ñ, ó, …) si el conjunto de caracteres utilizado en cada sistema de ficheros es distinto, por ejemplo si uno utiliza ISO-8859-1 y otro UTF-8.

    Para solucionar el problema rsync puede gestionar la transformación de la codificación utilizando el parámetro –iconv. Así, si queremos sincronizar ficheros desde un sistema de ficheros con codificación ISO-8859-1 hacia otro con UTF-8 se indicará de la siguiente forma:

    $ rsync -avz --iconv=ISO-8859-1,utf-8 /ruta/origen/ISO-8859-1/ /ruta/destino/UTF-8/

    También puede ser un problema el propio montaje del sistema de ficheros si tiene un conjunto de caracteres distinto al configurado por defecto en el sistema, en ese caso se puede utilizar mount indicando la codificación correcta mediante el parámetro locale:

     mount -o locale=es_ES.iso8859-1 /dev/sdb1 /ruta/ISO-8859-1

     

     

  • Configurar Java 7 en Wheezy

    Después de desactivar el plugin de Java para Iceweasel por los fallos de seguridad instalé Java 7 update 9, que parece arreglar los ya conocidos (tal vez tenga otros). La instalación la hice descomprimiendo el tar en /opt, y configurando las alternativas de la siguiente forma:

     

    update-alternatives --install /usr/bin/java java /opt/jdk1.7.0_09/bin/java 1
update-alternatives --install /usr/bin/javac javac /opt/jdk1.7.0_09/bin/javac 1
update-alternatives --install /usr/lib/mozilla/plugins/libjavaplugin.so mozilla-javaplugin.so /opt/jdk1.7.0_09/jre/lib/amd64/libnpjp2.so 1
update-alternatives --set java /opt/jdk1.7.0_09/bin/java
update-alternatives --set javac /opt/jdk1.7.0_09/bin/javac
update-alternatives --set iceweasel-javaplugin.so /opt/jdk1.7.0_09/jre/lib/amd64/libnpjp2.so

     

    También puede ser necesario actualizar el enlace que pudiera haberse creado previamente en el directorio de plugins de Mozilla particular del usuario:

     

    cd ~/.mozilla/plugins
ln -fs /etc/alternatives/mozilla-javaplugin.so libnpjp2.so
    

     
    

     
    

     
    

    
			
    
		
    
		
	
  • 
		
		
    
			
			
    OpenDNIe para Debian Wheezy 64 bits (y Squeeze 64bits también)
    
			
    Edición: Voy a revisitar/revisar este post que escribí hace casi dos años para asegurarme de que funciona a día de hoy 9 de abril de 2014.
    

    Gracias a las instrucciones de cómo usar el DNI electrónico en Debian Wheezy de Rodrigo Aguilera me decidí, otra vez a intentar hacer funcionar el DNIe en Linux, esta vez en Debian Wheezy 64bits (testing en ese momento).
    

    Comencé con la instalación de los paquetes sugeridos:
    

    apt-get install pcscd pcsc-tools pinentry-gtk2
    

    A continuación descargué el paquete opensc-opendnie para Debian proporcionado por OpenDNIe pero, al comprobar que el checksum no coincidía con el proporcionado, decidí optar por la compilación de los fuentes de opensc parcheados para DNIe. Y aquí empiezan los problemas.
    

    Edición. La compilación se realiza del modo habitual en los paquetes fuente bien hechos, es decir ./configure, make y make all. El día que yo aprenda a hacer un paquete de estos escribiré otro post explicándolo.
    

    Al ejecutar ./configure fallaba por no encontrar winscard.h. La solución estaba en este hilo:
    

    apt-get install libpcsclite-dev
    

    Ahora sí terminó con éxito la ejecución de ./configure. El siguiente problema fue en la compilación. make fallaba al no encontrar el símbolo dlopen y otros.
    

    En Squeeze 64 bits make realiza la compilación con éxito sin más acciones, por lo que se puede pasar a su instalación con make install. Nota, esto no lo he probado en la revisión del 2014, ya no tengo ningún Squeeze, pero se supone que debe seguir igual.
    

    Para arreglar el problema de dlopen instalé la librería dl ya que como se sugería en StackOverflow había que enlazar con ella.
    

    apt-get install libdlrestrictions-dev
    

    Pero make volvía fallar, y es que hay que incluir manualmente -ldl en la variable LDFLAGS.A continuación se ejecuta make proporcionando la variable de entorno LDFLAGS con la inclusión de la librería dl:
    

    export LDFLAGS=-ldl ; ./configure ; make
    

    Ahora el problema que se presentaba era con el símbolo dnie_match_card. El caso es que el símbolo estaba en card-dnie.c, pero el símbolo no estaba definido en la librería libopensc.so (tal como indicaba el error). Mirando el código de este fichero (después de otras cosas) vi que requería openssl. Yo tenía openssl instalado, pero no libssl-dev que es lo que hacía falta.
    

    apt-get install libssl-dev
    

    Ahora, confirmando que quería openssl en configure, e indicando en las variables de entorno el uso de la librería dl, la compilación funcionó:
    

    export LDFLAGS=-ldl; ./configure --enable-openssl
    

    make
    

    Y como root:
    

    make install
    

    Ahora, continuando con el documento de referencia inicial y creamos el enlace en /usr/lib a /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.
    

    ln -s /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 /usr/lib
    

    Ya «sólo» queda añadir el certificado de la autoridad de certificación de la DGP y el módulo creado como dispositivo de seguridad a firefox. El certificado de la autoridad de certificación raíz se encuentra en el portal oficial para el DNIe. Hay que importarlo desde la sección de certificados de autoridades de certificación (preferencias -> avanzado -> encriptación -> ver certificados -> autoridades -> import y seleccionar confiar en el certificado para sitios web, direcciones de correo electrónico y software).
    

    Para agregar el módulo creado a firefox tuve que tirar del último apartado de otras instrucciones para el DNIe donde se proporcionaba el siguiente comando (ejecutar como el usuario final, no como root). Debe ejecutarse con firefox cerrado.
    

    modutil -dbdir ~/.mozilla/firefox/$(cat ~/.mozilla/firefox/profiles.ini | grep Path | awk -F"=" '{print $2}') -add "DNIe" -libfile /usr/lib/opensc-pkcs11.so
    

    En el caso de que no exista el comando modutil se instala con el paquete libnss3-tools:
    

    apt-get install libnss3-tools
    

    Añadido: Para que el comando modutil funcionara tuve que hacer un par de enlaces simbólicos (hay más soluciones pero esta me pareció la más directa):
    

    ln -s /usr/local/lib/opensc-pkcs11.so /usr/lib/
ln -s /usr/local/lib/libopensc.so.3 /usr/lib/
    

     
    

    Y ahora se puede importar el módulo desde el apartado dispositivos de la pestaña de configuración de cifrado de firefox. Para ello se pulsa en cargar y se proporciona la ruta /usr/local/lib/opensc-pkcs11.so, que es donde la instalación de los fuentes deposita el módulo si no se indica otra ruta.
    

    Una vez hecho esto, reiniciando Iceweasel/Firefox pude, por primera vez de nuevo, utilizar el DNIe en Linux.
    

    Nota. Es necesario tener el plugin de Java habilitado en Iceweasel/Firefox para poder utilizar el DNIe.
    

    
			
    
		
    
		
	
  • 
		
		
    
			
			
    Ejecutar PDroidPatcher (aplicación Win32) en Wheezy 64 bits (incompleto)
    
			
    PDroidPatcher es una aplicación para Win32 que requiere para su ejecución Java y .NET. Por lo tanto hacen falta tres cosas para ejecutarlo; poder ejecutar aplicaciones Win32, instalar Java e instalar la infraestructura de ejecución de aplicaciones .NET.
    

    Instalación de Wine
    

    Para ejecutar las aplicaciones para Win32 en GNU/Linux se dispone de la herramienta Wine, incluida en los repositorios de Wheezy. Sin embargo, aunque la versión Wheezy para arquitecturas AMD64 incluye en el repositorio un paquete Wine, se trata de un paquete transicional, de modo que al intentar ejecutar wine, nos indicará que hay que instalar el paquete de la arquitectura de 32 bits y cómo hacerlo.
    

    Para instalar Wine para 32 bits hay que, en primer lugar, proporcionar a la instalación de Wheezy de 64 bits la capacidad de ejecutar aplicaciones de 32 bits instalando las librerías necesarias:
    

    apt-get install ia32-libs ia32-libs-gtk
    

    A continuación hay que preparar el sistema de paquetes para que incluya paquetes de la arquitectura de 32 bits en las búsquedas.
    

    dpkg --add-architecture i386
    

    Ahora se actualiza la base de datos
    

    apt-get update
    

    Y  se instala el paquete de Wine (hay que aceptar la eliminación del paquete de 64 bits):
    

    apt-get install wine-bin:i386
    

    Una vez instalado, opcionalmente, se puede volver a configurar el sistema de paquetes para que sólo trabaje con paquetes de la arquitectura de 64 bits.
    

    dpkg --remove-architecture i386
    

    También suele ser conveniente instalar el paquete winetricks, que ayudará a instalar complementos a la instalación de Wine necesarios para poder ejecutar algunas aplicaciones Win32.
    

    apt-get install winetricks
    

    Java
    

    Ya está Wine instalado pero, como indica al principio del artículo, esto es sólo  la  base, ahora hay que instalar Java, concretamente la versión JDK 6 (para Windows x86, claro), que es la que requiere en concreto PDroidPatcher. El instalador de JDK6 se puede descargar desde la página de descargas de Java SE. Una vez descargado se ejecuta en el entorno Wine.
    

    wine ~/Downloads/jdk-6u35-windows-i586.exe
    

    Soporte .NET
    

    Por último para el soporte para aplicaciones .NET existen dos alternativas, la de Microsoft y la de código abierto, Mono. Las dos pueden ser válidas, pero sólo una debe instalarse.
    

    La instalación de Mono se realiza mediante winetricks, pero de 32 bits. Para ello se ejecuta lo siguiente.
    

    export WINEARCH="win32"
winetricks dotnet35
    

    Desgraciadamente, aunque con todo esto se consigue iniciar PDroidPatcher, durante la ejecución se produce un error y no logra formar el parche para la imagen Android proporcionada. Ni siquiera con Mono:
    

    winetricks mono26
    

     
    

     
    

    
			
    
		
    
		
	
  • 
		
		
    
			
			
    Recetas varias Wheezy
    
			
    Recuperación de entorno gráfico después de actualización de núcleo:
    

    apt-get install nvidia-kernel-dkms
    

     
    

    Mejorar aspecto de aplicaciones que utillizan Gtk en Qt:
    

    apt-get install gtk3-engines-oxygen gtk2-engines-oxygen
    

     
    

    Historial de apt:
    

    cat /var/log/dpkg.log
    

    cat /var/log/apt/history.log
    

     
    

    Evitar el continuo mensaje de error del kernel «unable to enumerate usb device» prohibiendo la carga del módulo que lo genera (en este caso) ohci_hcd. Para prohibir su carga se envía un mensaje al kernel en su carga desde Grub, para ello se edita /etc/default/grub añadiendo la opción modprobe.blacklist=ohci_hcd:
    

    GRUB_CMDLINE_LINUX_DEFAULT=»quiet vga=791 modprobe.blacklist=ohci_hcd»
    

    Capturas de pantalla
    
Aunque el conjunto de efectos que viene con KDE incluye una captura de pantalla, a mi no me funcionaba así que tuve que arreglarlo instalando el paquete ksnapshot:
    

    apt-get install ksnapshot
    

     
    

    Para habilitar los codecs propietarios hay que instalar paquetes que no están en el repositorio oficial, para acceder a ellos se añade el repositorio multimedia a la lista de repositorios:
    

    echo «deb http://www.debian-multimedia.org wheezy main non-free» >> /etc/apt/sources.list
    

    Ahora se actualiza la base de datos y se instalan los paquetes necesarios:
    

    apt-get update
    

    apt-get install w64codecs
    

    apt-get install libdvdcss2 vlc
    

    aptitude install gstreamer0.10-fluendo-mp3 gstreamer0.10-ffmpeg ffmpeg sox twolame vorbis-tools lame faad
    

    Pedirá confirmación ya que no se ha incluido la clave de verificación del repositorio multimedia. El paquete a instalar es w64codecs para Wheezy de 64 bits, para 32 bits sería w32codecs.
    

     
    

    Wireshark
    

    Para configurar Wireshark para poder ser ejecutado sin privilegios de root hay que crear un grupo llamado wireshark y añadir a los usuarios deseados a ese grupo.Sin embargo, la creación del grupo hay que dejarla en la mano del paquete wireshark-common.
    

    dpkg-reconfigure wireshark-common
    

    usermod -aG wireshark <usuario>
    

    Para que el usuario haga efectiva su pertenencia al grupo wireshark y pueda, por tanto, acceder desde Wireshark a los interfaces hay que iniciar una nueva sesión.