Re: [arch-general] [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.3-1, net-tools-1.60-16, udev-171-2, yp-tools-2.12-2, ypbind-mt-1.33-2, iproute2-2.6.38-3
Hello Tom, thanks for the pre-announcement, looks good. I have just a question.. Since net-tools are going to be abandoned (I was wondering how i "misuninstalled" the package), what do i use as an alternative to ifconfig? I use wicd or manually bring LAN up, and it occurred to me network interfaces failed due to missing ifconfig command. What is the new one? Thanks On Tuesday 07 of June 2011 23:21:11 Tom Gundersen wrote:
Since these update introduces some important changes I'd like to make two announcements before it is moved to core (which should be as soon as we have the missing i686 signoff).
Drafts below, comments welcome.
Announcement one: =============================================
Deprecation of net-tools
This April marked the ten year anniversary of the last net-tools release. We decided to look at this as an opportunity to deprecate net-tools and provide alternative, and better maintained, solutions for net-tools functionality. This has a few consequences, but most people should not notice.
`hostname` ----------
This binary is now provided by `coreutils`, rather than by `net-tools`.
`domainname` (a.k.a. `nisdomainname`, a.k.a `ypdomainname`) -----------------------------------------------------------
These binaries are now provided by `yp-tools`, rather than by `net-tools`. Furthermore, the domain name is no longer set by initscripts, rather it is dealt with entirely by the ypbind rc script.
Before this change the domain name was handled inconsistently, sometimes being read from `/etc/conf.d/nisdomainname`, and sometimes from `/etc/defaultdomain`. From now on, the domain name is only ever read from `/etc/conf.d/nisdomainname`.
`network` ------------------------------
A new syntax is introduced in `rc.conf` for configuring a simple network setup using `iproute2` rather than `net-tools`. The old functionality is still preserved for those preferring to stay with that, but do not expect updates for this.
The new syntax is very simplistic and only supports one wired network device (configured statically or by dhcp) and we do not expect to add more features in the future. We want to encourage the use of more advanced network solutions, such as `networkmanager` or our own `netcfg`.
Announcement two: =============================================
Changes to module blacklisting
Since the dawn of time we have shipped our homegrown system for blacklisting kernel modules (in various incarnations). This has served us well, but we (or rather our various upstreams) have now reached a point where it is no longer necessary.
We have therefore decided to remove all our module blacklisting logic, and rely entirely on the blacklisting provided by `modprobe`. This means a change in syntax, and a minor change in functionality. We hope that the short-term inconvenience will be justified by the long-term gain.
The different notions of blacklisting --------------------------------------------
The notion of module blacklisting that we have used is (sadly) slightly different from what is used by modprobe.
* our blacklisting: a blacklisted module, or any module that depends on it, will never be loaded automatically by udev, but may be loaded manually. * modprobe's blacklisting: a blacklisted module will not be loaded automatically, but may be loaded if another non-blacklisted module depends on it, or if it is loaded manually. * disabling a module: one can get similar behavior to what we used to provide by forcing a module to always fail loading, it will not be possible to load it manually.
Boot time blacklisting ---------------------------
Modules can be blacklisted at boot time by appending `modprobe.blacklist=mod1,mod2,mod3` to the kernel command line (in grub, lilo or syslinux). Alternatively, the modules can be disabled altogether by appending `mod1.disable=1 mod2.disable=1 mod3.disable=1` instead.
Persistent blacklisting ---------------------------
Rather than blacklisting modules in `rc.conf`, use modprobe's native configuration files. These can be found in /etc/modprobe.d/, and are documented in `man modprobe.d`.
The replacement of `rc.d`'s `MODULES=(!mod1 !mod2 !mod3)` is to add a `.conf` file to `/etc/modprobe.d/` with the contents:
blacklist mod1 blacklist mod2 blacklist mod3
Alternatively, to ensure that the modules are never inserted, even if they are needed by other modules you load:
install mod1 /bin/false install mod2 /bin/false install mod3 /bin/false
-- Marek Otahal :o)
On Tue, Jun 7, 2011 at 14:36, Marek Otahal <markotahal@gmail.com> wrote:
Hello Tom, thanks for the pre-announcement, looks good. I have just a question.. Since net-tools are going to be abandoned (I was wondering how i "misuninstalled" the package), what do i use as an alternative to ifconfig? I use wicd or manually bring LAN up, and it occurred to me network interfaces failed due to missing ifconfig command. What is the new one? Thanks
Please don't top-post. The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments. 'ip link set up eth0' is equivalent to 'ifconfig eth0 up'. ~Celti
On 07-06-2011 22:46, Patrick Burroughs wrote:
The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments.
I don't see the current assigned IP when doing 'ip link show' so I don't see how that is equivalent to using only ifconfig without arguments. As a side note, at first glance it seems 'ip' needs a lot more typing than ifconfig needs, at least for the stuff I use more often. -- Mauro Santos
On 06/08/11 at 02:30pm, Mauro Santos wrote:
On 07-06-2011 22:46, Patrick Burroughs wrote:
The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments.
I don't see the current assigned IP when doing 'ip link show' so I don't see how that is equivalent to using only ifconfig without arguments.
'ip addr show' is the command you want. -- Byron Clark
On Wed, Jun 8, 2011 at 3:30 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
On 07-06-2011 22:46, Patrick Burroughs wrote:
The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments.
I don't see the current assigned IP when doing 'ip link show' so I don't see how that is equivalent to using only ifconfig without arguments.
As a side note, at first glance it seems 'ip' needs a lot more typing than ifconfig needs, at least for the stuff I use more often.
You should use just use "ip addr" rather than "ifconfig" (which saves you one character ;-) ). -t
On Wed, Jun 8, 2011 at 4:54 PM, Tom Gundersen <teg@jklm.no> wrote:
You should use just use "ip addr" rather than "ifconfig" (which saves you one character ;-) ).
No both can be 5 keystrokes: <i><p><space><a><tab> <i><f><c><o><tab> Yes this message was completely unuseful! :p -- Cédric Girard
Tom Gundersen (2011-06-08 16:54):
On Wed, Jun 8, 2011 at 3:30 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
On 07-06-2011 22:46, Patrick Burroughs wrote:
The new replacement for ifconfig is 'ip'; 'ip link show' is equivalent to the old 'ifconfig', without arguments.
I don't see the current assigned IP when doing 'ip link show' so I don't see how that is equivalent to using only ifconfig without arguments.
As a side note, at first glance it seems 'ip' needs a lot more typing than ifconfig needs, at least for the stuff I use more often.
You should use just use "ip addr" rather than "ifconfig" (which saves you one character ;-) ).
-t
Or, rather, "ip a" for addreses and link status (like /sbin/ifconfig) "ip r" for routes (like /sbin/route) -- -- Rogutės Sparnuotos
On 9 June 2011 01:57, Rogutės Sparnuotos <rogutes@googlemail.com> wrote:
Or, rather, "ip a" for addreses and link status (like /sbin/ifconfig) "ip r" for routes (like /sbin/route)
Nice. If only it displayed RX/TX bytes as well, I would totally not miss ifconfig. :) (*Secretly hopes that someone will point out how this is done.* :3)
On 8 June 2011 20:13, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 9 June 2011 01:57, Rogutės Sparnuotos <rogutes@googlemail.com> wrote:
Or, rather, "ip a" for addreses and link status (like /sbin/ifconfig) "ip r" for routes (like /sbin/route)
Nice. If only it displayed RX/TX bytes as well, I would totally not miss ifconfig. :)
(*Secretly hopes that someone will point out how this is done.* :3)
Actually wait, it does that with 'ip -s link'. :p However, I would prefer a more human-friendly output (e.g. in MiB/GiB/etc. instead of just bytes).
Hi Marek, On Tue, Jun 7, 2011 at 11:36 PM, Marek Otahal <markotahal@gmail.com> wrote:
Since net-tools are going to be abandoned (I was wondering how i "misuninstalled" the package), what do i use as an alternative to ifconfig? I use wicd or manually bring LAN up, and it occurred to me network interfaces failed due to missing ifconfig command. What is the new one?
The new one is "ip", found in the iproute2 package. I didn't mention this explicitly, as this upgrade is not supposed to remove net-tools, so in principle ifconfig should still work. Cheers, Tom
On Tuesday 07 of June 2011 23:47:35 Tom Gundersen wrote:
Hi Marek,
On Tue, Jun 7, 2011 at 11:36 PM, Marek Otahal <markotahal@gmail.com> wrote:
Since net-tools are going to be abandoned (I was wondering how i "misuninstalled" the package), what do i use as an alternative to ifconfig? I use wicd or manually bring LAN up, and it occurred to me network interfaces failed due to missing ifconfig command. What is the new one?
The new one is "ip", found in the iproute2 package.
I didn't mention this explicitly, as this upgrade is not supposed to remove net-tools, so in principle ifconfig should still work.
Cheers,
Tom
Patrick, Tom, thank you both for explanation. net-tools weren't installed as explicit, so some upgrade removed them from my system. I'll test if eg wicd can handle just 'ip' now. Thank you, cheers, Mark -- Marek Otahal :o)
On Tue, Jun 7, 2011 at 11:47 PM, Tom Gundersen <teg@jklm.no> wrote:
I didn't mention this explicitly, as this upgrade is not supposed to remove net-tools, so in principle ifconfig should still work.
Maybe this should be added to the announcement (the fact that net-tools will still be there). -- Cédric Girard
2011/6/8 Cédric Girard <girard.cedric@gmail.com>:
Maybe this should be added to the announcement (the fact that net-tools will still be there).
-- Cédric Girard
Yeah, this should be in the announcement. I thought net-tools would be removed completely. -- Vic Demuzere
...
The new syntax is very simplistic and only supports one wired network device (configured statically or by dhcp) and we do not expect to add more features in the future. We want to encourage the use of more advanced network solutions, such as `networkmanager` or our own `netcfg`.
Just one officially supported? How about boxes with 2 nics acting as routers or gateways? It sounds to me a bit limited... netcfg is there but it's not the default, and most arch wiki documentation show a way without netcfg, :-) Perhaps time to change the arch wikies when the change take place, :-) Did I misunderstand the statement? Thanks, -- Javier.
On Wed, Jun 8, 2011 at 1:33 AM, Javier Vasquez <j.e.vasquez.v@gmail.com> wrote:
Just one officially supported? How about boxes with 2 nics acting as routers or gateways? It sounds to me a bit limited... netcfg is there but it's not the default,
We hope netcfg will become the preferred networking solution in the future. If you cannot use netcfg, and the basic functionality we provide in initscripts is not sufficient, then the old net-tools way will continue to work for the foreseeable future.
and most arch wiki documentation show a way without netcfg, :-) Perhaps time to change the arch wikies when the change take place, :-)
Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting).
Did I misunderstand the statement?
No, I don't think so ;-) Cheers, Tom
If true, you might want to consider mentioning that it might be unnecessary to blacklist certain modules such as 'pcspkr' which are no longer automatically loaded (since load_modules.sh has been removed)
On 06/08/2011 01:41 AM, Tom Gundersen wrote:
Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting).
Hey Tom, what help do you need with the documentation?
On Wed, Jun 8, 2011 at 4:17 PM, mangust <m4ngust@gmail.com> wrote:
On 06/08/2011 01:41 AM, Tom Gundersen wrote:
Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting).
Hey Tom, what help do you need with the documentation?
Thanks for offering to help! We should find the places in the wiki that suggest using the old net-tools configuration options in rc.conf, and see if the use-cases they are describing can be replaced by our new syntax, or by upgrading to netcfg. If so, we should update the documentation to reflect this. Otherwise, we leave it as it is, as net-tools will still be supported. Possibly, we should add a comment that net-tools needs to be installed for it to work. Cheers, Tom
On 06/08/2011 04:57 PM, Tom Gundersen wrote:
On Wed, Jun 8, 2011 at 4:17 PM, mangust <m4ngust@gmail.com> wrote:
On 06/08/2011 01:41 AM, Tom Gundersen wrote:
Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting). Hey Tom, what help do you need with the documentation? Thanks for offering to help!
We should find the places in the wiki that suggest using the old net-tools configuration options in rc.conf, and see if the use-cases they are describing can be replaced by our new syntax, or by upgrading to netcfg. If so, we should update the documentation to reflect this. Otherwise, we leave it as it is, as net-tools will still be supported. Possibly, we should add a comment that net-tools needs to be installed for it to work.
Cheers,
Tom No problem!
I'll search the Wiki for this information and will update it. Cheers, mangust
On Wed, Jun 8, 2011 at 7:33 PM, mangust <m4ngust@gmail.com> wrote:
On 06/08/2011 04:57 PM, Tom Gundersen wrote:
On Wed, Jun 8, 2011 at 4:17 PM, mangust <m4ngust@gmail.com> wrote:
On 06/08/2011 01:41 AM, Tom Gundersen wrote:
Yes, documentation should be updated. Help with this is very much appreciated! I will personally start working on this once the release is out (time permitting). Hey Tom, what help do you need with the documentation? Thanks for offering to help!
We should find the places in the wiki that suggest using the old net-tools configuration options in rc.conf, and see if the use-cases they are describing can be replaced by our new syntax, or by upgrading to netcfg. If so, we should update the documentation to reflect this. Otherwise, we leave it as it is, as net-tools will still be supported. Possibly, we should add a comment that net-tools needs to be installed for it to work.
Cheers,
Tom No problem!
I'll search the Wiki for this information and will update it.
Great! Thanks! -t
2011/6/9 Wim Van Deun <wimvandeun@gmail.com>
Hi,
Is there also an alternative to netstat ??? Thanks.
Regards, Wim
"lsof -i -n" may help you, it shows current connections, ordered by owner's process id. -- Hyacinthe
On 9 June 2011 16:37, Wim Van Deun <wimvandeun@gmail.com> wrote:
Is there also an alternative to netstat ???
ss :p
Thx, ss does exactly what i want. On Thu, Jun 9, 2011 at 5:39 PM, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 9 June 2011 16:37, Wim Van Deun <wimvandeun@gmail.com> wrote:
Is there also an alternative to netstat ???
ss :p
/etc/conf.d/bridges (bridge-utils) still has old rc.conf example: # example: # # in /etc/rc.conf: # eth0="eth0 up" # eth1="eth1 up" # br0="br0 192.168.0.2 netmask 255.255.255.0 up" # INTERFACES=(lo eth0 eth1 br0) # # in /etc/conf.d/bridges # bridge_br0="eth0 eth1" # BRIDGE_INTERFACES=(br0) # In addition bridged interfaces doesn't work with new rc.conf syntax (unknown interface br0). How to set up?
On Fri, Jun 10, 2011 at 12:52 AM, Joker-jar <joker-jar@yandex.ru> wrote:
/etc/conf.d/bridges (bridge-utils) still has old rc.conf example:
# example: # # in /etc/rc.conf: # eth0="eth0 up" # eth1="eth1 up" # br0="br0 192.168.0.2 netmask 255.255.255.0 up" # INTERFACES=(lo eth0 eth1 br0) # # in /etc/conf.d/bridges # bridge_br0="eth0 eth1" # BRIDGE_INTERFACES=(br0) #
In addition bridged interfaces doesn't work with new rc.conf syntax (unknown interface br0). How to set up?
The dchp still works with net-tools installed: eth0="eth0 up" br0="dhcp" INTERFACES=(eth0 br0) However using netcfg it can be accomplish, it has examples: /etc/network.d/examples/bridge I have two profiles, one for dhcp (work) and one for static (home): % cat /etc/network.d/wired-dhcp # DHCLIENT=yes CONNECTION='bridge' DESCRIPTION='A basic dhcp ethernet connection using iproute' INTERFACE='br0' BRIDGE_INTERFACES="eth0" IP='dhcp' CARRIER_TIMEOUT=3 % cat /etc/network.d/wired-static # CONNECTION='bridge' DESCRIPTION='A basic static ethernet connection using iproute' INTERFACE='br0' BRIDGE_INTERFACES="eth0" IP='static' ADDR='192.168.1.159' GATEWAY='192.168.1.1' DNS=('200.91.75.5' '200.91.75.6' '192.168.1.1') CARRIER_TIMEOUT=3 So I use net-profiles daemon instead of network one, :-) Notice for some reason dhcpd is not a good option for bridging under netcfg, since somehow the dhcp client keeps alive after netcfg -a, so I preferred using dhclient, which works well... So perhaps you might consider using netcfg for bridging, :-) -- Javier.
participants (15)
-
Byron Clark
-
Cédric Girard
-
Evangelos Foutras
-
Hyacinthe Cartiaux
-
Javier Vasquez
-
Joker-jar
-
mangust
-
Marek Otahal
-
Mauro Santos
-
Patrick Burroughs
-
Rogutės Sparnuotos
-
Tom Gundersen
-
Vic Demuzere
-
Wim Van Deun
-
Yclept Nemo