EDICIóN GENERAL
173 meneos
4777 clics

Hay razones reales para reemplazar las herramientas de Linux ‘ifconfig’, ‘netstat’ y compañía [ENG]

Una de las controversias de administración de sistemas actual en Linux es que hay un esfuerzo continuo por reemplazar los comandos de administración y diagnóstico de red estándar de Unix, ifconfig, netstat y similares, con nuevos elementos específicos como ss e ip. Aunque a los administradores de sistemas con experiencia generalmente no les gusta esta idea, existen dos razones principales para realizar este cambio, una ostensible y otra sutil.

| etiquetas: razones , reemplazar , herramientas de red , ifconfig , netstat , ss , ip
Comentarios destacados:                  
#7 #5 A parte de lo cansino de la típica pedantería que sueltas, que lleva siendo cansina desde hace 20 años, es que no tienes razón.

iproute2 es una herramienta para administrar el networking del kernel Linux, conectándose directamente al kernel via netlink y modificando las tablas internas del kernel. No es una herramienta GNU ni específica para distribuciones GNU/Linux, funciona en cualquier sitio donde haya un kernel linux con networking y soporte para netlink.
Ala.. a cambiar los scripts :wall:
#1 Bueno, teniendo en cuenta que algunas herramientas como ifconfig se las han cargado igualmente y su salida ya no es igual que antes...
#1 Nadie te va a obligar a desinstalar las net-tools.

Pero vaya, que iproute2 ya iba por la 3.0 en 2011. No creo que esta recomendación pille por sorpresa a nadie.
#3 Si no recuerdo mal, debian stretch por defecto no las lleva instaladas. A mi me pilló desprevenido al reinstalar una máquina que, (siguiendo la ley de murfy) se quedó sin internet
#4 te recomiendo aprovechar la situación y aprender a usar ip que es mucho más versátil y potente
#1 Solonsi actualizas. Yo seguiré con mis lavadoras HP-UX 11.00 y mis RedHat 7 aguantando al pie del cañón en un entorno donde la empresa que hizo el software que corre en esos servidores ya no existe pero la necesidad de seguirlo ejecutando si. No corren en nada mas moderno.

El tiempo pasa, las herramientas evolucionan y aunque duela es hora de actualizar scripts.
#10 una buena oportunidad para intentar hacer correr ese software en contenedores ;)
#12 ¿Contenedores Linux o de la basura? :shit:
#14 no son lo mismo? :roll:
#12 Tenenos un cluster HP-UX en arquitectura Itanium con máquinas que contienen VM y su vez contienen contenedores de máquinas HP con arquitectura PA-RISC. Es un truñardo de dimensiones épicas. Eso sí, en dos bastidores hemos metido lo que antes estaba en dos filas enteras del CPD.

En cuanto a Linux tenemos muchos contenedores, pero nos sale más a cuenta esperar a que le cliente deje de tener la necesidad de ejecutar cierto software que corre en esos servidores que los costes de la migración.…   » ver todo el comentario
#10 Siendo un novato absoluto en el tema, ¿no sería posible mejorar ifconfig de manera que pueda ofrecer la salida correcta, completa, de información usando un switch específico, de manera que los nuevos scripts puedan usarlo, pero que no rompa los scripts que ya hay?

En cuanto a la forma de trabajar de cada comando, ¿qué problema hay en que coexistan ifconfig e ip, como han venido coexistiendo hasta ahora, y que cada admin use el que más le convenga en cada momento?
#45 No hay ningún problema en que coexistan. Vienen en paquetes distintos y extraen su información de lugares distintos.

El problema de compatibilidad es que las herrameintas antiguas, y los scripts que las utilizan, no contemplan la posibilidad de que una misma interfaz tenga por ejemplo más de una IP, por ejemplo. Así que en los casos donde solo tienen una configurada podrías incluso desinstalar el paquete donde viene ifconfig y crear un alias o un script llamado ifconfig que llame a ip y…   » ver todo el comentario
#5 No se si es una batalla perdida...

El lenguaje está vivo. Cuando se hizo famoso dejó de estar en manos de sus creadores.

