Re: net-tools future
On Mittwoch, 25. März 2009, Gunnar Wolf wrote: Munin ... does not support alerting It does. Directly or via nagios. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: net-tools future
Manoj Srivastava dijo [Sat, Mar 21, 2009 at 09:54:42AM -0500]: Err, isn't munin a hugely complex beasty, that has to be configured for the network, and usually lives on a signle machine and polls others? and does alerting and graphing and is a pain to configure? On the other hand, netstat -r, netstat -i, netstat -al just work? Am I missing something, since munin is seen as a replacement for netstat? Munin is actually a quite simple and extendable framework for centralized infrastructure monitoring, almost trivial to configure (although you can come up with some pretty involved/complicated setups, but for most situations it is quite trivial). It does not support alerting, only monitoring and (offline, static, cron-based) graphing. It is by far not a replacement for netstat - it uses netstat as a source for many of its queries. -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Marco d'Itri dijo [Fri, Mar 20, 2009 at 12:14:53PM +0100]: trouble for embedded or limited ones. I don't do embedded personally so I have no idea how udev fares there, but I can tell you that vservers and udev don't go well together. Udev expects a real system where there's none and then gets confused -- vserver is hardly more than a glorified chroot, nearly identical to BSD jails. You want every container to be small and simple. This is why you install udev in the host system and bind-mount its /dev to the /dev of each context. vserver and openvz are not relevant for the purpose of this discussion. !?! $ sudo vserver backups enter # ls /dev/ core full log ptmx ram shm stdin tty xconsole fdinitctl null pts random stderr stdout urandom zero # mount /dev/hdv1 on / type ufs (defaults) none on /proc type proc (defaults) none on /tmp type tmpfs (size=16m,mode=1777) none on /dev/pts type devpts (gid=5,mode=620) # mknod /dev/sda b 8 0 mknod: `/dev/sda': Operation not permitted Yes, there is a small perception bug here (i.e. there is no /dev/hdv1), but still - I don't want a vserver to be able to mess with any of my physical devices! -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Henrique de Moraes Holschuh h...@debian.org (16/03/2009): So, ethtool really needs to grow an option to iterate over all netdevs, and another one to print a summary of link state and speed,duplex before mii-tool could be dropped. I won't promise anything, but I'm interested in having a look, time permitting. Mraw, KiBi. signature.asc Description: Digital signature
Re: net-tools future
On Mon, 23 Mar 2009, Cyril Brulebois wrote: Henrique de Moraes Holschuh h...@debian.org (16/03/2009): So, ethtool really needs to grow an option to iterate over all netdevs, and another one to print a summary of link state and speed,duplex before mii-tool could be dropped. I won't promise anything, but I'm interested in having a look, time permitting. Thank you! -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Sun, Mar 22, 2009 at 01:17:01AM +0100, Marco d'Itri wrote: On Mar 21, Wouter Verhelst wou...@debian.org wrote: While 1.6% is indeed a rather small amount, I wouldn't call 1340 people 'trivial'. I do, since I expect that most of these are using sarge or worse. There's no proof of that. Personally, I disagree. That would be a good argument if you were to explain how, exactly, it would make other packages more complex. Can you give an example, please? The second-last alsa-base release is a good example. *sigh* please try to make your arguments be actual arguments, rather than random handwavering. None of the recent alsa-base changelog entries explain how not having udev makes things more complex, and I'm not going to read the source. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Sun, Mar 22, 2009 at 10:55:58AM +0100, Florian Weimer wrote: * Wouter Verhelst: On Sat, Mar 21, 2009 at 10:53:55PM +0100, Florian Weimer wrote: * Bernd Zeimetz: Being able to rename an interface without messing with udev is a feature, not a bug. I think you can't rename most interfaces after the boot process anyway. Or has the kernel been changed and can rename interfaces which are in use? How on earth does 'network interface is in use' correlate to 'the system is booting'? ip link set dev down ip addr flush dev dev rename address Hmm, this did not really work a couple of years ago once there was some process using the network interface in a substantial way. If you do 'ip link set dev down' followed by 'ip addr flush dev dev', then every piece of software using the link will get an immediate ICMP 'network unreachable' back from the kernel (unless the network is reachable through another interface, of course). This should deal with such issues. I see this has improved (and libpcap runs into an infinite loop, yay). To be honest, I haven't tried it. I could imagine that using raw sockets on a NIC would require a bit more work than the above. In any case, my point was that it's not like you can't make processes stop using a NIC. Once you've done that, renaming a NIC should pose no problems. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
* Wouter Verhelst: On Sat, Mar 21, 2009 at 10:53:55PM +0100, Florian Weimer wrote: * Bernd Zeimetz: Being able to rename an interface without messing with udev is a feature, not a bug. I think you can't rename most interfaces after the boot process anyway. Or has the kernel been changed and can rename interfaces which are in use? How on earth does 'network interface is in use' correlate to 'the system is booting'? ip link set dev down ip addr flush dev dev rename address Hmm, this did not really work a couple of years ago once there was some process using the network interface in a substantial way. I see this has improved (and libpcap runs into an infinite loop, yay). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Hi Luk, On Freitag, 20. März 2009, Luk Claes wrote: Below a list of packages/maintainers that use ifconfig/route/netstat: How did you create that list? You seem to be missing a few.. ifconfig + route sitesummary netstat --- munin ifconfig fai debian-edu-config regards, Holger signature.asc Description: This is a digitally signed message part.
Re: net-tools future
Holger Levsen wrote: Hi Luk, On Freitag, 20. März 2009, Luk Claes wrote: Below a list of packages/maintainers that use ifconfig/route/netstat: How did you create that list? You seem to be missing a few.. By looking at dependency relations with the net-tools package. I guess some packages use net-tools if available and otherwise fallback to something else? Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Holger Levsen wrote: Hi Luk, On Freitag, 20. März 2009, Luk Claes wrote: Below a list of packages/maintainers that use ifconfig/route/netstat: How did you create that list? You seem to be missing a few.. By looking at dependency relations with the net-tools package. I guess some packages use net-tools if available and otherwise fallback to something else? In that case, Holger actually listed packages that lack proper Depends: ... :-) Best, Michael pgpcH5Dh7YK49.pgp Description: PGP signature
Re: net-tools future
On Sun, Mar 15, 2009 at 02:30:18PM -0300, Martín Ferrari wrote: About the wrapper scripts: * ipconfig, route: the most difficult ones, both can be replaced by calls to ip, maybe except for some obscure options. Suggestion about the wrapper scripts. It would be nice if they had a mode enabled by an environment variable or a command-line option which printed the equivalent ip commands which they issued, so people can learn the new ip interface if they are so interested. Also, I'd recommend making the scripts carefully cover 100% of the ifconfig, route, and netstat commands, since these commands have a very long history, and are extremely well known by many sysadmins, and used in many, *many* shell scripts. - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Hi Luk, On Samstag, 21. März 2009, Luk Claes wrote: Below a list of packages/maintainers that use ifconfig/route/netstat: How did you create that list? You seem to be missing a few.. By looking at dependency relations with the net-tools package. I guess some packages use net-tools if available and otherwise fallback to something else? Sadly I think thats wishful thinking at least in the case of the four packages I mentioned. munin uses netstat only in the netstat plugin. I've now added a suggests (in svn) on the assumption that netstat is a rather common plugin. We dont want to suggest asterisk just because there is a plugin to monitor it :) debian-edu-config might be covered through one of its depends (but it doesnt seem so, not even lsb depends net-tools, so I just added a depends in svn). sitesummary misses it, so I fixed it in svn. fai uses it in three binary packages: fai-server, fai-client and fai-doc. I'll follow up on this on the fai-list. regards, Holger (maintainer role-addresses bcc:ed.) signature.asc Description: This is a digitally signed message part.
Re: net-tools future
Holger Levsen wrote: Hi Luk, Hi Holger On Samstag, 21. März 2009, Luk Claes wrote: Below a list of packages/maintainers that use ifconfig/route/netstat: How did you create that list? You seem to be missing a few.. By looking at dependency relations with the net-tools package. I guess some packages use net-tools if available and otherwise fallback to something else? Sadly I think thats wishful thinking at least in the case of the four packages I mentioned. munin uses netstat only in the netstat plugin. I've now added a suggests (in svn) on the assumption that netstat is a rather common plugin. We dont want to suggest asterisk just because there is a plugin to monitor it :) debian-edu-config might be covered through one of its depends (but it doesnt seem so, not even lsb depends net-tools, so I just added a depends in svn). sitesummary misses it, so I fixed it in svn. fai uses it in three binary packages: fai-server, fai-client and fai-doc. I'll follow up on this on the fai-list. Note that we want packages to stop using net-tools, so you might want to fix that as well :-) Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Mar 21, 2009 at 02:10:40PM +0100, Holger Levsen wrote: munin uses netstat only in the netstat plugin. I've now added a suggests (in svn) on the assumption that netstat is a rather common plugin. We dont want to suggest asterisk just because there is a plugin to monitor it :) Why not? The purpose of Suggests: is exactly to declare non-important relationship. From Policy 7.2: This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. Kind regards, - Jonas P.S. Please cc me on responses: I am not subscribed to -devel - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknE7asACgkQn7DbMsAkQLjc2wCfXHR73zu54jsTcaEQVJcAI6qe oa8An358Gj3WDQd4c15f8B/e7ZscveJn =ax17 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
munin-plugin enhances.. (Re: net-tools future
Hi Jonas, On Samstag, 21. März 2009, Jonas Smedegaard wrote: plugin. We dont want to suggest asterisk just because there is a plugin to monitor it :) Why not? The purpose of Suggests: is exactly to declare non-important relationship. From Policy 7.2: True, but IMO it's the other way round: asterisk should suggest munin-node, to monitor it's performance. munin-node could probably make use of the enhances: field, which has been proposed sometime. (I dont remember its exact status.) Else munin-node would suggest a lot of software, which IMO doesnt fit. Please cc me on responses: I am not subscribed to -devel done. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: net-tools future
On Sat, Mar 21 2009, Holger Levsen wrote: netstat --- munin Err, isn't munin a hugely complex beasty, that has to be configured for the network, and usually lives on a signle machine and polls others? and does alerting and graphing and is a pain to configure? On the other hand, netstat -r, netstat -i, netstat -al just work? Am I missing something, since munin is seen as a replacement for netstat? manoj -- I've noticed several design suggestions in your code. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Manoj Srivastava wrote: On Sat, Mar 21 2009, Holger Levsen wrote: netstat --- munin Err, isn't munin a hugely complex beasty, that has to be configured for the network, and usually lives on a signle machine and polls others? and does alerting and graphing and is a pain to configure? On the other hand, netstat -r, netstat -i, netstat -al just work? Am I missing something, since munin is seen as a replacement for netstat? This lists are not replacements for tools from net-tools, but lists of packages using tools from net-tools. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Hi, On Samstag, 21. März 2009, Manoj Srivastava wrote: Err, isn't munin a hugely complex beasty, that has to be configured for the network, and usually lives on a signle machine and polls others? and does alerting and graphing and is a pain to configure? actually you just do sudo apt-get install munin munin-node and point your webbrowser to http://127.0.0.1/munin/ and are done for a single host. for multiple hosts its editing one file on the node to allow the server to access it, and tell the server to do so (by editing another simple file). Configuring extra plugins is a bit more work, though many services munin can monitor are autoconfigured. (And configuring a plugin involves creating a link to activate the plugin and then putting some configuration in into /etc/munin/plugin-conf.d/ - usually stuff like the disk to monitor by the smart plugin or the credentials to access databases or such.) Really not a big deal. Am I missing something, since munin is seen as a replacement for netstat? You missed what Luk pointed out, but I felt like clarifying the above as well :-) regards, Holger signature.asc Description: This is a digitally signed message part.
Re: net-tools future
* Bernd Zeimetz: Kill it ASAP, it's not compatible with udev. Being able to rename an interface without messing with udev is a feature, not a bug. I think you can't rename most interfaces after the boot process anyway. Or has the kernel been changed and can rename interfaces which are in use? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Fri, Mar 20, 2009 at 10:53:19AM +0100, Marco d'Itri wrote: On Mar 20, Wouter Verhelst wou...@debian.org wrote: It is still possible to install and run Lenny without the use of udev, and many people do so. popcon shows that the number is trivial. Definitely not many. popcon tells me that there are 82953 people who have udev installed, and that this is 98.41% of the total amount of people who do popcon submission. 82953*100/98.41 = 84293 This means that of those who have popcon running, there are 1340 people who do not use udev. While 1.6% is indeed a rather small amount, I wouldn't call 1340 people 'trivial'. Moreover, while popcon is useful to order packages so that we can decide which package goes on which CD, I would be _very_ wary of using it to justify throwing software out of the archive. To be representative, statistical data has to be drawn from a *random* subgroup of people. This does not happen with popcon; as such, it is not entirely reliable. Whether you agree that this is useful or a 'toy' setup is beside the point; fact is that it happens, and if people want to work on this so that it remains being supported, why not? Because it makes other packages more complex. That would be a good argument if you were to explain how, exactly, it would make other packages more complex. Can you give an example, please? -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Sat, Mar 21, 2009 at 10:53:55PM +0100, Florian Weimer wrote: * Bernd Zeimetz: Being able to rename an interface without messing with udev is a feature, not a bug. I think you can't rename most interfaces after the boot process anyway. Or has the kernel been changed and can rename interfaces which are in use? How on earth does 'network interface is in use' correlate to 'the system is booting'? ip link set dev down ip addr flush dev dev rename address -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mar 21, Wouter Verhelst wou...@debian.org wrote: While 1.6% is indeed a rather small amount, I wouldn't call 1340 people 'trivial'. I do, since I expect that most of these are using sarge or worse. That would be a good argument if you were to explain how, exactly, it would make other packages more complex. Can you give an example, please? The second-last alsa-base release is a good example. -- ciao, Marco signature.asc Description: Digital signature
Re: net-tools future
On Sun, Mar 15, 2009 at 11:07:29PM +0100, Marco d'Itri wrote: On Mar 15, Bernd Zeimetz be...@bzed.de wrote: Being able to rename an interface without messing with udev is a feature, not a bug. Every relevant Linux distribution requires udev, and so do many important features of Debian systems. Anything not compatible with udev is a toy which wastes space in the archive. Welcome to 2008. It is still possible to install and run Lenny without the use of udev, and many people do so. Whether you agree that this is useful or a 'toy' setup is beside the point; fact is that it happens, and if people want to work on this so that it remains being supported, why not? -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Tue, Mar 17, 2009 at 09:05:53AM +0100, Bjørn Mork wrote: Ben Hutchings b...@decadent.org.uk writes: You can do this with ethtool now, and more cleanly: link-speed 100 link-duplex full Yes, I know. But that means that existing working configurations have to be modified. Which should not be an argument to hold back progress. Every release upgrade contains with it such cases, and they are all handled, either through documentation in /usr/share/doc/relevant package, or through meta packages, or through the release notes. This is no different. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Fri, Mar 20, 2009 at 09:57:13AM +0100, Wouter Verhelst wrote: On Sun, Mar 15, 2009 at 11:07:29PM +0100, Marco d'Itri wrote: Every relevant Linux distribution requires udev, and so do many important features of Debian systems. Anything not compatible with udev is a toy which wastes space in the archive. Welcome to 2008. It is still possible to install and run Lenny without the use of udev, and many people do so. Whether you agree that this is useful or a 'toy' setup is beside the point; fact is that it happens, and if people want to work on this so that it remains being supported, why not? I wouldn't call small systems a 'toy'. udev is desired, nearly required for big systems, right. It's bloat and trouble for embedded or limited ones. I don't do embedded personally so I have no idea how udev fares there, but I can tell you that vservers and udev don't go well together. Udev expects a real system where there's none and then gets confused -- vserver is hardly more than a glorified chroot, nearly identical to BSD jails. You want every container to be small and simple. A vserver is a valid Debian system, and certainly not a waste of archive space. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mar 20, Wouter Verhelst wou...@debian.org wrote: It is still possible to install and run Lenny without the use of udev, and many people do so. popcon shows that the number is trivial. Definitely not many. Whether you agree that this is useful or a 'toy' setup is beside the point; fact is that it happens, and if people want to work on this so that it remains being supported, why not? Because it makes other packages more complex. -- ciao, Marco signature.asc Description: Digital signature
Re: net-tools future
Twas brillig at 10:50:23 20.03.2009 UTC+01 when kilob...@angband.pl did gyre and gimble: AB It's bloat and trouble for embedded or limited ones. mdev from busybox kicks in there. -- pgpoBcZgEVOcl.pgp Description: PGP signature
Re: net-tools future
On Fri March 20 2009 02:53:19 Marco d'Itri wrote: On Mar 20, Wouter Verhelst wou...@debian.org wrote: It is still possible to install and run Lenny without the use of udev, and many people do so. popcon shows that the number is trivial. Definitely not many. Perhaps sysadmins that go to the effort of removing udev from some systems are less likely to install popcon on those systems? --Mike Bird -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mar 20, Adam Borowski kilob...@angband.pl wrote: udev is desired, nearly required for big systems, right. It's bloat and It's not. trouble for embedded or limited ones. I don't do embedded personally so I have no idea how udev fares there, but I can tell you that vservers and udev don't go well together. Udev expects a real system where there's none and then gets confused -- vserver is hardly more than a glorified chroot, nearly identical to BSD jails. You want every container to be small and simple. This is why you install udev in the host system and bind-mount its /dev to the /dev of each context. vserver and openvz are not relevant for the purpose of this discussion. On Mar 20, Mike Bird mgb-deb...@yosemite.net wrote: popcon shows that the number is trivial. Definitely not many. Perhaps sysadmins that go to the effort of removing udev from some systems are less likely to install popcon on those systems? And surely lurkers agree with you in personal emails... -- ciao, Marco signature.asc Description: Digital signature
Re: net-tools future
Le vendredi 20 mars 2009 à 12:14 +0100, Marco d'Itri a écrit : This is why you install udev in the host system and bind-mount its /dev to the /dev of each context. Erm… no, you don’t. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: net-tools future
m...@linux.it (Marco d'Itri) writes: On Mar 20, Mike Bird mgb-deb...@yosemite.net wrote: popcon shows that the number is trivial. Definitely not many. Perhaps sysadmins that go to the effort of removing udev from some systems are less likely to install popcon on those systems? And surely lurkers agree with you in personal emails... Marco, it was you that cited absence of evidence (the low popcon score) as evidence of absence. You don't get to accuse Adam of doing the same, especially since he's not doing it. -- \ “Any intelligent fool can make things bigger and more complex… | `\It takes a touch of genius – and a lot of courage – to move in | _o__)the opposite direction.” —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Fri, Mar 20, 2009 at 12:14:53PM +0100, Marco d'Itri wrote:
On Mar 20, Adam Borowski kilob...@angband.pl wrote:
trouble for embedded or limited ones. I don't do embedded personally so I
have no idea how udev fares there, but I can tell you that vservers and udev
don't go well together. Udev expects a real system where there's none and
then gets confused -- vserver is hardly more than a glorified chroot, nearly
identical to BSD jails. You want every container to be small and simple.
This is why you install udev in the host system and bind-mount its /dev
to the /dev of each context.
Definitely wrong.
Only a tiny sliver of devices are accessible from inside a context, and
making others accessible would be bad. Even root can't create forbidden
devices from inside...
vserver and openvz are not relevant for the purpose of this discussion.
They have their specific needs, and the last time I checked, udev couldn't
fulfill them. You need just /dev/{null,zero,full,random,urandom,tty,ptmx}
and the links to /proc/. More may be needed, but that depends on the
context's capabilities rather than on modules being present. A vserver may
have /dev/kqemu, /dev/fuse, /dev/net/tun, ...
On Mar 20, Mike Bird mgb-deb...@yosemite.net wrote:
popcon shows that the number is trivial. Definitely not many.
Perhaps sysadmins that go to the effort of removing udev from
some systems are less likely to install popcon on those systems?
And surely lurkers agree with you in personal emails...
If you insist on popcon being installed on such systems, I may arrange a
bunch. I'm not sure if Debian would be well-served by a slew popcon
submissions of: (minimal+bind), (minimal+apache+mod_perl), (minimal+...),
though.
Rawr?!?
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mar 20, Adam Borowski kilob...@angband.pl wrote:
They have their specific needs, and the last time I checked, udev couldn't
fulfill them. You need just /dev/{null,zero,full,random,urandom,tty,ptmx}
and the links to /proc/. More may be needed, but that depends on the
You keep missing the point. udev matters in the host system, not in each
context. You will also not install in the contexts SANE or alsa-base or
kvm or Gnome.
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: net-tools future
On Fri, Mar 20, 2009 at 01:03:32PM +0100, Marco d'Itri wrote:
On Mar 20, Adam Borowski kilob...@angband.pl wrote:
They have their specific needs, and the last time I checked, udev couldn't
fulfill them. You need just /dev/{null,zero,full,random,urandom,tty,ptmx}
and the links to /proc/. More may be needed, but that depends on the
You keep missing the point. udev matters in the host system, not in each
context.
Do you mean the original point of this thread, about ifrename (which indeed
can't be used inside vserver or openvz, can be in xen)? Or do you mean
other uses of udev?
You will also not install in the contexts SANE
Probably.
or alsa-base
Right.
or kvm
That's pretty useful. I used to run qemu from a vserver.
or Gnome.
I have Gnome installed on a sid vserver, used it no farther than a couple of
days ago to test something.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mar 20, Adam Borowski kilob...@angband.pl wrote: You keep missing the point. udev matters in the host system, not in each context. Do you mean the original point of this thread, about ifrename (which indeed can't be used inside vserver or openvz, can be in xen)? Or do you mean other uses of udev? About udev in general. I have Gnome installed on a sid vserver, used it no farther than a couple of days ago to test something. Then you had to have udev installed, because it's a dependency of gnome-volume-manager. -- ciao, Marco signature.asc Description: Digital signature
Re: net-tools future
On Fri, Mar 20, 2009 at 02:37:44PM +0100, Marco d'Itri wrote: On Mar 20, Adam Borowski kilob...@angband.pl wrote: You keep missing the point. udev matters in the host system, not in each context. Do you mean the original point of this thread, about ifrename (which indeed can't be used inside vserver or openvz, can be in xen)? Or do you mean other uses of udev? About udev in general. udev is needed to allow for complex and/or hotplugged hardware. Small systems have either little, static hardware, or no hardware at all. I have Gnome installed on a sid vserver, used it no farther than a couple of days ago to test something. Then you had to have udev installed, because it's a dependency of gnome-volume-manager. Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==-= pn udev none (no description available) Indeed, that's how I learned that udev breaks vservers. That's in a good part my fault, I installed the whole bulk of Gnome without trimming things utterly useless on a headless box. gnome-volume-manager has no place there. But, let's return to the original claim which I disagree with: Every relevant Linux distribution requires udev, and so do many important features of Debian systems. Anything not compatible with udev is a toy which wastes space in the archive. Welcome to 2008. I can agree that there's no need to support _hardware-related_ things which are incompatible with udev. Yet, pieces of Debian which do not need to talk to hardware directly (ie, 95% of the archive) should not require udev. I also say that systems without udev installed are legitimate. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Twas brillig at 15:30:11 20.03.2009 UTC+01 when kilob...@angband.pl did gyre and gimble: AB udev is needed to allow for complex and/or hotplugged hardware. AB Small systems have either little, static hardware, Small systems nowadays have a lot of hotplugged hardware: various USB devices, from mass storage to printers, SD and other storage cards. AB or no hardware at all. :) -- pgpFyhR31wSQ4.pgp Description: PGP signature
Re: net-tools future
On Fri, Mar 20, 2009 at 11:13:45PM +1100, Ben Finney wrote: m...@linux.it (Marco d'Itri) writes: On Mar 20, Mike Bird mgb-deb...@yosemite.net wrote: popcon shows that the number is trivial. Definitely not many. Perhaps sysadmins that go to the effort of removing udev from some systems are less likely to install popcon on those systems? And surely lurkers agree with you in personal emails... Marco, it was you that cited absence of evidence (the low popcon score) as evidence of absence. You don't get to accuse Adam of doing the same, especially since he's not doing it. I think he gets to accuse Mike Bird of anything he wants to. I accuse Mike Bird of being a dolomite. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Martín Ferrari wrote: Hi, Hi In our call to move away from net-tools, I want to first start with identifying the packages that still use it: * ifconfig, route: the most difficult ones, both can be replaced by calls to ip, maybe except for some obscure options. * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line Below a list of packages/maintainers that use ifconfig/route/netstat: Note that I divided them according the use of one or more of the tools (with what appear to be false positives at the end): ifconfig + route + netstat -- Simon Horman ho...@debian.org heartbeat pacemaker (U) Anibal Monsalve Salazar ani...@debian.org pacemaker ifconfig + route Achim Bohnet a...@mpe.mpg.de knemo (U) Bruno Barrera C. br...@debian.org portsentry Kanru Chen kos...@debian.org.tw tspc Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org knemo Thomas Goirand tho...@goirand.fr dtc Alberto Gonzalez Iniesta a...@inittab.org openvpn Mark Purcell m...@debian.org knemo (U) Petter Reinholdtsen p...@debian.org ifupdown (U) Al Stone a...@debian.org laptop-net Anthony Towns a...@debian.org ifupdown ifconfig + netstat -- Micah Anderson mi...@debian.org rkhunter (U) Daniel Baumann dan...@debian.org gnunet Christoph Berg m...@debian.org irssi-scripts Fathi Boudra f...@debian.org kvpnc (U) Marc 'HE' Brockschmidt h...@debian.org firehol (U) Kanru Chen kos...@debian.org.tw tspc Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org kvpnc Debian QA Group packa...@qa.debian.org ion3-scripts Matthew Palmer mpal...@debian.org facter (U) Javier Fernandez-Sanguino Pen~a j...@debian.org ifupdown-extra tiger Mark Purcell m...@debian.org kvpnc (U) Julien Valroff jul...@kirya.net rkhunter Jamie Wilkinson j...@debian.org facter facter (U) Alexander Wirt formo...@debian.org firehol netstat --- Joost van Baal joos...@debian.org systraq (U) Adam Conrad adcon...@0c3.net apache2 (U) Debian Apache Maintainers debian-apa...@lists.debian.org apache2 Mike Forbes m...@nothing.net.nz chkrootkit (U) Laurent Fousse laur...@komite.net systraq Turbo Fredriksson tu...@debian.org roxen4 Stefan Fritsch s...@debian.org apache2 (U) Wilmer van der Gaast wil...@gaast.net bitlbee Tollef Fog Heen tfh...@debian.org apache2 (U) Giuseppe Iuculano giuse...@iuculano.it chkrootkit Thom May t...@debian.org apache2 (U) Kari Pahula k...@debian.org tntnet Peter Samuelson pe...@p12n.org apache2 (U) Jelmer Vernooij jel...@samba.org bitlbee (U) ifconfig Debian Apache Maintainers debian-apa...@lists.debian.org apr Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org libnet-arp-perl Stefan Fritsch s...@debian.org apr (U) Bdale Garbee bd...@gag.com bind9 (U) Tollef Fog Heen tfh...@debian.org apr (U) LaMont Jones lam...@debian.org bind9 Bastian Kleineidam cal...@debian.org fiaif Noèl Köthe n...@debian.org hammerhead Jonny Lamb jo...@debian.org synce-hal Andrew Lee and...@linux.org.tw lxnm Andrew McMillan deb...@mcmillan.net.nz whereami Ryan Niebur ryanrya...@gmail.com apr (U) Martin Peylo deb...@izac.de tipcutils Andrew Pollock apoll...@debian.org argus Peter Samuelson pe...@p12n.org apr (U) Guus Sliepen g...@debian.org ifenslave-2.6 Niko Tyni nt...@debian.org libnet-arp-perl (U) Gunnar Wolf gw...@debian.org libnet-arp-perl (U) false positive? --- Mirco Bauer mee...@debian.org xsp (U) Daniel Baumann dan...@debian.org gnunet-gtk gnunet-qt Marc 'HE' Brockschmidt h...@debian.org gnome-nettool (U) Kanru Chen kos...@debian.org.tw tspc Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org gnome-nettool Debian Mono Group pkg-mono-gr...@lists.alioth.debian.org xsp Debian OLPC debian-olpc-de...@lists.alioth.debian.org sugar Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org libnet-sip-perl Sebastian Dröge sl...@debian.org gnome-nettool (U) Martín Ferrari tin...@debian.org libnet-sip-perl (U) gregor herrmann gre...@debian.org libnet-sip-perl (U) Damyan Ivanov d...@debian.org libnet-sip-perl (U) Rene Mayorga rmayo...@debian.org libnet-sip-perl (U) Loic Minier l...@dooz.org gnome-nettool (U) Dylan R. E. Moonfire deb...@mfgames.com xsp (U) Josselin Mouette j...@debian.org gnome-nettool (U) Jose Luis Rivas ghostba...@gmail.com libnet-sip-perl (U) Jo Shields direct...@apebox.org xsp (U) Jonas Smedegaard d...@jones.dk sugar (U) Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Ben Hutchings b...@decadent.org.uk writes: On Mon, Mar 16, 2009 at 01:08:04PM +0100, Bjørn Mork wrote: mii-tool may not be meant for scripts, but I for one have used it in the past to force speed/duplex like this: iface eth1 inet static address 10.122.226.9 netmask 255.255.255.192 up /sbin/mii-tool -F 100baseTx-FD eth1 I'm pretty sure I'm not the only one... You can do this with ethtool now, and more cleanly: link-speed 100 link-duplex full Yes, I know. But that means that existing working configurations have to be modified. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Martín Ferrari dijo [Sun, Mar 15, 2009 at 02:30:18PM -0300]: Hi, Luk Claes and me, as the current maintainers of net-tools, we've been thinking about it's future. Net-tools has been a core part of Debian and any other linux based distro for many years, but it's showing its age. (...) Hence, our plans are to replace net-tools completely with iproute, maybe leading the route for other distributions to follow. Of course, most people and tools use and remember the venerable old interface, so the first step would be to write wrappers, trying to be compatible with net-tools. Great news, and a bold initiative! About the wrapper scripts: * ipconfig, route: the most difficult ones, both can be replaced by calls to ip, maybe except for some obscure options. * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line Oops... I strongly suggest providing a wrapper that matches netstat's format as closely as possible (even bug-for-bug if possible). Netstat is probably among the most used tools by sysadmins and programmers alike, both for software we distribute and for home-grown tools. Besides that, I'm all for the change. Although my fingers still prefer ifconfig over ip for some strange reason... Maybe it gets better huffman-encoded? -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Tue, 2009-03-17 at 21:30 -0600, Gunnar Wolf wrote: Oops... I strongly suggest providing a wrapper that matches netstat's format as closely as possible (even bug-for-bug if possible). Netstat is probably among the most used tools by sysadmins and programmers alike, both for software we distribute and for home-grown tools. sockstat is similar, but needs to be adapted for IPv6 still. William signature.asc Description: This is a digitally signed message part
Re: net-tools future
Martín Ferrari tin...@debian.org writes: Problematic tools: * mii-tool: it could be dropped and replaced by a pointer to ethtool as it's not meant to be used automatically by scripts. On the other hand, it's distributed as a stand-alone tool [0] and we could do the same. A couple of notes: mii-tool and ethtool use different driver interfaces which I'm pretty sure aren't completely overlapping for all drivers in the kernel mii-tool may not be meant for scripts, but I for one have used it in the past to force speed/duplex like this: iface eth1 inet static address 10.122.226.9 netmask 255.255.255.192 up /sbin/mii-tool -F 100baseTx-FD eth1 I'm pretty sure I'm not the only one... I fail to see the value of removing mii-tool. I'd rather see just the non-working features removed in favour of an ethtool recommendation. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mon, Mar 16, 2009 at 01:08:04PM +0100, Bjørn Mork wrote: Martín Ferrari tin...@debian.org writes: Problematic tools: * mii-tool: it could be dropped and replaced by a pointer to ethtool as it's not meant to be used automatically by scripts. On the other hand, it's distributed as a stand-alone tool [0] and we could do the same. A couple of notes: mii-tool and ethtool use different driver interfaces which I'm pretty sure aren't completely overlapping for all drivers in the kernel mii-tool may not be meant for scripts, but I for one have used it in the past to force speed/duplex like this: iface eth1 inet static address 10.122.226.9 netmask 255.255.255.192 up /sbin/mii-tool -F 100baseTx-FD eth1 I'm pretty sure I'm not the only one... You can do this with ethtool now, and more cleanly: link-speed 100 link-duplex full I fail to see the value of removing mii-tool. I'd rather see just the non-working features removed in favour of an ethtool recommendation. It doesn't recognise 1G and 10G links, so its speed reporting is broken. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Sun, Mar 15, 2009 at 06:41:14PM +, Ben Hutchings wrote: * nameif: can be replaced by ip link, not sure if it's worth the effort (does anybody actually use it?) Never heard of it, and it seems redundant with udev now. There's also ifrename. I think udev can now do everything ifrename can do, and if installations without udev are unsupported by Debian then this tool can go away as well. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: net-tools future
On Mon, 2009-03-16 at 22:25 +, Ben Hutchings wrote: On Mon, Mar 16, 2009 at 01:08:04PM +0100, Bjørn Mork wrote: [...] I fail to see the value of removing mii-tool. I'd rather see just the non-working features removed in favour of an ethtool recommendation. It doesn't recognise 1G and 10G links, so its speed reporting is broken. I was mistaken - the Debian package has a patch to add 1G support. Ethernet 10G PHYs have a much larger MDIO register set and there is no standard for addressing these through ioctls (something else I'd like to fix). But I'll admit that they are rare as yet. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
Re: net-tools future
On Mar 15, Martín Ferrari tin...@debian.org wrote: * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line While I am happy to see ifconfig and route go, I am not sure that netstat is in the same category and should be replaced with something which is not 100% compatibile in the output. * nameif: can be replaced by ip link, not sure if it's worth the effort (does anybody actually use it?) Kill it ASAP, it's not compatible with udev. * plipsetup, slattach: we don't know of any replacement for those, but could be distributed separately too. Also, it's dubious if anyone still uses them. I expect that some people still do, and I think it's reasonable to continue distributing them in a extra priority package. -- ciao, Marco signature.asc Description: Digital signature
Re: net-tools future
On Sun, 2009-03-15 at 14:30 -0300, Martín Ferrari wrote: [...] * nameif: can be replaced by ip link, not sure if it's worth the effort (does anybody actually use it?) Never heard of it, and it seems redundant with udev now. There's also ifrename. Problematic tools: * mii-tool: it could be dropped and replaced by a pointer to ethtool as it's not meant to be used automatically by scripts. On the other hand, it's distributed as a stand-alone tool [0] and we could do the same. [...] Note that ethtool cannot yet provide all of the information mii-tool does (#511392). I hope to submit patches to the kernel and ethtool to fix this, though. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Re: net-tools future
Marco, On Sun, Mar 15, 2009 at 15:11, Marco d'Itri m...@linux.it wrote: * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line While I am happy to see ifconfig and route go, I am not sure that netstat is in the same category and should be replaced with something which is not 100% compatibile in the output. The idea is to provide a wrapper with the same output as the original netstat -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Marco d'Itri wrote: On Mar 15, Martín Ferrari tin...@debian.org wrote: * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line While I am happy to see ifconfig and route go, I am not sure that netstat is in the same category and should be replaced with something which is not 100% compatibile in the output. * nameif: can be replaced by ip link, not sure if it's worth the effort (does anybody actually use it?) Kill it ASAP, it's not compatible with udev. Being able to rename an interface without messing with udev is a feature, not a bug. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mar 15, Bernd Zeimetz be...@bzed.de wrote: Being able to rename an interface without messing with udev is a feature, not a bug. Every relevant Linux distribution requires udev, and so do many important features of Debian systems. Anything not compatible with udev is a toy which wastes space in the archive. Welcome to 2008. -- ciao, Marco signature.asc Description: Digital signature
Re: net-tools future
On Sun, 15 Mar 2009 23:07:29 +0100, Marco d'Itri wrote: [..] Welcome to 2008. Marco, did you dist-upgrade yourself? ;) Ciao, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: net-tools future
Martín Ferrari wrote: * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line sstat? I see /usr/bin/sstat in slurm-llnl - but that doesn't look right. What sstat are you referring to here? -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Mar 15, David Paleino d.pale...@gmail.com wrote: [..] Welcome to 2008. Marco, did you dist-upgrade yourself? ;) http://en.wiktionary.org/wiki/irony HTH. -- ciao, Marco signature.asc Description: Digital signature
Re: net-tools future
On Sun, Mar 15, 2009 at 21:52, Brian May br...@microcomaustralia.com.au wrote: Martín Ferrari wrote: * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line sstat? I see /usr/bin/sstat in slurm-llnl - but that doesn't look right. What sstat are you referring to here? Sorry, it was meant to say ss, from the iproute package -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Sun, 15 Mar 2009, Martín Ferrari wrote:
* mii-tool: it could be dropped and replaced by a pointer to ethtool as
it's not meant to be used automatically by scripts. On the other hand,
mii-tool behaviour when you call it without parameters is *extremely* useful
to locate which cable goes where. ethtool is quite cubersome for this. In
fact, it is downright ill-suited for this kind of use.
Compare:
# mii-tool
eth0: negotiated 100baseTx-FD flow-control, link ok
eth1: no link
with:
# ip link | sed -ne '/^[0-9]\+:/ {s/.*:\(.*\): [].*/\1/ p}' | xargs -n1 -r
ethtool | grep -E '(Settings)|(Link)|(Speed)|(Duplex)'
Settings for lo:
Link detected: yes
Settings for eth1:
Speed: Unknown! (65535)
Duplex: Unknown! (255)
Link detected: no
Settings for eth0:
Speed: 100Mb/s
Duplex: Full
Link detected: yes
So, ethtool really needs to grow an option to iterate over all netdevs, and
another one to print a summary of link state and speed,duplex before
mii-tool could be dropped.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
