[arch-projects] [netcfg] Call for testers: netctl
Dear all, For little over a year now, I have maintained netcfg. In doing so I have encountered three major problems. 1. Despite best efforts, the code and control flow of netcfg remain rather messy. 2. Usage of netcfg has many corner cases. 3. Some wheels are invented by both systemd and netcfg, but it is not easy to have netcfg make use of systemd. In order to deal with these issues I have forked netcfg. In the end, it turned out to be more of a rewrite. The result[1] I have called netctl. The main purpose of netctl is to provide profile-based networking in a systemd environment. Here are some of the changes with respect to netcfg. a. Variables in profiles are CamelCase instead of UPPER_CASE to mimic systemd services. b. All configuration files are gone, configuration is done through the netctl utility, which interfaces systemd's systemctl. c. The only non-trivial usage that is provided is automatic configuration through ifplugd or wpa_actiond, formerly known as net-auto-wire{d,less}, now known as netctl-ifplugd and netctl-auto. Some of the bugs that are fixed: d. Bind to network interfaces during boot, thus preventing the lack of a connection after boot recently encountered by owners of slow hardware. e. Allow more complex nameserver setups by using resolvconf (openresv). Transition should not be hard. At any rate the three new man pages netctl(1), netctl.profile(5), and netctl.special(7) should answer all questions. Here is a basic outline of the changes required: - Rename variables in the profiles in /etc/network.d/ and unquote some of their values (mainly Interface=). - Run `netctl enable <profile>` for every profile in the old NETWORKS array. 'last' doesn't work this way, see netcfg.special(7). - Use `netctl list`/`netctl start <profile>` instead of `netcfg-menu`, wifi-menu remains available. As half of the total code base has been removed and almost every line in the other half has been touched, I expect some easy-to-fix bugs to be introduced. Therefore I need testers. Please test netctl: I. $ git clone git://github.com/joukewitteveen/netctl.git II. $ cd netctl; make pkgbuild III. copy netctl-*.tar.xz and PKGBUILD to an empty directory IV. run makepkg in that directory V. install (using `pacman -U`) the resulting package. During the 0.x series, I am not afraid of breaking compatibility. If all goes well, I would like to replace netcfg with netctl starting with a 1.0 release. I know many people don't like the idea of dropping netcfg or netcfg compatibility, but I think the situation of netctl is far easier to maintain. Personally, I don't see much future in netcfg besides an optional compatibility layer on top of netctl. Thanks to all testers! - Jouke [1] https://github.com/joukewitteveen/netctl
On 12/29/12 at 12:50pm, Jouke Witteveen wrote:
Dear all,
For little over a year now, I have maintained netcfg. In doing so I have encountered three major problems. 1. Despite best efforts, the code and control flow of netcfg remain rather messy. 2. Usage of netcfg has many corner cases. 3. Some wheels are invented by both systemd and netcfg, but it is not easy to have netcfg make use of systemd.
In order to deal with these issues I have forked netcfg. In the end, it turned out to be more of a rewrite. The result[1] I have called netctl. The main purpose of netctl is to provide profile-based networking in a systemd environment. Here are some of the changes with respect to netcfg. a. Variables in profiles are CamelCase instead of UPPER_CASE to mimic systemd services. b. All configuration files are gone, configuration is done through the netctl utility, which interfaces systemd's systemctl. c. The only non-trivial usage that is provided is automatic configuration through ifplugd or wpa_actiond, formerly known as net-auto-wire{d,less}, now known as netctl-ifplugd and netctl-auto.
Some of the bugs that are fixed: d. Bind to network interfaces during boot, thus preventing the lack of a connection after boot recently encountered by owners of slow hardware. e. Allow more complex nameserver setups by using resolvconf (openresv).
Transition should not be hard. At any rate the three new man pages netctl(1), netctl.profile(5), and netctl.special(7) should answer all questions. Here is a basic outline of the changes required: - Rename variables in the profiles in /etc/network.d/ and unquote some of their values (mainly Interface=). - Run `netctl enable <profile>` for every profile in the old NETWORKS array. 'last' doesn't work this way, see netcfg.special(7). - Use `netctl list`/`netctl start <profile>` instead of `netcfg-menu`, wifi-menu remains available.
As half of the total code base has been removed and almost every line in the other half has been touched, I expect some easy-to-fix bugs to be introduced. Therefore I need testers. Please test netctl: I. $ git clone git://github.com/joukewitteveen/netctl.git II. $ cd netctl; make pkgbuild III. copy netctl-*.tar.xz and PKGBUILD to an empty directory IV. run makepkg in that directory V. install (using `pacman -U`) the resulting package.
During the 0.x series, I am not afraid of breaking compatibility. If all goes well, I would like to replace netcfg with netctl starting with a 1.0 release. I know many people don't like the idea of dropping netcfg or netcfg compatibility, but I think the situation of netctl is far easier to maintain. Personally, I don't see much future in netcfg besides an optional compatibility layer on top of netctl.
Thanks to all testers! - Jouke
Seems pretty neat. So far almost all functions seem to work. Though I have come across an issue with netctl-auto. I cannot seem to store a profile. I use # netctl store [PROFILE] and the result is simply the help/usage. I checked with "list" and still not active (no *). Ergo, starting netctl-auto with: # netctl-auto start wlan0 has no action. Though enabling and starting the services using "netctl enable" works perfectly. So far, things look pretty awesome. I really like this interface, as it does indeed integrate well with systemd. Regards, -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On Sun, Dec 30, 2012 at 1:16 AM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
Seems pretty neat. So far almost all functions seem to work. Though I have come across an issue with netctl-auto.
Cool, can you share what you have tested?
I cannot seem to store a profile. I use # netctl store [PROFILE] and the result is simply the help/usage. I checked with "list" and still not active (no *).
That is because, as the help should tell you, 'store' does not take arguments ;-). Did you mean 'enable'?
Ergo, starting netctl-auto with: # netctl-auto start wlan0 has no action.
This is unrelated to `netctl store`. As netctl-auto is inevitably a different beast by design, it indeed does not really bring profiles up, but rather configures the network according to them. This may sound strange, but it really is what is going on. For example: you can enable the netctl-auto service in systemd, which will run independently of other netctl@<profiles> and also not start/stop any of them. Regards, - Jouke
On 12/30/12 at 01:49pm, Jouke Witteveen wrote:
On Sun, Dec 30, 2012 at 1:16 AM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
Seems pretty neat. So far almost all functions seem to work. Though I have come across an issue with netctl-auto.
Cool, can you share what you have tested?
I have tried using the netctl interface to start/stop the wifi (home) connection on my laptop. I have not tried the wired functionality, and probably won't be able to any time soon. I use WiFI 99.999% of the time on my laptop. I also quickly discovered how well it integrates with systemd. I really like how enabling the profile through netctl is actually a call to systemctl. It works pretty great.
I cannot seem to store a profile. I use # netctl store [PROFILE] and the result is simply the help/usage. I checked with "list" and still not active (no *).
That is because, as the help should tell you, 'store' does not take arguments ;-). Did you mean 'enable'?
I actually was thinking that marking a profile as "active" would mark it to be used with netctl-auto. But I guess I was wrong on that. After reading the above, it does indeed work without any arguments. I guess now that I look at the help and see that there is no [PROFILE] appending list, store, restore, or stop-all. Can you tell me then, what exacly does an "active" profile indicate?
Ergo, starting netctl-auto with: # netctl-auto start wlan0 has no action.
This is unrelated to `netctl store`. As netctl-auto is inevitably a different beast by design, it indeed does not really bring profiles up, but rather configures the network according to them. This may sound strange, but it really is what is going on. For example: you can enable the netctl-auto service in systemd, which will run independently of other netctl@<profiles> and also not start/stop any of them.
So I was a big fan of net-auto-wireless. I loved the proper roaming functionality from such a simple network manager. Needless to say, I am having a bit of trouble figuring out how to use netctl-auto.
From what you are telling me above, I am kind of getting the idea that maybe I need to enable all the profiles that I might be roaming between. Then enable/start the netctl-auto service, which will handle switching between the enabled profiles. Is this right?
Regards, - Jouke
From what I have seen here so far, I am impressed. As I said before, I really like netcfg and particularly net-auto-wireless, so this really feels more of less like the same thing, but meant for use with systemd. The enable/disable is super intuitive, and I really like how it shows you the symlink command it is running to enable/disable (like systemctl).
My only complaint is that usage of netctl-auto is not entirely straight forward. But I think this can probably be fixed with a couple lines in the netctl.special man page, no problem. I will test out netctl-auto and report back. Regards, -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On Sun, Dec 30, 2012 at 5:47 PM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
On 12/30/12 at 01:49pm, Jouke Witteveen wrote:
On Sun, Dec 30, 2012 at 1:16 AM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
Seems pretty neat. So far almost all functions seem to work. Though I have come across an issue with netctl-auto.
Cool, can you share what you have tested?
I have tried using the netctl interface to start/stop the wifi (home) connection on my laptop. I have not tried the wired functionality, and probably won't be able to any time soon. I use WiFI 99.999% of the time on my laptop.
I also quickly discovered how well it integrates with systemd. I really like how enabling the profile through netctl is actually a call to systemctl. It works pretty great.
I cannot seem to store a profile. I use # netctl store [PROFILE] and the result is simply the help/usage. I checked with "list" and still not active (no *).
That is because, as the help should tell you, 'store' does not take arguments ;-). Did you mean 'enable'?
I actually was thinking that marking a profile as "active" would mark it to be used with netctl-auto. But I guess I was wrong on that.
After reading the above, it does indeed work without any arguments. I guess now that I look at the help and see that there is no [PROFILE] appending list, store, restore, or stop-all.
Can you tell me then, what exacly does an "active" profile indicate?
A profile is 'active' if it is 'running', 'up', 'started', or however you'd like to call it. The name 'active' is chosen to conform to systemd's notion of 'active' :-).
Ergo, starting netctl-auto with: # netctl-auto start wlan0 has no action.
This is unrelated to `netctl store`. As netctl-auto is inevitably a different beast by design, it indeed does not really bring profiles up, but rather configures the network according to them. This may sound strange, but it really is what is going on. For example: you can enable the netctl-auto service in systemd, which will run independently of other netctl@<profiles> and also not start/stop any of them.
So I was a big fan of net-auto-wireless. I loved the proper roaming functionality from such a simple network manager. Needless to say, I am having a bit of trouble figuring out how to use netctl-auto.
From what you are telling me above, I am kind of getting the idea that maybe I need to enable all the profiles that I might be roaming between. Then enable/start the netctl-auto service, which will handle switching between the enabled profiles. Is this right?
You don't need to enable them. It takes all profiles on the interface into account, unless a profile sets ExcludeAuto. The netctl-auto should work nearly identical to the old net-auto-wireless, so you should be good. Indeed, you did spot the first bug: ExcludeAuto was not documentated! This is fixed in git now.
Regards, - Jouke
From what I have seen here so far, I am impressed. As I said before, I really like netcfg and particularly net-auto-wireless, so this really feels more of less like the same thing, but meant for use with systemd. The enable/disable is super intuitive, and I really like how it shows you the symlink command it is running to enable/disable (like systemctl).
My only complaint is that usage of netctl-auto is not entirely straight forward. But I think this can probably be fixed with a couple lines in the netctl.special man page, no problem.
I will test out netctl-auto and report back.
Regards, -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On 12/30/12 at 06:05pm, Jouke Witteveen wrote:
You don't need to enable them. It takes all profiles on the interface into account, unless a profile sets ExcludeAuto. The netctl-auto should work nearly identical to the old net-auto-wireless, so you should be good. Indeed, you did spot the first bug: ExcludeAuto was not documentated! This is fixed in git now.
I cannot get netctl-auto to work. My interface is wlan0, so I have done: # systemctl enable netctl-auto@wlan0.service as well as: # netctl-auto start wlan0 Neither of which have worked. I have but one profile in /etc/network.d which contains the following: Description='Home Network' Interface=wlan0 Connection=wireless Security=wpa ESSID=AwesomeNetwork IP='dhcp' Key=<super-secret-password> ExcludeAuto=no This works by starting it via "netctl start" as well as enabling it with netctl@.service. I tried with and without the ExcludeAuto=no line. Am I missing something? Regards -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On Sun, Dec 30, 2012 at 9:48 PM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
On 12/30/12 at 06:05pm, Jouke Witteveen wrote:
You don't need to enable them. It takes all profiles on the interface into account, unless a profile sets ExcludeAuto. The netctl-auto should work nearly identical to the old net-auto-wireless, so you should be good. Indeed, you did spot the first bug: ExcludeAuto was not documentated! This is fixed in git now.
I cannot get netctl-auto to work. My interface is wlan0, so I have done: # systemctl enable netctl-auto@wlan0.service
as well as: # netctl-auto start wlan0
Neither of which have worked.
I have but one profile in /etc/network.d which contains the following: Description='Home Network' Interface=wlan0 Connection=wireless Security=wpa ESSID=AwesomeNetwork IP='dhcp' Key=<super-secret-password> ExcludeAuto=no
This works by starting it via "netctl start" as well as enabling it with netctl@.service. I tried with and without the ExcludeAuto=no line.
Am I missing something?
Regards -- Curtis Shimamoto sugar.and.scruffy@gmail.com
You did not miss anything, it was just broken. How about the new git version? I am confident that it works now. Thanks for testing! - Jouke
On 12/31/12 at 02:08pm, Jouke Witteveen wrote:
On Sun, Dec 30, 2012 at 9:48 PM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
On 12/30/12 at 06:05pm, Jouke Witteveen wrote:
You don't need to enable them. It takes all profiles on the interface into account, unless a profile sets ExcludeAuto. The netctl-auto should work nearly identical to the old net-auto-wireless, so you should be good. Indeed, you did spot the first bug: ExcludeAuto was not documentated! This is fixed in git now.
I cannot get netctl-auto to work. My interface is wlan0, so I have done: # systemctl enable netctl-auto@wlan0.service
as well as: # netctl-auto start wlan0
Neither of which have worked.
I have but one profile in /etc/network.d which contains the following: Description='Home Network' Interface=wlan0 Connection=wireless Security=wpa ESSID=AwesomeNetwork IP='dhcp' Key=<super-secret-password> ExcludeAuto=no
This works by starting it via "netctl start" as well as enabling it with netctl@.service. I tried with and without the ExcludeAuto=no line.
Am I missing something?
Regards -- Curtis Shimamoto sugar.and.scruffy@gmail.com
You did not miss anything, it was just broken. How about the new git version? I am confident that it works now.
Thanks for testing! - Jouke
Excellent, I will check it out right now! -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On 12/31/12 at 02:08pm, Jouke Witteveen wrote:
On Sun, Dec 30, 2012 at 9:48 PM, Curtis Shimamoto <sugar.and.scruffy@gmail.com> wrote:
On 12/30/12 at 06:05pm, Jouke Witteveen wrote:
You don't need to enable them. It takes all profiles on the interface into account, unless a profile sets ExcludeAuto. The netctl-auto should work nearly identical to the old net-auto-wireless, so you should be good. Indeed, you did spot the first bug: ExcludeAuto was not documentated! This is fixed in git now.
I cannot get netctl-auto to work. My interface is wlan0, so I have done: # systemctl enable netctl-auto@wlan0.service
as well as: # netctl-auto start wlan0
Neither of which have worked.
I have but one profile in /etc/network.d which contains the following: Description='Home Network' Interface=wlan0 Connection=wireless Security=wpa ESSID=AwesomeNetwork IP='dhcp' Key=<super-secret-password> ExcludeAuto=no
This works by starting it via "netctl start" as well as enabling it with netctl@.service. I tried with and without the ExcludeAuto=no line.
Am I missing something?
Regards -- Curtis Shimamoto sugar.and.scruffy@gmail.com
You did not miss anything, it was just broken. How about the new git version? I am confident that it works now.
Thanks for testing! - Jouke
Indeed it works now! After having played with it a bit, I am liking this interface more and more. I think I actually now prefer this over netcfg, and I love netcfg and all its simplicity. Thanks! Regards, -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On Sat, Dec 29, 2012 at 12:50 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
In order to deal with these issues I have forked netcfg. In the end, it turned out to be more of a rewrite. The result[1] I have called netctl. The main purpose of netctl is to provide profile-based networking in a systemd environment. Here are some of the changes with respect to netcfg.
Have you compared your aims/features to NetworkManager? In particular, do you see any deficiencies in nmcli that you will provide with netctl? Cheers, Tom
On Sun, Dec 30, 2012 at 1:36 AM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Dec 29, 2012 at 12:50 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
In order to deal with these issues I have forked netcfg. In the end, it turned out to be more of a rewrite. The result[1] I have called netctl. The main purpose of netctl is to provide profile-based networking in a systemd environment. Here are some of the changes with respect to netcfg.
Have you compared your aims/features to NetworkManager? In particular, do you see any deficiencies in nmcli that you will provide with netctl?
No, I have not done a comparison :-P. Although from the surface, it seems NetworkManager is far more complex. It is a Gnome project written in C with deep system integration (read: many dependencies). By contrast, netctl is a transparant and highly configurable collection of shell scripts. Furthermore, I doubt whether NetworkManager integrates as cleanly with systemd as netctl does. Read a netctl-generated service file if you are not convinced. Another alternative is ConnMan. It looks a little more lean than NetworkManager to my eyes, but I also haven't done a comparison with this one. Indeed, there is more than enough choice in network managers, but I actually think netctl has some things going for it. Its new codebase is easy to navigate, contribute to and maintain, and it doesn't invent wheels that are also invented by systemd. I agree that it would be nice if someone did a decent comparison of some of the network manager contestants. Regards, - Jouke
On Sat, Dec 29, 2012 at 12:50 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
Dear all,
For little over a year now, I have maintained netcfg. In doing so I have encountered three major problems. 1. Despite best efforts, the code and control flow of netcfg remain rather messy. 2. Usage of netcfg has many corner cases. 3. Some wheels are invented by both systemd and netcfg, but it is not easy to have netcfg make use of systemd.
In order to deal with these issues I have forked netcfg. In the end, it turned out to be more of a rewrite. The result[1] I have called netctl. The main purpose of netctl is to provide profile-based networking in a systemd environment. Here are some of the changes with respect to netcfg. a. Variables in profiles are CamelCase instead of UPPER_CASE to mimic systemd services. b. All configuration files are gone, configuration is done through the netctl utility, which interfaces systemd's systemctl. c. The only non-trivial usage that is provided is automatic configuration through ifplugd or wpa_actiond, formerly known as net-auto-wire{d,less}, now known as netctl-ifplugd and netctl-auto.
Some of the bugs that are fixed: d. Bind to network interfaces during boot, thus preventing the lack of a connection after boot recently encountered by owners of slow hardware. e. Allow more complex nameserver setups by using resolvconf (openresv).
Transition should not be hard. At any rate the three new man pages netctl(1), netctl.profile(5), and netctl.special(7) should answer all questions. Here is a basic outline of the changes required: - Rename variables in the profiles in /etc/network.d/ and unquote some of their values (mainly Interface=). - Run `netctl enable <profile>` for every profile in the old NETWORKS array. 'last' doesn't work this way, see netcfg.special(7). - Use `netctl list`/`netctl start <profile>` instead of `netcfg-menu`, wifi-menu remains available.
As half of the total code base has been removed and almost every line in the other half has been touched, I expect some easy-to-fix bugs to be introduced. Therefore I need testers. Please test netctl: I. $ git clone git://github.com/joukewitteveen/netctl.git II. $ cd netctl; make pkgbuild III. copy netctl-*.tar.xz and PKGBUILD to an empty directory IV. run makepkg in that directory V. install (using `pacman -U`) the resulting package.
During the 0.x series, I am not afraid of breaking compatibility. If all goes well, I would like to replace netcfg with netctl starting with a 1.0 release. I know many people don't like the idea of dropping netcfg or netcfg compatibility, but I think the situation of netctl is far easier to maintain. Personally, I don't see much future in netcfg besides an optional compatibility layer on top of netctl.
Thanks to all testers! - Jouke
I have tagged a 0.2 release of netctl. It is surprisingly stable on my machines and the only stuff I haven't seen working yet (because I know of no one who tested it) are the following connections: bond, bridge, pppoe, tunnel, tuntap, vlan. I would still like a Developer's comment on the (viability of the) project and additionally would like to move the repository back to projects.archlinux.org. The next thing on my list is to post a call for testers on the forums. Keep on testing, - Jouke
Am 08.01.2013 10:44, schrieb Jouke Witteveen:
I have tagged a 0.2 release of netctl. It is surprisingly stable on my machines and the only stuff I haven't seen working yet (because I know of no one who tested it) are the following connections: bond, bridge, pppoe, tunnel, tuntap, vlan.
I would still like a Developer's comment on the (viability of the) project and additionally would like to move the repository back to projects.archlinux.org.
I'm incredibly far behind on Arch things to do. I'll have a look as soon as I can.
On Tue, Jan 8, 2013 at 4:44 AM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
I have tagged a 0.2 release of netctl.
Working fine w/ my trivial example (static). The `make pkgbuild` is kind of neat, but the AUR should be used in my opinion.
On Tue, Jan 08, 2013 at 06:30:21PM -0500, member graysky wrote:
On Tue, Jan 8, 2013 at 4:44 AM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
I have tagged a 0.2 release of netctl.
Working fine w/ my trivial example (static). The `make pkgbuild` is kind of neat, but the AUR should be used in my opinion.
There is an aur package [0]. It even comes with zsh completion if you're into that. [0] https://aur.archlinux.org/packages/netctl-git/ -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F
On 01/08/13 at 05:42pm, William Giokas wrote:
On Tue, Jan 08, 2013 at 06:30:21PM -0500, member graysky wrote:
On Tue, Jan 8, 2013 at 4:44 AM, Jouke Witteveen <j.witteveen@gmail.com> wrote:
I have tagged a 0.2 release of netctl.
Working fine w/ my trivial example (static). The `make pkgbuild` is kind of neat, but the AUR should be used in my opinion.
There is an aur package [0]. It even comes with zsh completion if you're into that.
[0] https://aur.archlinux.org/packages/netctl-git/
-- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F
Cool, I am into zsh completion! I have just been pulling from the git source everytime there has been an update. Anyway, I just want to report that this version seems to be working great in my also trivial situation. The last version seemed to have trouble connecting to the network at work. I tried with wifi-menu, and a handwritten config. Besides not connecting, I had no time to further diagnose the problem. In any case, 0.2 works perfectly, and netctl-auto is performing excellent between the three networks I frequent. Regards, -- Curtis Shimamoto sugar.and.scruffy@gmail.com
I took a quick glance at the code a minute ago and I am confused. I was wondering how you solved the problem of systemd starting the network services before the devices appear. And as it turned out, it doesn't! When you activate netctl@PROFILE.service, the netctl profile will often activate before the needed network devices appear. That is precisely the problem I addressed by my generator-based solution in my latest netcfg patches. Apart from reduced code size (which is good), this is no improvement over netcfg.
Am 01.02.2013 00:25, schrieb Thomas Bächler:
I took a quick glance at the code a minute ago and I am confused. I was wondering how you solved the problem of systemd starting the network services before the devices appear.
And as it turned out, it doesn't! When you activate netctl@PROFILE.service, the netctl profile will often activate before the needed network devices appear. That is precisely the problem I addressed by my generator-based solution in my latest netcfg patches.
Apart from reduced code size (which is good), this is no improvement over netcfg.
Furthermore, every profile requires an interface name. For generic ppp or 3g profiles, for example, there is no interface name prior to establishing a connection - how do you plan to implement such profiles?
On Fri, Feb 1, 2013 at 12:29 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.02.2013 00:25, schrieb Thomas Bächler:
I took a quick glance at the code a minute ago and I am confused. I was wondering how you solved the problem of systemd starting the network services before the devices appear.
And as it turned out, it doesn't! When you activate netctl@PROFILE.service, the netctl profile will often activate before the needed network devices appear. That is precisely the problem I addressed by my generator-based solution in my latest netcfg patches.
It does. Use `netctl enable PROFILE` and you're all set.
Apart from reduced code size (which is good), this is no improvement over netcfg.
Furthermore, every profile requires an interface name. For generic ppp or 3g profiles, for example, there is no interface name prior to establishing a connection - how do you plan to implement such profiles?
When such names are really unknown a priori, you might need something different than netctl. Compared to netcfg, netctl tries to be simple and reasonably good at what it does. It no longer makes coffee, but when you want to connect to a network via a network interface, it is there for you. - Jouke
Am 01.02.2013 00:32, schrieb Jouke Witteveen:
On Fri, Feb 1, 2013 at 12:29 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.02.2013 00:25, schrieb Thomas Bächler:
I took a quick glance at the code a minute ago and I am confused. I was wondering how you solved the problem of systemd starting the network services before the devices appear.
And as it turned out, it doesn't! When you activate netctl@PROFILE.service, the netctl profile will often activate before the needed network devices appear. That is precisely the problem I addressed by my generator-based solution in my latest netcfg patches.
It does. Use `netctl enable PROFILE` and you're all set.
I didn't see this before. Now that's clever.
Apart from reduced code size (which is good), this is no improvement over netcfg.
I think I need to take that back.
Furthermore, every profile requires an interface name. For generic ppp or 3g profiles, for example, there is no interface name prior to establishing a connection - how do you plan to implement such profiles?
When such names are really unknown a priori, you might need something different than netctl.
Why? This is true for all ppp-based connections, and they make lots of sense in network profiles.
Compared to netcfg, netctl tries to be simple and reasonably good at what it does. It no longer makes coffee, but when you want to connect to a network via a network interface, it is there for you.
Where is the interface name requirement even needed?
On Fri, Feb 1, 2013 at 12:46 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.02.2013 00:32, schrieb Jouke Witteveen:
On Fri, Feb 1, 2013 at 12:29 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.02.2013 00:25, schrieb Thomas Bächler: Furthermore, every profile requires an interface name. For generic ppp or 3g profiles, for example, there is no interface name prior to establishing a connection - how do you plan to implement such profiles?
When such names are really unknown a priori, you might need something different than netctl.
Why? This is true for all ppp-based connections, and they make lots of sense in network profiles.
Compared to netcfg, netctl tries to be simple and reasonably good at what it does. It no longer makes coffee, but when you want to connect to a network via a network interface, it is there for you.
Where is the interface name requirement even needed?
Currently the code does not need it per se. It is used to determine whether a conflicting profile (same interface) is already started. If you look at the old ppp code, you see that it doesn't need netctl at all. It is easy to write your own systemd unit that does everything netctl would do. As far as uncommon connections go, I still don't have any feedback on connection types other than ethernet and wireless. Regards, - Jouke
Am 01.02.2013 16:43, schrieb Jouke Witteveen:
If you look at the old ppp code, you see that it doesn't need netctl at all. It is easy to write your own systemd unit that does everything netctl would do.
Yes, but a future 3g profile, which is really really needed, would work without interfaces. You would only specify either a TTY (or optionally a bluetooth BDID and port for rfcomm) and some options like the APN, and it would establish a connection. I never got motivated enough to write that, sadly.
As far as uncommon connections go, I still don't have any feedback on connection types other than ethernet and wireless.
I could probably test PPPoE and bridge, when I finally get to break my computers again.
On Fri, Feb 1, 2013 at 4:50 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.02.2013 16:43, schrieb Jouke Witteveen:
If you look at the old ppp code, you see that it doesn't need netctl at all. It is easy to write your own systemd unit that does everything netctl would do.
Yes, but a future 3g profile, which is really really needed, would work without interfaces. You would only specify either a TTY (or optionally a bluetooth BDID and port for rfcomm) and some options like the APN, and it would establish a connection. I never got motivated enough to write that, sadly.
Wouldn't a rfcomm device be acceptable as an interface? I think it might just work. We might want to source the connection file too on `netctl enable`, so that we can set BindsToInterfaces to an empty array over there.
As far as uncommon connections go, I still don't have any feedback on connection types other than ethernet and wireless.
I could probably test PPPoE and bridge, when I finally get to break my computers again.
One of the reasons I noted this is because I think the vast majority of users is primarily interested in ethernet/wireless functionality. Since that seems to work OK, I think we can already start the migration. The next steps would be: - move openresolv to [core] - add netctl to [testing] Regards, - Jouke
To smaller criticism: ip has: [[ $addr == */* ]] || addr+="/24" This is a stupid default, and it is inconsistent to what is done in IPv6. Just leave it out - every configuration needs both the IP and the netmask, a network cannot be configured without it!
participants (6)
-
Curtis Shimamoto
-
Jouke Witteveen
-
member graysky
-
Thomas Bächler
-
Tom Gundersen
-
William Giokas