A pesar de “estar mal escrito” , mucha gente sobreentiende a Linux como el SO entero y su entorno.
#6 Pontelo en tu epitafio macho .... "Se dice GNU Linux copón!!!"
#27 Y Naik se pronuncia naiki...
pero el pueblo habla... mal... pero habla.
#61 Los ingleses dicen "naik", los estadounidenses "naiki" y los griegos que adoraban a la diosa que da nombre a la marca de ropa "nike". Así que... :roll:
#5 A parte de lo cansino de la típica pedantería que sueltas, que lleva siendo cansina desde hace 20 años, es que no tienes razón.

iproute2 es una herramienta para administrar el networking del kernel Linux, conectándose directamente al kernel via netlink y modificando las tablas internas del kernel. No es una herramienta GNU ni específica para distribuciones GNU/Linux, funciona en cualquier sitio donde haya un kernel linux con networking y soporte para netlink.
#7 zascaaa
#11 Es una herramienta para administrar la red. No es técnicamente parte del kernel. Hay que ver si forma parte del paquete del kernel y me temo que no. Ahora.... ni idea si es de GNU o no. :troll:
#13 iproute2 se aloja en kernel.org. git.kernel.org/pub/scm/network/iproute2/iproute2.git

Todo util-linux se ejecuta en userspace y es parte del proyecto del kernel, auque luego a nivel de código no tenga nada que ver en.wikipedia.org/wiki/Util-linux
#13 No es parte del kernel, pero es una herramienta para administrar el kernel Linux. Puedes usarlo en Linux sin GNU, pero no puedes usarlo en GNU/FreeBSD, por ejemplo.
#41 Como muchas herramientas GNU
#41
netlink también está en FreeBSD.
www.freebsd.org/cgi/man.cgi?query=netlink&sektion=7&manpath=Su

Por eso decía sólo lo de GNU y opcionalmente GNU/Linux si quieres ser más específico.

De hecho util-linux está diseñado para ser multiplataforma: mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.32/v2.32-Release (sirva de ejemplo el cambio en libblkid para FreeBSD).
#7 Kame...hame... ha!!!! :-D
#7
Es gracioso porque estás equivocado. Analiza el binario ip y verás que está diseñado para GNU/Linux:
ldd /bin/ip
 linux-vdso.so.1 (0x00007fff18f2a000)
 libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f623acd2000)
sourceware.org/elfutils/
 libmnl.so.0 => /lib/x86_64-linux-gnu/libmnl.so.0 (0x00007f623aacc000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f623a8c8000)
www.gnu.org/software/libc/
 libc.so.6 =>…   » ver todo el comentario
#49
Ah ... y netlink también está en FreeBSD.
www.freebsd.org/cgi/man.cgi?query=netlink&sektion=7&manpath=Su

Por eso decía sólo lo de GNU y opcionalmente GNU/Linux si quieres ser más específico.

De hecho util-linux está diseñado para ser multiplataforma: mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.32/v2.32-Release (sirva de ejemplo el cambio en libblkid para FreeBSD).
#56
Cree lo que quieras, pero diciendo eso demuestras que no dominas nada.

#53 te da más detalles si quieres leerlos claro.

Y lo que es ruin es votar negativo a un comentario que ni es racista, ni hace spam, ni insulta, ni es xenófobo.
#49 Qué tendrá que ver como esté linkado un determinado binario con su diseño.
#58
Otro que no lee.
Para poder enlazar un programa con una biblioteca ha de ser compatible con esta. Si puede enlazarse con GNU es que ha sido diseñado para GNU, además de otros sistemas operativos como se puede ver en la página util-linux.

Cosas de las API y ABI.
#59 La llamada a funciones en c en sistemas derivados de unix tiene más años que yo, no es nada que haya inventado linux o GNU.

Hablando de GNU, GNU aloja un libro gratuito en savanah llamado programming from the ground up que explica por encima el tema. O si quieres algo a más bajo nivel tienes esto:
software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.

Ni linux ni GNU han inventado nada en cuanto a ELF o linkado (o enlazado si te quedas más contento), en system v estaba todo inventado.

PD: Digo ELF por poner el formato usado en los binarios que mencionas pero que si quieres mirarte la parte de los binfmt_ del kernel viene a ser lo mismo.
#66
No sé cuál es la intención de tu mensaje. Linux adoptó ELF en 1995: www.linuxjournal.com/article/1059

