[arch-projects] [netcfg] netcfg/netctl
Hello arch developers! I looked at netcfg code and functionality and I think that this can be usefull replacement for NetworkManager. Interface for writing new modules is simple and I think it can be usefull on other linux distributions. Now I found that there is netctl fork which is like new generation of netcfg. From info in readme I see that now it depends on systemd, which is very controverse init daemon and not all linux distributions and user using it... I'm not using arch, but I'd like to use netcfg/netctl. My current situation is that I need to connect to ethernet with 802.1X authentification (high priority!) and then try connection without 802.1X (normal dhcp - low priority). And seems that netcfg is only one tool which done it successfully. Is archlinux going to participate to Google Summer of Code 2013? If yes I'd like to extend netcfg/netctl project. What do you think, it is possible? Is there some future plan or TODO? My imagination is that network tool can auto configure (without user interact) any network adapter based on information from config files (profiles). Also network tool should support any possible wireless configuration (which support for example wpa_supplicant), but have configuration in one file (not one for supplicant, one for ip/dhcp and one for static dns). I think that hostapd support can be also usefull or full automatic ipv6 configuration (use stateless dns, read M/O bits from RA and use dhcpv6 when needed). -- Pali Rohár pali.rohar@gmail.com
On Thu, Jan 17, 2013 at 12:55 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
Hello arch developers!
I looked at netcfg code and functionality and I think that this can be usefull replacement for NetworkManager. Interface for writing new modules is simple and I think it can be usefull on other linux distributions.
Indeed, netctl is not Arch-specific anymore, so it can easily be used on other distributions as well. Unfortunately, netcfg uses initscripts to a level that makes usage on other distros unfeasible.
Now I found that there is netctl fork which is like new generation of netcfg. From info in readme I see that now it depends on systemd, which is very controverse init daemon and not all linux distributions and user using it... I'm not using arch, but I'd like to use netcfg/netctl.
There are more distros using systemd than the Arch initscripts. This was part of the reason to switch to systemd and part of the reason systemd was written ;-).
My current situation is that I need to connect to ethernet with 802.1X authentification (high priority!) and then try connection without 802.1X (normal dhcp - low priority). And seems that netcfg is only one tool which done it successfully.
I remember that this worked well on FreeBSD too.
Is archlinux going to participate to Google Summer of Code 2013? If yes I'd like to extend netcfg/netctl project. What do you think, it is possible? Is there some future plan or TODO?
Although it is technically only a few weeks old, netctl is quite mature. There were a few TODOs with netcfg, but they have mostly been implemented in netctl. Keep in mind that netctl does not try to be your ultimate coffee-making-and-mail-sending piece of software. I am proud of the fact that with netctl, some of the weirder bells and whistles of netcfg are gone. As you will understand from this, there are no intentions to mentor any netctl contributions for the GSoC 2013.
My imagination is that network tool can auto configure (without user interact) any network adapter based on information from config files (profiles). Also network tool should support any possible wireless configuration (which support for example wpa_supplicant), but have configuration in one file (not one for supplicant, one for ip/dhcp and one for static dns). I think that hostapd support can be also usefull or full automatic ipv6 configuration (use stateless dns, read M/O bits from RA and use dhcpv6 when needed).
Some of this is already possible. Some other stuff will be welcomed as patches. Profiles for Access Point configurations have been suggested in the past and this should not be very hard to realize. The rest will probably come around when someone needs it and writes the necessary support. Thanks for your thoughts, - Jouke
participants (2)
-
Jouke Witteveen
-
Pali Rohár