• 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.

    Leer en meneame.net | Noticia original

16 Comentarios

  1. mariopg /  hace 1 año

    entiendo que sea importante, y que medio menéame sean informáticos, pero que esto sea portada me parece demencial

    • MDman /  hace 1 año

      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.

    • uname /  hace 1 año

      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.

  2. Backs1ash /  hace 1 año

    # 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

    • bcc2c436cab /  hace 1 año


      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.

  3. bcc2c436cab /  hace 1 año

    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.

  4. Router_7 /  hace 1 año

    Estas cosas con Windows no pasan.

  5. blb /  hace 1 año

    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.

  6. anv /  hace 1 año

    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.

    • Aokromes /  hace 1 año

      con ip a te vale.

      • anv /  hace 1 año

        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:
        .

        • rastersoft /  hace 1 año

          En realidad, bastaría con añadir una línea en blanco entre interfaces... no es un cambio demasiado grande...

          • anv /  hace 1 año

            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:
            .

  7. stroke /  hace 1 año

    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

    • Tarkedo /  hace 1 año

      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.

      • stroke /  hace 1 año

        Tienes acciones de systemd o que?

        • Tarkedo /  hace 1 año

          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

      • anv /  hace 1 año

        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.

        • rastersoft /  hace 1 año

          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 que SOLO hace las funciones de init). Luego, dentro del proyecto "systemd" hay más utilidades, pero son binarios independientes y cada uno hace su tarea, para lanzar entornos CHROOT, para UDEV, LOGIN, LOGs, etc. Pero, y esta es la clave, cada uno es un binario que hace una sola cosa, y la hace bien, igual que en el UNIX original. De hecho, en muchos casos no es más que la herramienta original, que antes iba "a su bola" pero ahora está integrada dentro del mismo proyecto. La diferencia es que, dado que es inevitable que una herramienta dependa de otras, al estar en un proyecto paraguas te aseguras de que un cambio en una que afecte a las demás se corregirá de inmediato en ellas, en lugar de lo que pasaba antes, que cambiaban algo en un lado, y hasta un par de semanas después no salía la nueva versión de la herramienta X que fallaba por el cambio.

          Un ejemplo: ifconfig es una herramienta que hace una sola cosa y la hace bien, pero necesita que los datos en los ficheros virtuales de /proc estén en un formato concreto. Si un día los programadores de linux cambian ese formato por el motivo que sea, hay que modificar también ifconfig para que los reconozca. Si ifconfig está en un proyecto independiente del núcleo, si la comunicación entre ambos no es buena se producirán retardos y habrá un periodo en que habrá problemas.

          La idea de hacer "systemd" un proyecto paraguas no es otra que, precisamente, garantizar una buena comunicación entre todos los desarrolladores de los elementos clave del arranque del sistema y evitar estos problemas que pueden hacer que una máquina, directamente, no arranque. Pero cada utilidad dentro de él sigue "haciendo una sola cosa, y haciéndola bien".

    • kincho /  hace 1 año

      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...

  8. Pijus_Magnificus /  hace 1 año

    Mientras que podamos seguir eligiendo entre lo viejo y lo nuevo yo no veo problema en que existan nuevas herramientas.

  9. uxiaga /  hace 1 año

    Qué raro ver una meneo de esta categoría en portada

    • sleep_timer /  hace 1 año

      ¿Acabas de descubrir que meneame es frikilandia?
      (Me incluyo, eh)

      • JanSmite /  hace 1 año

        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

  10. headlesschicken /  hace 1 año

    Tampoco hay que correr en circulos gritando pudiendo desinstalar los paquetes obsoletos y creando aliases de los antiguos comandos con la nueva sintaxis.

  11. Aokromes /  hace 1 año

    ifconfig o ifconf o ipconfig o ipconf? bienvenido sea ip!

  12. llorencs /  hace 1 año

    Joder, tengo que reinstalarme Linux de ya y ponerme al día :-D

  13. musg0 /  hace 1 año

    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 haciendo algo ineficiente leyendo de los ficheros de /proc. ¿Dónde quedó eso de que todo en Unix es un fichero? ¿No estamos complicando y heterogeneizando el sistema con diferentes interfaces con la excusa del rendimiento?
    Antes mirabas en /proc si no alcanzabas a entender algún estado del sistema. Luego se inventaron /sys. Ahora igual tienes que mirar en los netlink esos y en el futuro vete a saber... Supongo que los desarrolladores saben porqué lo hacen, pero a veces están en su burbuja y ver más allá se hace difícil, con los consecuentes errores imprevistos o daños colaterales que no previeron

    • kyle /  hace 1 año

      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...

      • musg0 /  hace 1 año

        ¿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.

  14. KrilinUx /  hace 1 año

    El hispterismo llega hasta Linux ... Yo por el ifconfig mato, me entiendesssss ? MA-TO!!!!

  15. bcc2c436cab /  hace 1 año

    Partiendo de la base de que Linux no se administra, el artículo es erróneo. GNU o GNU{/,+,-}Linux. Linux -> núcleo.

    • GroumenHour /  hace 1 año

      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.

      • chuchete /  hace 1 año

        Pontelo en tu epitafio macho .... "Se dice GNU Linux copón!!!"

        • GroumenHour /  hace 1 año

          Y Naik se pronuncia naiki...
          pero el pueblo habla... mal... pero habla.

    • Backs1ash /  hace 1 año

      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.

      • MaF /  hace 1 año

        zascaaa

        • chavi /  hace 1 año

          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:

      • Miguel_Angel_Fernández_ /  hace 1 año

        Kame...hame... ha!!!! :-D

      • bcc2c436cab /  hace 1 año


        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 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f623a4d7000)
        www.gnu.org/software/libc/
         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f623a2ba000)
         /lib64/ld-linux-x86-64.so.2 (0x00007f623b1bd000)
        www.sourceware.org/binutils/

        De hecho el núcleo Linux está diseñado para pertenecer a GNU puesto que se compila con GCC y se usan las macros y API de dicho compilador. Las páginas de manual que hay en www.kernel.org contienen la versión de GNU.

        • uname /  hace 1 año

          Qué tendrá que ver como esté linkado un determinado binario con su diseño.

          • bcc2c436cab /  hace 1 año


            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.

            • StonyPriapus /  hace 1 año

              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.

              • bcc2c436cab /  hace 1 año


                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).

                • StonyPriapus /  hace 1 año

                  EDITADO: Le di a enviar sin querer

                  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 46 02 01 01 00 00 00 00 00 00 00 00 00
                  Class: ELF64
                  Data: 2's complement, little endian
                  Version: 1 (current)
                  OS/ABI: UNIX - System V
                  ABI Version: 0
                  Type: DYN (Shared object file)
                  Machine: Advanced Micro Devices X86-64
                  Version: 0x1
                  Entry point address: 0xba00
                  Start of program headers: 64 (bytes into file)
                  Start of section headers: 590520 (bytes into file)
                  Flags: 0x0
                  Size of this header: 64 (bytes)
                  Size of program headers: 56 (bytes)
                  Number of program headers: 11
                  Size of section headers: 64 (bytes)
                  Number of section headers: 30
                  Section header string table index: 29

                  El formato del binario en si es ELF generico, no tiene ninguna extensión GNU. En las secciones solo mete información del compilador:
                  $ readelf --sections /sbin/ip
                  There are 30 section headers, starting at offset 0x902b8:

                  Section Headers:
                  [Nr] Name Type Address Offset
                  Size EntSize Flags Link Info Align
                  [ 0] NULL 0000000000000000Â00000000
                  0000000000000000Â0000000000000000 0 0 0
                  [ 1] .interp PROGBITS 00000000000002a8Â000002a8
                  000000000000001c 0000000000000000 A 0 0 1
                  [ 2] .note.ABI-tag NOTE 00000000000002c4Â000002c4
                  0000000000000020Â0000000000000000 A 0 0 4
                  [ 3] .note.gnu.propert NOTE 00000000000002e8Â000002e8
                  0000000000000030Â0000000000000000 A 0 0 8
                  [ 4] .note.gnu.build-i NOTE 0000000000000318Â00000318
                  0000000000000024Â0000000000000000 A 0 0 4
                  [ 5] .gnu.hash GNU_HASH 0000000000000340Â00000340
                  0000000000000c3c 0000000000000000 A 6 0 8
                  [ 6] .dynsym DYNSYM 0000000000000f80Â00000f80
                  0000000000003330Â0000000000000018 A 7 1 8
                  [ 7] .dynstr STRTAB 00000000000042b0Â000042b0
                  0000000000001b86Â0000000000000000 A 0 0 1
                  [ 8] .gnu.version VERSYM 0000000000005e36Â00005e36
                  0000000000000444Â0000000000000002 A 6 0 2
                  [ 9] .gnu.version_r VERNEED 0000000000006280Â00006280
                  00000000000000f0Â0000000000000000 A 7 4 8
                  [10] .rela.dyn RELA 0000000000006370Â00006370
                  00000000000037e0Â0000000000000018 A 6 0 8
                  [11] .rela.plt RELA 0000000000009b50Â00009b50
                  0000000000000e58Â0000000000000018 AI 6 23 8
                  [12] .init PROGBITS 000000000000a9a8Â0000a9a8
                  0000000000000017Â0000000000000000 AX 0 0 4
                  [13] .plt PROGBITS 000000000000a9c0Â0000a9c0
                  00000000000009a0Â0000000000000010 AX 0 0 16
                  [14] .text PROGBITS 000000000000b360Â0000b360
                  0000000000056e31Â0000000000000000 AX 0 0 16
                  [15] .fini PROGBITS 0000000000062194Â00062194
                  0000000000000009Â0000000000000000 AX 0 0 4
                  [16] .rodata PROGBITS 00000000000621a0Â000621a0
                  0000000000013c19Â0000000000000000 A 0 0 32
                  [17] .eh_frame_hdr PROGBITS 0000000000075dbc 00075dbc
                  0000000000001444Â0000000000000000 A 0 0 4
                  [18] .eh_frame PROGBITS 0000000000077200Â00077200
                  0000000000008868Â0000000000000000 A 0 0 8
                  [19] .init_array INIT_ARRAY 0000000000280790Â00080790
                  0000000000000008Â0000000000000008 WA 0 0 8
                  [20] .fini_array FINI_ARRAY 0000000000280798Â00080798
                  0000000000000008Â0000000000000008 WA 0 0 8
                  [21] .data.rel.ro PROGBITS 00000000002807a0Â000807a0
                  0000000000001110Â0000000000000000 WA 0 0 32
                  [22] .dynamic DYNAMIC 00000000002818b0Â000818b0
                  0000000000000230Â0000000000000010 WA 7 0 8
                  [23] .got PROGBITS 0000000000281ae0Â00081ae0
                  0000000000000518Â0000000000000008 WA 0 0 8
                  [24] .data PROGBITS 0000000000282000Â00082000
                  0000000000005c40Â0000000000000000 WA 0 0 32
                  [25] .bss NOBITS 0000000000287c40Â00087c40
                  0000000000049dd0Â0000000000000000 WA 0 0 32
                  [26] .gnu.build.attrib NOTE 0000000000000000Â00087c40
                  0000000000006900Â0000000000000000 0 0 4
                  [27] .gnu_debuglink PROGBITS 0000000000000000Â0008e540
                  0000000000000024Â0000000000000000 0 0 4
                  [28] .gnu_debugdata PROGBITS 0000000000000000Â0008e564
                  0000000000001c18Â0000000000000000 0 0 1
                  [29] .shstrtab STRTAB 0000000000000000Â0009017c
                  0000000000000135Â0000000000000000 0 0 1
                  Key to Flags:
                  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
                  L (link order), O (extra OS processing required), G (group), T (TLS),
                  C (compressed), x (unknown), o (OS specific), E (exclude),
                  l (large), p (processor specific)


                  Esas secciones se pueden quitar si haces un strip del binario. Son fundamentalmente los DWARF. Pero porque está compilado en fedora. Si lo compilas con clang no tiene nada de eso.

                  • bcc2c436cab /  hace 1 año


                    $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
                    0x000000000007ead8 0x000000000007ead8 R E 0x200000
                    LOAD 0x000000000007f7d0 0x000000000027f7d0 0x000000000027f7d0
                    0x0000000000007470 0x0000000000051240 RW 0x200000
                    DYNAMIC 0x00000000000808d0 0x00000000002808d0 0x00000000002808d0
                    0x0000000000000220 0x0000000000000220 RW 0x8
                    NOTE 0x0000000000000254 0x0000000000000254 0x0000000000000254
                    0x0000000000000044 0x0000000000000044 R 0x4
                    GNU_EH_FRAME 0x000000000007501c 0x000000000007501c 0x000000000007501c
                    0x000000000000143c 0x000000000000143c R 0x4
                    GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
                    0x0000000000000000 0x0000000000000000 RW 0x10
                    GNU_RELRO 0x000000000007f7d0 0x000000000027f7d0 0x000000000027f7d0
                    0x0000000000001830 0x0000000000001830 R 0x1

                    • StonyPriapus /  hace 1 año

                      Eso no son secciones, son cabeceras, y las ha metido el linker, insisto, si lo compilas con llvm no estrían

                  • bcc2c436cab /  hace 1 año


                    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.

                    • StonyPriapus /  hace 1 año

                      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.

                      • bcc2c436cab /  hace 1 año


                        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é.

            • uname /  hace 1 año

              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 ser que solo uses software GNU con Linux.

              Lo de imponer a todo el mundo llamar GNU/Linux viene de cuando no salía HURD adelante y ya tenían hecho el resto de aplicaciones, utilidades y librerías, solo les faltaban acabar el kernel y entonces Linus publicó el suyo con licencia GPL, las distribuciones y la gente los combinaba y a todo ello lo llamaban Linux. Como es lógico que la gente lo llamase solamente Linux causó la irritación de Stallman, ya que era un sistema basado en un kernel relativamente sencillo y mientras las herramientas GNU con mucho curro detrás y que son las que hacen realmente útil un sistema operativo, pasaban al olvido.

              Pero a día de hoy que se usa mucho software que no es GNU, me parece más justo decir "sistemas basados en Linux" o "sistemas Linux" o ponga el nombre de su distribución aquí. Es decir, kernel Linux y el resto.

              ¿Porqué si mi distribución tiene Apache, OpenSSH y Firefox no tengo que decir entonces que uso OpenBSD/Apache/Mozilla/GNU con Linux?

              • bcc2c436cab /  hace 1 año


                Sinceramente, cualquiera que lea el hilo de comentarios encontrará una explicación a todo lo que cuestionas.

        • StonyPriapus /  hace 1 año


          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.

          • bcc2c436cab /  hace 1 año


            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.

            • StonyPriapus /  hace 1 año

              Es que ip no está diseñado para GNU, está diseñado para linux.

              • bcc2c436cab /  hace 1 año


                Está diseñado para GNU y otros sistemas operativos como FreeBSD.

                • StonyPriapus /  hace 1 año

                  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 AF_NETLINK, que al final es meter en la lista de protocolos una entrada con #define AF_NETLINK 16 (si, he ido a buscarlo)

                  Otra cosa es que algunos BSD hayan implementado netlink porque les convenció igual que linux probablemente acabe implementando pledge de openBSD.

                  1- git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/co
                  2- pdfs.semanticscholar.org/6efd/e161a2582ba5846e4b8fea5a53bc305a64f3.pdf
                  3- wiki.linuxfoundation.org/networking/iproute2

                  • bcc2c436cab /  hace 1 año


                    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 Libc:

                    ./sysdeps/mach/hurd/ifaddrs.c
                    ./sysdeps/unix/sysv/linux/bits/socket.h
                    ./sysdeps/unix/sysv/linux/mq_notify.c
                    ./sysdeps/unix/sysv/linux/Versions
                    ./sysdeps/unix/sysv/linux/if_index.c
                    ./sysdeps/unix/sysv/linux/check_pf.c
                    ./sysdeps/unix/sysv/linux/Makefile
                    ./sysdeps/unix/sysv/linux/netlink_assert_response.c
                    ./sysdeps/unix/sysv/linux/netlinkaccess.h
                    ./sysdeps/unix/sysv/linux/ifaddrs.c
                    ./sysdeps/unix/sysv/linux/check_native.c
                    ./nscd/connections.c
                    ./nscd/nscd-client.h
                    ./nscd/selinux.c

                    • StonyPriapus /  hace 1 año

                      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.

                      • bcc2c436cab /  hace 1 año


                        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.

    • anv /  hace 1 año

      Estás confundiendo la acepción secundaria "núcleo" por la acepción primaria "sistema que usa ese núcleo".

      • bcc2c436cab /  hace 1 año


        Estamos hablando de un nombre propio, no tiene significado. No tiene definición.

        • anv /  hace 1 año

          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.

          • bcc2c436cab /  hace 1 año


            Que no tenga significado no significa que no tenga sentido.

  16. Hopo /  hace 1 año

    Ala.. a cambiar los scripts :wall:

    • ccguy /  hace 1 año

      Bueno, teniendo en cuenta que algunas herramientas como ifconfig se las han cargado igualmente y su salida ya no es igual que antes...

    • ubicuamente /  hace 1 año

      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.

      • Hopo /  hace 1 año

        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

        • Backs1ash /  hace 1 año

          te recomiendo aprovechar la situación y aprender a usar ip que es mucho más versátil y potente

    • empanadilla.cosmica /  hace 1 año

      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.

      • weboncin /  hace 1 año

        una buena oportunidad para intentar hacer correr ese software en contenedores ;)

        • Garrosh /  hace 1 año

          ¿Contenedores Linux o de la basura? :shit:

          • kyle /  hace 1 año

            no son lo mismo? :roll:

        • empanadilla.cosmica /  hace 1 año

          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. Además de algunos casos de éxito tenemos algunos casos de sonados fracasos.

          Lo mismo con Solaris. Al mes de estar todo funcionando en un nuevo entorno nos llegan quejas de que ciertas funcionalidades ya no funcionan.

          Y dependiendo de cómo funcione el contenedor se pierden algunas carateristicas que en la máquina física se tenían y que no conviene perder.

          El mundo de los sistemas legacy es apasionante.

      • JanSmite /  hace 1 año

        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?

        • empanadilla.cosmica /  hace 1 año

          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 que muestre la salida como la muestra ifconfig, pero hay casos donde no es posible.

          Luego hay que pensar en quien viene después. Cuando uso ifconfig quiero la salida de ifconfig y cuando uso ip la que muestra IP. Espero que mi predecesor no me haya hecho ñapas de eliminar binarios básicos y cambiármelos por scripts que igual mañana me dejan de funcionar.

Ofertas

Loader noticialalminuto

Volver arriba

Esta web utiliza cookies, puedes ver nuestra política de cookies, aquí Si continuas navegando estás aceptándola