Los binarios generados por o para GNU tienen secciones propias de GNU y están enlazados con la GNU libc. Linux en sí mismo está pensado para GNU utilizando la API del C de GNU (GCC).
EDITADO: Le di a enviar sin querer

#68 Pues que no existe tal cosa como enlazar con GNU. Enlazas ficheros ELF y luego tienen que coincidir los parametros,pero eso es tema de la llamada a la función en si y da igual linkado estático dinámico etc.
$ readelf -h /sbin/ip

> Los binarios generados por o para GNU tienen secciones propias de GNU y están enlazados con la GNU libc.
> Linux en sí mismo está pensado para GNU utilizando la API del C de GNU (GCC).

ELF Header:
Magic: 7f 45 4c…   » ver todo el comentario
#69
$readelf -e /bin/ip
Encabezados de Programa:
Tipo Desplazamiento DirVirtual DirFísica
TamFichero TamMemoria Opts Alineación
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000001f8 0x00000000000001f8 R 0x8
INTERP 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0…   » ver todo el comentario
#71 Eso no son secciones, son cabeceras, y las ha metido el linker, insisto, si lo compilas con llvm no estrían
#69
La ABI de GNU es específica de GNU. Por suerte ésta es estable.
No he hablado de enlazado dinámico o estático precisamente porque es irrelevante. Simplemente con ldd mostraba las bibliotecas con las que estaba enlazadas y por tanto con las que «ip» tiene que ser compatibles/estar diseñado para.
#74 Paso de discutir más, todo lo que hay especifico de GNU lo ha metido el compilador o en su defecto, si compilas con musl y llvm (cosa que puedes hacer) no te sale nada de eso.
#76
Eso si puedes compilarlo con LLVM y Musl.
Pero insistes en que no está pensado para GNU cuando lo que estoy diciendo es que está pensado para GNU y otros sistemas operativos aunque aparte de FreeBSD no sé cuales. ¿Los basados en Musl? Puede, no lo sé.
#59 Si, eso es obvio, iproute2 puede funcionar con sistemas GNU (enlazar con glibc) o no y también tiene licencia GPL2 de GNU, pero eso no les convierte en software GNU.

Este es el directorio con todo el software GNU

www.gnu.org/software/

Allí no está ni iproute2 ni las net-tools, por lo tanto no son software GNU, por lo tanto y volviendo al tema, no es correcto corregir a la gente por llamarlo Linux a secas. Es más, en mi opinión no es correcto llamarlo GNU/Linux a no…   » ver todo el comentario
#79
Sinceramente, cualquiera que lea el hilo de comentarios encontrará una explicación a todo lo que cuestionas.
#49
1- Que un proyecto esté compilado con gcc y que utilice glibc no lo convierte automáticamente en GNU. Por ejemplo, systemd solo funciona con glibc y no es GNU (aunque sea GPL) porque no forma parte de los proyectos alojados en GNU.
2- Que esté linkado contra librerías de glibc no quiere decir que solo pueda depender de estas, ip puede funcionar perfectamente con musl.
#62
1- Está diseñado para GNU, se convierte automáticamente en un software para GNU aunque su autoría no sea la de GNU.
2- No he dicho lo contrario.

Y por favor, eso de linkado está muy feo. Enlazado o vinculado.
#63 Es que ip no está diseñado para GNU, está diseñado para linux.
#64
Está diseñado para GNU y otros sistemas operativos como FreeBSD.
#65 Se diseñó para gestionar interfaces de redes en linux. Netlink lo implementa Alexey Kuznetsov[1] porque necesita un mecanismo para comunicarse entre el kernel y userspace y ninguna de las alternativas existentes era satisfactoria [2]. Y el mismo Alexey Kuznetsov hace iproute2[3].

Es completamente ABSURDO hablar de GNU y netlink cuando netlink es un tipo de socket, de modo que se implementa en kernelspace y lo unico que hace glibc es que cuando llamas a socket te admite en el protocolo…   » ver todo el comentario
#67
No es absurdo hablar de GNU y netlink puesto que GNU es quien permite a los programas acceder a la implementación netlink del núcleo subyacente, como ocurre en GNU/kFreeBSD.

Tú mismo lo dices, permite comunicar espacio de usuario con espacio de núcleo. Si GNU no soporta Netlink el usuario no podrá usar netlink. Las cabeceras se distribuyen con GNU y la gestión previa a la comunicación con el núcleo se hace con GNU.

Nótese que GNU Hurd también soportará Netlink. Código fuente de GNU…   » ver todo el comentario
#70 No tiene ningún sentido lo que dices. La función socket espera una serie de parámetros, y cuando metes AF_NETLINK lo que hace es que tiene una definición de que AF_NETLINK = 16. Y eso se le pasa al kernel tal cual le llega (hazme caso, que he comprobado el código)

Si en vez de meterle AF_NETLINK le metes 127 (que cabe) glibc se lo pasa igual al kernel, otra cosa es que el kernel luego te devuelva un error.

Ahora, si netlink es GNU porque porque la gente de glibc ha añadido una linea que pone
#define AF_NETLINK 16

Pues ahi ante esa lógica aplastante ya no digo nada.

> Nótese que GNU Hurd también soportará Netlink
HURD tambien soporta TCP y creo que no por ello nadie diria que TCP es GNU.
#72
En ningún momento he dicho que Netlink sea GNU.
La afirmación incial es que ip está diseñado para GNU y FreeBSD, no sé si otros sistemas operativos están implicados.

Glibc hace chequeos previos. Si metes 127 ese valor no llegará al núcleo.
#5 Estás confundiendo la acepción secundaria "núcleo" por la acepción primaria "sistema que usa ese núcleo".
#29
Estamos hablando de un nombre propio, no tiene significado. No tiene definición.
#50 Entonces no te quejes del uso que se le de. Si no tiene significado ni definición, no puedes decir que esté bien o mal nada.
#51
Que no tenga significado no significa que no tenga sentido.
El hispterismo llega hasta Linux ... Yo por el ifconfig mato, me entiendesssss ? MA-TO!!!!
Si dan información errónea o incompleta me parece normal no usarlos y cambiarlos. No sé porqué en las distribuciones no usan el concepto de depreciación de las bibliotecas de programación.
Que pongan esos comandos en cuarentena unas cuantas versiones, con avisos grandes y una lista de alternativas y a la siguiente iteración las eliminan. Si alguien no se hubiese enterado no sería porque no le han avisado.

Por otro lado me resulta curioso que digan que una pega es que esas herramientas están…   » ver todo el comentario
#15 bueno, la cuestión es que ya hay problemas de rendimiento reales con ifconfig y demás cosas que intentan parsear cosas de /proc y /sys . Un ejemplo: en sistemas que corren VMs de openstack o contenedores con centenares de bridges, un `ifconfig -a` puede tardar más de 20 minutos solo en listar los interfaces. `ip a` lo hace en menos de 1 segundo...
#25 ¿Pero ese problema es por "parsear" el fichero en serie mientras que con netlink se puede hacer en paralelo? ¿Porque el núcleo tarda mucho en generar el fichero en /proc u otra razón?
Quizás la tecnología "todo es un fichero" ya no escala en estos tiempos, pero da la impresión de que parche aquí, parche allá, al final tenemos multiples subsistemas, cada uno con sus reglas y forma de hacer las cosas diferentes entre sí. Al final eso genera un batiburrillo complicado de aprender.
Joder, tengo que reinstalarme Linux de ya y ponerme al día :-D
ifconfig o ifconf o ipconfig o ipconf? bienvenido sea ip!
Tampoco hay que correr en circulos gritando pudiendo desinstalar los paquetes obsoletos y creando aliases de los antiguos comandos con la nueva sintaxis.
Qué raro ver una meneo de esta categoría en portada
#20 ¿Acabas de descubrir que meneame es frikilandia?
(Me incluyo, eh)
#24 Calla, que mi primera portada fue un artículo sobre un fallo de Linux, y mi segunda portada una aclaración desmintiendo/corrigiendo la primera… xD
Mientras que podamos seguir eligiendo entre lo viejo y lo nuevo yo no veo problema en que existan nuevas herramientas.
Como no me habian tocado bastante los webos con el p***o systemd, ahora me van cambiando mas herramientas?

Vale, que todo evoluciona poero no me digais que no es tocapelotas, 4 o 5 años despues sigo buscando el maldito initd
#26 Ya tenía que salir alguien mentando systemd. Tanto init cómo estás herramientas se están cambiando en sistemas modernos porque tienen limitaciones insalvables, así de simple.

Pero nadie te obliga a usarlas, hay mucha gente con mucho tiempo libre y muy poco que hacer que se dedica a mantener SOs con herramientas antiguas. Si tanto te gustan, pásate a esos. Por ejemplo Devuan.
#28 Tienes acciones de systemd o que?
#30 No. Simplemente se en que lado de la historia estoy.

Estoy en el mismo lado que la totalidad de distribuciones serías de GNU Linux que se utilizan para sistemas de producción enormes de alta disponibilidad. Igual estamos todos equivocados y los genios con nicknames entrecomillados de Devuan (devuan.org/os/team/) tienen razón, pero no me suena ver ningún caso de uso relevante para su SO, por algo será.

CC #32
#28 Una de las grandísimas ventajas de unix era que las herramientas hacen una sola cosa pero la hacen bien.

Systemd va en contra de esa filosofía que tan bien había funcionado hasta ahora.
#32 En realidad no es exactamente así. Es cierto que el nombre "systemd", en origen, era el del reemplazo de init, pero poco después se convirtió en un "proyecto paraguas". Es algo así como "el proyecto gnome" o "KDE", que en realidad son "proyectos paraguas" que aglutinan muchas cosas independientes (el escritorio, utilidades, applets...). Actualmente "systemd" comprende, por un lado, el binario que reemplaza a init (y es un binario…   » ver todo el comentario
#26 a ver, que se lleva avisando al menos 10 años de que ifconfig y netstat quedan obsoletos y que pases a ip y ss...
Cuando hagan que la salida de un "ip address show" sea tan práctica y legible como la de un "ifconfig", empezaré a usar ip.
#31 con ip a te vale.
#34 Si, pero no me quejo de la cantidad de teclas que tengo que presionar sino del formato del resultado. Es muchísimo más legible el de ifconfig. Por ejemplo:
.  media
#36 En realidad, bastaría con añadir una línea en blanco entre interfaces... no es un cambio demasiado grande...
#39 Y algunas tabulaciones o algo para que salga más encolumnado, no se.

Lo mismo me pasa con ip route vs. route (o netstat -rn) aunque reconozco que el ip route y el ip addrees permiten más cosas que un simple ifconfig o un route xx la salida es mucho más fácil de leer:
.  media
Pues el emacs es una mierda. Yo me quedo con vi.

Era aquí donde se dan opiniones sobre opciones? Me tengo que poner al día ahora es ifconfig o ip.
Estas cosas con Windows no pasan.
La verdad es que el nombre apropiado tendría que ser util-kernel y no util-linux, pero el ego a algunos le juega malas pasadas.
# 49 ( usuario bcc2c436cab )

o sea que según tú, un software es específico para un SO si el binario compilado para este SO usa las librerías de dicho SO? Que se haya compilado contra la libc de GNU no quiere decir que dependa de GNU, también se podría haber compilado contra otra libc. Ahora mira el binario "ip" en Android a ver contra qué está linkado.

Creo que estás intentando tratar un tema que no dominas mucho.


----

Un poco ruin eso de responder a alguien y luego meterlo en ignorados para que no te pueda replicar a la tontería que has dicho
entiendo que sea importante, y que medio menéame sean informáticos, pero que esto sea portada me parece demencial
#60 A mi me parece muy cabal, cuando Menéame molaba hace años, había mínimo cada dos días una noticia sobre software libre.

Después vino el grafeno, los gatos y ahora estamos en la época forocoches.
#60 Lo que es demencial es la política a todas horas, teniendo en cuenta que menéame empezó como una comunidad que venía de barrapunto.
#60 Y por qué te parece demencial??
Si sabes que medio MNM son informáticos... y que este envío para ellos es importante... que parte es lo que te parece demencial??

Porque, aunque a ti la informática o siendo más específico, los comandos de los OS UNIX , no te digan nada; que un artículo como este haya llegado a portada, no creo que te haya impedido leer o comentar en cualquiera de los otros envíos que hay en la portada.

menéame