| Message ID | 20130128103433.GA1247@Mindship-03.lan |
|---|---|
| State | Rejected |
| Headers | show |
On Mon, 2013-01-28 at 11:34 +0100, Jouke Witteveen wrote: > Follow an FHS proposal[1] that is already implemented on some major > distributions. Shouldn't those distros carry the patch then? :) johannes
On Mon, Jan 28, 2013 at 11:51 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Mon, 2013-01-28 at 11:34 +0100, Jouke Witteveen wrote: >> Follow an FHS proposal[1] that is already implemented on some major >> distributions. > > Shouldn't those distros carry the patch then? :) > > johannes > Could be, but if all major distros switch, waiting for the foundation can look a lot like testing your patience ;-). - Jouke
Right patch is : should be choosen at compilation or run time not this :@ IMHO On Mon, Jan 28, 2013 at 7:09 AM, Jouke Witteveen <j.witteveen@gmail.com>wrote: > On Mon, Jan 28, 2013 at 11:51 AM, Johannes Berg > <johannes@sipsolutions.net> wrote: > > On Mon, 2013-01-28 at 11:34 +0100, Jouke Witteveen wrote: > >> Follow an FHS proposal[1] that is already implemented on some major > >> distributions. > > > > Shouldn't those distros carry the patch then? :) > > > > johannes > > > > Could be, but if all major distros switch, waiting for the foundation > can look a lot like testing your patience ;-). > > - Jouke > _______________________________________________ > HostAP mailing list > HostAP@lists.shmoo.com > http://lists.shmoo.com/mailman/listinfo/hostap >
On Mon, Jan 28, 2013 at 3:11 PM, sven falempin <sven.falempin@gmail.com> wrote: > Right patch is : > should be choosen at compilation or run time > not this :@ > > IMHO > > On Mon, Jan 28, 2013 at 7:09 AM, Jouke Witteveen <j.witteveen@gmail.com> > wrote: >> >> On Mon, Jan 28, 2013 at 11:51 AM, Johannes Berg >> <johannes@sipsolutions.net> wrote: >> > On Mon, 2013-01-28 at 11:34 +0100, Jouke Witteveen wrote: >> >> Follow an FHS proposal[1] that is already implemented on some major >> >> distributions. >> > >> > Shouldn't those distros carry the patch then? :) >> > >> > johannes >> > >> >> Could be, but if all major distros switch, waiting for the foundation >> can look a lot like testing your patience ;-). >> >> - Jouke It already is a compile-time option, the patch just changes the default to something that better suits the current landscape. Most of the hassle is documentation updates. - Jouke
On 01/28/2013 11:11 AM, Jouke Witteveen wrote: > On Mon, Jan 28, 2013 at 3:11 PM, sven falempin <sven.falempin@gmail.com> wrote: >> Right patch is : >> should be choosen at compilation or run time >> not this :@ >> >> IMHO >> >> On Mon, Jan 28, 2013 at 7:09 AM, Jouke Witteveen <j.witteveen@gmail.com> >> wrote: >>> >>> On Mon, Jan 28, 2013 at 11:51 AM, Johannes Berg >>> <johannes@sipsolutions.net> wrote: >>>> On Mon, 2013-01-28 at 11:34 +0100, Jouke Witteveen wrote: >>>>> Follow an FHS proposal[1] that is already implemented on some major >>>>> distributions. >>>> >>>> Shouldn't those distros carry the patch then? :) >>>> >>>> johannes >>>> >>> >>> Could be, but if all major distros switch, waiting for the foundation >>> can look a lot like testing your patience ;-). >>> >>> - Jouke > > It already is a compile-time option, the patch just changes the > default to something that better suits the current landscape. > Most of the hassle is documentation updates. It's going to break older systems...I think you should leave the defaults as is... Or, perhaps detect that you are on a 'new' system at compile time and change the new default in that case only. Thanks, Ben
On Mon, Jan 28, 2013 at 9:08 PM, Ben Greear <greearb@candelatech.com> wrote: > On 01/28/2013 11:11 AM, Jouke Witteveen wrote: >> >> On Mon, Jan 28, 2013 at 3:11 PM, sven falempin <sven.falempin@gmail.com> >> wrote: >>> >>> Right patch is : >>> should be choosen at compilation or run time >>> not this :@ >>> >>> IMHO >>> >>> On Mon, Jan 28, 2013 at 7:09 AM, Jouke Witteveen <j.witteveen@gmail.com> >>> wrote: >>>> >>>> >>>> On Mon, Jan 28, 2013 at 11:51 AM, Johannes Berg >>>> <johannes@sipsolutions.net> wrote: >>>>> >>>>> On Mon, 2013-01-28 at 11:34 +0100, Jouke Witteveen wrote: >>>>>> >>>>>> Follow an FHS proposal[1] that is already implemented on some major >>>>>> distributions. >>>>> >>>>> >>>>> Shouldn't those distros carry the patch then? :) >>>>> >>>>> johannes >>>>> >>>> >>>> Could be, but if all major distros switch, waiting for the foundation >>>> can look a lot like testing your patience ;-). >>>> >>>> - Jouke >> >> >> It already is a compile-time option, the patch just changes the >> default to something that better suits the current landscape. >> Most of the hassle is documentation updates. > > > It's going to break older systems...I think you should > leave the defaults as is... We could put it in for a later version (3.x?), as far as I can see, most systems are still on 1.x. As long as the /run directory exists, I expect breakage to be minor. > Or, perhaps detect that you are on a 'new' system at compile time and > change the new default in that case only. It is unclear to me what constitutes a 'new' system. Any that has /run? I think it is best not to over-complicate things and either take the patch more or less like this, or leave it until the foundation makes a move (if ever). I assembled the patch mainly to see how deep integration goes. In fact, I am not extremely bothered by the issue on a day-to-day basis. The reason I submitted it is mainly to start the discussion. Perhaps some feel strongly in favor of it. Regards, - Jouke
On Mon, Jan 28, 2013 at 11:04 PM, Jouke Witteveen <j.witteveen@gmail.com> wrote: > On Mon, Jan 28, 2013 at 9:08 PM, Ben Greear <greearb@candelatech.com> wrote: >> On 01/28/2013 11:11 AM, Jouke Witteveen wrote: >>> >>> On Mon, Jan 28, 2013 at 3:11 PM, sven falempin <sven.falempin@gmail.com> >>> wrote: >>>> >>>> Right patch is : >>>> should be choosen at compilation or run time >>>> not this :@ >>>> >>>> IMHO >>>> >>>> On Mon, Jan 28, 2013 at 7:09 AM, Jouke Witteveen <j.witteveen@gmail.com> >>>> wrote: >>>>> >>>>> >>>>> On Mon, Jan 28, 2013 at 11:51 AM, Johannes Berg >>>>> <johannes@sipsolutions.net> wrote: >>>>>> >>>>>> On Mon, 2013-01-28 at 11:34 +0100, Jouke Witteveen wrote: >>>>>>> >>>>>>> Follow an FHS proposal[1] that is already implemented on some major >>>>>>> distributions. >>>>>> >>>>>> >>>>>> Shouldn't those distros carry the patch then? :) >>>>>> >>>>>> johannes >>>>>> >>>>> >>>>> Could be, but if all major distros switch, waiting for the foundation >>>>> can look a lot like testing your patience ;-). >>>>> >>>>> - Jouke >>> >>> >>> It already is a compile-time option, the patch just changes the >>> default to something that better suits the current landscape. >>> Most of the hassle is documentation updates. >> >> >> It's going to break older systems...I think you should >> leave the defaults as is... > > We could put it in for a later version (3.x?), as far as I can see, > most systems are still on 1.x. As long as the /run directory exists, I > expect breakage to be minor. > >> Or, perhaps detect that you are on a 'new' system at compile time and >> change the new default in that case only. > > It is unclear to me what constitutes a 'new' system. Any that has > /run? I think it is best not to over-complicate things and either take > the patch more or less like this, or leave it until the foundation > makes a move (if ever). > > I assembled the patch mainly to see how deep integration goes. In > fact, I am not extremely bothered by the issue on a day-to-day basis. > The reason I submitted it is mainly to start the discussion. Perhaps > some feel strongly in favor of it. Nevertheless I do think this should be merged. The critiques by Sven Falempin and Ben Greear do not seem entirely correct and at least the following distributions have already made the switch (so things should only improve there): Arch Linux, Debian, Fedora, Suse, Ubuntu. > Regards, > - Jouke
On 01/31/2013 02:10 PM, Jouke Witteveen wrote: > Nevertheless I do think this should be merged. The critiques by Sven > Falempin and Ben Greear do not seem entirely correct and at least the > following distributions have already made the switch (so things should > only improve there): Arch Linux, Debian, Fedora, Suse, Ubuntu. They may have, but you seem to be simply overstepping the fact that there are a lot of deployed systems out there that do not have made the switch and may have no intention to make it at all. Can you hold the patch for another 5 years so those system are safely turned to compost ;-) >> > Regards, >> > - Jouke Regards, Arend
Arend, I fear that those "deployed systems" that don't do the switch from /var/run to /run will also not do the switch from wpa_supplicant_<antique-version> to wpa_supplicant_2.x. 2013/1/31 Arend van Spriel <arend@broadcom.com> > On 01/31/2013 02:10 PM, Jouke Witteveen wrote: > > Nevertheless I do think this should be merged. The critiques by Sven > > Falempin and Ben Greear do not seem entirely correct and at least the > > following distributions have already made the switch (so things should > > only improve there): Arch Linux, Debian, Fedora, Suse, Ubuntu. > > They may have, but you seem to be simply overstepping the fact that > there are a lot of deployed systems out there that do not have made the > switch and may have no intention to make it at all. Can you hold the > patch for another 5 years so those system are safely turned to compost ;-) > > >> > Regards, > >> > - Jouke > > Regards, > Arend > > _______________________________________________ > HostAP mailing list > HostAP@lists.shmoo.com > http://lists.shmoo.com/mailman/listinfo/hostap >
On Fri, Feb 1, 2013 at 5:03 AM, Holger Schurig <holgerschurig@gmail.com>wrote: > Arend, I fear that those "deployed systems" that don't do the switch from > /var/run to /run will also not do the switch from > wpa_supplicant_<antique-version> to wpa_supplicant_2.x. > > > 2013/1/31 Arend van Spriel <arend@broadcom.com> > >> On 01/31/2013 02:10 PM, Jouke Witteveen wrote: >> > Nevertheless I do think this should be merged. The critiques by Sven >> > Falempin and Ben Greear do not seem entirely correct and at least the >> > following distributions have already made the switch (so things should >> > only improve there): Arch Linux, Debian, Fedora, Suse, Ubuntu. >> >> They may have, but you seem to be simply overstepping the fact that >> there are a lot of deployed systems out there that do not have made the >> switch and may have no intention to make it at all. Can you hold the >> patch for another 5 years so those system are safely turned to compost ;-) >> >> >> > Regards, >> >> > - Jouke >> >> i just dont like constant in code, if all the linux system choose to yet again to become 'different' and adopt /run instead of /var/run 'because /var is not mounted' i see no reason for keepinf /var//run as a default, but a DEFINE in config.h or even in .config would make a good deal , wouldnt it ? > Regards, >> Arend >> >> _______________________________________________ >> HostAP mailing list >> HostAP@lists.shmoo.com >> http://lists.shmoo.com/mailman/listinfo/hostap >> > > > _______________________________________________ > HostAP mailing list > HostAP@lists.shmoo.com > http://lists.shmoo.com/mailman/listinfo/hostap > >
On Mon, Jan 28, 2013 at 11:34:33AM +0100, Jouke Witteveen wrote: > Follow an FHS proposal[1] that is already implemented on some major > distributions. > > [1] https://bugs.linuxfoundation.org/show_bug.cgi?id=718 How many of those distributions that have implemented this do not have a symlink from /var/run to /run? I'm apparently using one system where that change has happened, but to this date, I had not noticed any issues with using /var/run never mind being aware of such change having occurred. It would sound more likely to me that new systems have such symlink than older ones handle /run.. Not that this really should matter much since apart from the wpa_gui one (and wpa_priv, which almost nobody uses), these should all be configurable at both build and runtime. Please also note that wpa_supplicant and hostapd are supposed to work on systems other than Linux, too.. In addition, many Linux systems seem to be happily using other locations even without this patch.
On Mon, Jan 28, 2013 at 11:34:33AM +0100, Jouke Witteveen wrote: > Follow an FHS proposal[1] that is already implemented on some major > distributions. > > [1] https://bugs.linuxfoundation.org/show_bug.cgi?id=718 Actually.. That proposal seems to indicate that programs may continue to use /var/run for the purposes of backwards compatibility and some linked discussion seemed to indicate that programs "should" and not just "may" do so.. Could you please provide a pointer to the FHS draft that justifies this change for wpa_supplicant or use cases where /run has to be used instead of /var/run? It would sound simplest to continue using /var/run since FHS specification seems to indicate that this directory is required to exist (e.g., as a symlink or some other means of linking it to to /run). This would not cause problems for existing systems or non-Linux platforms and should continue to work with new Linux systems for that matter.
On Sat, Feb 2, 2013 at 10:52 PM, Jouni Malinen <j@w1.fi> wrote: > On Mon, Jan 28, 2013 at 11:34:33AM +0100, Jouke Witteveen wrote: >> Follow an FHS proposal[1] that is already implemented on some major >> distributions. >> >> [1] https://bugs.linuxfoundation.org/show_bug.cgi?id=718 > > How many of those distributions that have implemented this do not have a > symlink from /var/run to /run? I'm apparently using one system where > that change has happened, but to this date, I had not noticed any issues > with using /var/run never mind being aware of such change having > occurred. It would sound more likely to me that new systems have such > symlink than older ones handle /run.. Not that this really should matter > much since apart from the wpa_gui one (and wpa_priv, which almost nobody > uses), these should all be configurable at both build and runtime. There is a reason for the migration ---quote Matthew Miller------ System services / applications need to store run-time variable data somewhere before /var/run may be available. ---end quote------ This would make /run a sensible default. The main problem with the buildtime configuration is that the choice is not reflected in the documentation. In other words: there is a hardcoded choice in the documentation. > Please also note that wpa_supplicant and hostapd are supposed to work on > systems other than Linux, too.. In addition, many Linux systems seem to > be happily using other locations even without this patch. I didn't really think of that. It sounds like a good reason to not take the patch as-is. Just for laughs: /var/run does not appear in any Unix Directory Structure standard I could find. > Actually.. That proposal seems to indicate that programs may continue to > use /var/run for the purposes of backwards compatibility and some linked > discussion seemed to indicate that programs "should" and not just "may" > do so.. Could you please provide a pointer to the FHS draft that > justifies this change for wpa_supplicant or use cases where /run has to > be used instead of /var/run? > > It would sound simplest to continue using /var/run since FHS > specification seems to indicate that this directory is required to exist > (e.g., as a symlink or some other means of linking it to to /run). This > would not cause problems for existing systems or non-Linux platforms and > should continue to work with new Linux systems for that matter. Indeed, these observations are enough reason to keep things the way they are. At least it has now turned from a convention into a decision :-). Regards, - Jouke
On 02/02/2013 23:02, Jouni Malinen wrote: > On Mon, Jan 28, 2013 at 11:34:33AM +0100, Jouke Witteveen wrote: >> Follow an FHS proposal[1] that is already implemented on some major >> distributions. >> >> [1] https://bugs.linuxfoundation.org/show_bug.cgi?id=718 > > Actually.. That proposal seems to indicate that programs may continue to > use /var/run for the purposes of backwards compatibility and some linked > discussion seemed to indicate that programs "should" and not just "may" > do so.. Could you please provide a pointer to the FHS draft that > justifies this change for wpa_supplicant or use cases where /run has to > be used instead of /var/run? When /var is a NFS over a WPA2-secured Wi-Fi access point. In that case, wpasupplicant is required to run before /var is mounted. (Yes, this is evil, but i know Debian actually support it)
On Sat, Feb 02, 2013 at 11:17:13PM +0100, Nicolas Cavallari wrote: > When /var is a NFS over a WPA2-secured Wi-Fi access point. In that case, > wpasupplicant is required to run before /var is mounted. Uh, lovely. I would assume this actually works fine with runtime configuration. I have no problems noting this type of special cases in the documentation, but I don't think this would be enough of a justification to change the default behavior.
On 02/03/2013 02:56 PM, Jouni Malinen wrote: > On Sat, Feb 02, 2013 at 11:17:13PM +0100, Nicolas Cavallari wrote: >> When /var is a NFS over a WPA2-secured Wi-Fi access point. In that case, >> wpasupplicant is required to run before /var is mounted. > > Uh, lovely. I would assume this actually works fine with runtime > configuration. I have no problems noting this type of special cases in > the documentation, but I don't think this would be enough of a > justification to change the default behavior. > And in a really sick and twisted world someone could even mount something on /run. Probably won't work when there are already file handles created in /run. Gr. AvS
On Sun, Feb 3, 2013 at 6:31 PM, Arend van Spriel <arend@broadcom.com> wrote: > On 02/03/2013 02:56 PM, Jouni Malinen wrote: >> On Sat, Feb 02, 2013 at 11:17:13PM +0100, Nicolas Cavallari wrote: >>> When /var is a NFS over a WPA2-secured Wi-Fi access point. In that case, >>> wpasupplicant is required to run before /var is mounted. >> >> Uh, lovely. I would assume this actually works fine with runtime >> configuration. I have no problems noting this type of special cases in >> the documentation, but I don't think this would be enough of a >> justification to change the default behavior. >> > > And in a really sick and twisted world someone could even mount > something on /run. Probably won't work when there are already file > handles created in /run. > > Gr. AvS > The idea is that you don't do that. I think changing the default behavior is more or less the right thing to do for Linux-based systems, but it is currently not easy to have such a dependency for the documentation at build time. Hence: either keep it as is, or adopt some fancy build system. The latter sounds like extreme overkill for this issue to me. - Jouke
diff --git a/wpa_supplicant/ChangeLog b/wpa_supplicant/ChangeLog index 3f10e11..73e9a7f 100644 --- a/wpa_supplicant/ChangeLog +++ b/wpa_supplicant/ChangeLog @@ -3,6 +3,7 @@ ChangeLog for wpa_supplicant ????-??-?? - v2.1 * added support for simulataneous authentication of equals (SAE) for stronger password-based authentication with WPA2-Personal + * migrate from /var/run to /run 2013-01-12 - v2.0 * removed Qt3-based wpa_gui (obsoleted by wpa_qui-qt4) diff --git a/wpa_supplicant/README b/wpa_supplicant/README index d84e61e..f0ee234 100644 --- a/wpa_supplicant/README +++ b/wpa_supplicant/README @@ -504,7 +504,7 @@ Example configuration files for some common configurations: network # allow frontend (e.g., wpa_cli) to be used by all users in 'wheel' group -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant ctrl_interface_group=wheel # # home network; allow all valid ciphers @@ -534,7 +534,7 @@ network={ 2) WPA-RADIUS/EAP-PEAP/MSCHAPv2 with RADIUS servers that use old peaplabel (e.g., Funk Odyssey and SBR, Meetinghouse Aegis, Interlink RAD-Series) -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="example" @@ -552,7 +552,7 @@ network={ 3) EAP-TTLS/EAP-MD5-Challenge configuration with anonymous identity for the unencrypted use. Real identity is sent only within an encrypted TLS tunnel. -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="example" @@ -570,7 +570,7 @@ network={ 4) IEEE 802.1X (i.e., no WPA) with dynamic WEP keys (require both unicast and broadcast); use EAP-TLS for authentication -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="1x-test" @@ -591,7 +591,7 @@ network={ selected SSID. This is mostly for testing and is not recommended for normal use. -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="example" @@ -618,7 +618,7 @@ network={ 6) Authentication for wired Ethernet. This can be used with 'wired' or 'roboswitch' interface (-Dwired or -Droboswitch on command line). -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant ctrl_interface_group=wheel ap_scan=0 network={ @@ -772,7 +772,7 @@ wpa_cli [-p<path to ctrl sockets>] [-i<ifname>] [-hvB] [-a<action file>] \ -a = run in daemon mode executing the action file based on events from wpa_supplicant -B = run a daemon in the background - default path: /var/run/wpa_supplicant + default path: /run/wpa_supplicant default interface: first interface found in socket path @@ -867,12 +867,12 @@ network interfaces and then add a network interface and configure a network (SSID): # Start wpa_supplicant in the background -wpa_supplicant -g/var/run/wpa_supplicant-global -B +wpa_supplicant -g/run/wpa_supplicant-global -B # Add a new interface (wlan0, no configuration file, driver=wext, and # enable control interface) -wpa_cli -g/var/run/wpa_supplicant-global interface_add wlan0 \ - "" wext /var/run/wpa_supplicant +wpa_cli -g/run/wpa_supplicant-global interface_add wlan0 \ + "" wext /run/wpa_supplicant # Configure a network using the newly added network interface: wpa_cli -iwlan0 add_network @@ -888,7 +888,7 @@ wpa_cli -iwlan0 enable_network 0 # with the WPA-PSK network using SSID test. # Remove network interface -wpa_cli -g/var/run/wpa_supplicant-global interface_remove wlan0 +wpa_cli -g/run/wpa_supplicant-global interface_remove wlan0 Privilege separation @@ -926,14 +926,14 @@ Example configuration: - create user group for users that are allowed to use wpa_supplicant ('wpapriv' in this example) and assign users that should be able to use wpa_supplicant into that group -- create /var/run/wpa_priv directory for UNIX domain sockets and control +- create /run/wpa_priv directory for UNIX domain sockets and control user access by setting it accessible only for the wpapriv group: - mkdir /var/run/wpa_priv - chown root:wpapriv /var/run/wpa_priv - chmod 0750 /var/run/wpa_priv + mkdir /run/wpa_priv + chown root:wpapriv /run/wpa_priv + chmod 0750 /run/wpa_priv - start wpa_priv as root (e.g., from system startup scripts) with the enabled interfaces configured on the command line: - wpa_priv -B -P /var/run/wpa_priv.pid wext:ath0 + wpa_priv -B -P /run/wpa_priv.pid wext:ath0 - run wpa_supplicant as non-root with a user that is in wpapriv group: wpa_supplicant -i ath0 -c wpa_supplicant.conf diff --git a/wpa_supplicant/README-P2P b/wpa_supplicant/README-P2P index fb99c7b..e9fa43c 100644 --- a/wpa_supplicant/README-P2P +++ b/wpa_supplicant/README-P2P @@ -42,7 +42,7 @@ for P2P may be set. In order to make the devices easier to recognize, device_name and device_type should be specified. For example, something like this should be included: -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant device_name=My P2P Device device_type=1-0050F204-1 diff --git a/wpa_supplicant/README-WPS b/wpa_supplicant/README-WPS index 1ea9843..9835e55 100644 --- a/wpa_supplicant/README-WPS +++ b/wpa_supplicant/README-WPS @@ -243,7 +243,7 @@ wpa_supplicant -Dnone -c er.conf -ieth0 Sample er.conf: -ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=admin +ctrl_interface=DIR=/run/wpa_supplicant GROUP=admin device_name=WPS External Registrar diff --git a/wpa_supplicant/config.h b/wpa_supplicant/config.h index 0c3cb9a..83c7d8f 100644 --- a/wpa_supplicant/config.h +++ b/wpa_supplicant/config.h @@ -323,8 +323,8 @@ struct wpa_config { * information and configuration. The socket file will be named based * on the interface name, so multiple %wpa_supplicant processes can be * run at the same time if more than one interface is used. - * /var/run/wpa_supplicant is the recommended directory for sockets and - * by default, wpa_cli will use it when trying to connect with + * /run/wpa_supplicant is the recommended directory for sockets and by + * default, wpa_cli will use it when trying to connect with * %wpa_supplicant. * * Access control for the control interface can be configured @@ -342,8 +342,8 @@ struct wpa_config { * interface access to this group. * * When configuring both the directory and group, use following format: - * DIR=/var/run/wpa_supplicant GROUP=wheel - * DIR=/var/run/wpa_supplicant GROUP=0 + * DIR=/run/wpa_supplicant GROUP=wheel + * DIR=/run/wpa_supplicant GROUP=0 * (group can be either group name or gid) * * For UDP connections (default on Windows): The value will be ignored. diff --git a/wpa_supplicant/doc/docbook/wpa_priv.sgml b/wpa_supplicant/doc/docbook/wpa_priv.sgml index eb907a8..9cb5770 100644 --- a/wpa_supplicant/doc/docbook/wpa_priv.sgml +++ b/wpa_supplicant/doc/docbook/wpa_priv.sgml @@ -56,14 +56,14 @@ <para>Create user group (e.g., wpapriv) and assign users that should be able to use wpa_supplicant into that group.</para> - <para>Create /var/run/wpa_priv directory for UNIX domain sockets and + <para>Create /run/wpa_priv directory for UNIX domain sockets and control user access by setting it accessible only for the wpapriv group:</para> <blockquote><programlisting> -mkdir /var/run/wpa_priv -chown root:wpapriv /var/run/wpa_priv -chmod 0750 /var/run/wpa_priv +mkdir /run/wpa_priv +chown root:wpapriv /run/wpa_priv +chmod 0750 /run/wpa_priv </programlisting></blockquote> <para>Start <command>wpa_priv</command> as root (e.g., from system @@ -71,7 +71,7 @@ chmod 0750 /var/run/wpa_priv command line:</para> <blockquote><programlisting> -wpa_priv -B -c /var/run/wpa_priv -P /var/run/wpa_priv.pid wext:wlan0 +wpa_priv -B -c /run/wpa_priv -P /run/wpa_priv.pid wext:wlan0 </programlisting></blockquote> <para>Run <command>wpa_supplicant</command> as non-root with a user @@ -89,7 +89,7 @@ wpa_supplicant -i ath0 -c wpa_supplicant.conf <term>-c ctrl path</term> <listitem><para>Specify the path to wpa_priv control directory - (Default: /var/run/wpa_priv/).</para></listitem> + (Default: /run/wpa_priv/).</para></listitem> </varlistentry> <varlistentry> diff --git a/wpa_supplicant/doc/docbook/wpa_supplicant.conf.sgml b/wpa_supplicant/doc/docbook/wpa_supplicant.conf.sgml index 462039d..e2a40db 100644 --- a/wpa_supplicant/doc/docbook/wpa_supplicant.conf.sgml +++ b/wpa_supplicant/doc/docbook/wpa_supplicant.conf.sgml @@ -46,7 +46,7 @@ <blockquote><programlisting> # allow frontend (e.g., wpa_cli) to be used by all users in 'wheel' group -ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel +ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel # # home network; allow all valid ciphers network={ @@ -79,7 +79,7 @@ network={ Aegis, Interlink RAD-Series)</para> <blockquote><programlisting> -ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel +ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel network={ ssid="example" scan_ssid=1 @@ -101,7 +101,7 @@ network={ <blockquote><programlisting> -ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel +ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel network={ ssid="example" scan_ssid=1 @@ -123,7 +123,7 @@ network={ authentication</para> <blockquote><programlisting> -ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel +ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel network={ ssid="1x-test" scan_ssid=1 @@ -148,7 +148,7 @@ network={ use.</para> <blockquote><programlisting> -ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel +ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel network={ ssid="example" scan_ssid=1 @@ -178,7 +178,7 @@ network={ (-Dwired or -Droboswitch on command line).</para> <blockquote><programlisting> -ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel +ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel ap_scan=0 network={ key_mgmt=IEEE8021X diff --git a/wpa_supplicant/examples/ieee8021x.conf b/wpa_supplicant/examples/ieee8021x.conf index e8a5503..7147191 100644 --- a/wpa_supplicant/examples/ieee8021x.conf +++ b/wpa_supplicant/examples/ieee8021x.conf @@ -1,6 +1,6 @@ # IEEE 802.1X with dynamic WEP keys using EAP-PEAP/MSCHAPv2 -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant network={ ssid="example 802.1x network" diff --git a/wpa_supplicant/examples/plaintext.conf b/wpa_supplicant/examples/plaintext.conf index 542ac1d..bd17d18 100644 --- a/wpa_supplicant/examples/plaintext.conf +++ b/wpa_supplicant/examples/plaintext.conf @@ -1,6 +1,6 @@ # Plaintext (no encryption) network -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant network={ ssid="example open network" diff --git a/wpa_supplicant/examples/wep.conf b/wpa_supplicant/examples/wep.conf index 9c7b55f..4896934 100644 --- a/wpa_supplicant/examples/wep.conf +++ b/wpa_supplicant/examples/wep.conf @@ -1,6 +1,6 @@ # Static WEP keys -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant network={ ssid="example wep network" diff --git a/wpa_supplicant/examples/wpa-psk-tkip.conf b/wpa_supplicant/examples/wpa-psk-tkip.conf index 93d7fc2..15b309f 100644 --- a/wpa_supplicant/examples/wpa-psk-tkip.conf +++ b/wpa_supplicant/examples/wpa-psk-tkip.conf @@ -1,6 +1,6 @@ # WPA-PSK/TKIP -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant network={ ssid="example wpa-psk network" diff --git a/wpa_supplicant/examples/wpa2-eap-ccmp.conf b/wpa_supplicant/examples/wpa2-eap-ccmp.conf index d7a64d8..db93708 100644 --- a/wpa_supplicant/examples/wpa2-eap-ccmp.conf +++ b/wpa_supplicant/examples/wpa2-eap-ccmp.conf @@ -1,6 +1,6 @@ # WPA2-EAP/CCMP using EAP-TLS -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant network={ ssid="example wpa2-eap network" diff --git a/wpa_supplicant/examples/wps-nfc.py b/wpa_supplicant/examples/wps-nfc.py index 0cfc1f6..c7da9a5 100755 --- a/wpa_supplicant/examples/wps-nfc.py +++ b/wpa_supplicant/examples/wps-nfc.py @@ -17,7 +17,7 @@ import nfc.handover import wpactrl -wpas_ctrl = '/var/run/wpa_supplicant' +wpas_ctrl = '/run/wpa_supplicant' def wpas_connect(): ifaces = [] diff --git a/wpa_supplicant/wpa_cli.c b/wpa_supplicant/wpa_cli.c index 632db80..dc079d6 100644 --- a/wpa_supplicant/wpa_cli.c +++ b/wpa_supplicant/wpa_cli.c @@ -73,7 +73,7 @@ static int wpa_cli_attached = 0; static int wpa_cli_connected = 0; static int wpa_cli_last_id = 0; #ifndef CONFIG_CTRL_IFACE_DIR -#define CONFIG_CTRL_IFACE_DIR "/var/run/wpa_supplicant" +#define CONFIG_CTRL_IFACE_DIR "/run/wpa_supplicant" #endif /* CONFIG_CTRL_IFACE_DIR */ static const char *ctrl_iface_dir = CONFIG_CTRL_IFACE_DIR; static char *ctrl_ifname = NULL; diff --git a/wpa_supplicant/wpa_gui-qt4/wpagui.cpp b/wpa_supplicant/wpa_gui-qt4/wpagui.cpp index 6bba8d2..049130f 100644 --- a/wpa_supplicant/wpa_gui-qt4/wpagui.cpp +++ b/wpa_supplicant/wpa_gui-qt4/wpagui.cpp @@ -133,7 +133,7 @@ WpaGui::WpaGui(QApplication *_app, QWidget *parent, const char *, Qt::WFlags) ctrl_conn = NULL; monitor_conn = NULL; msgNotifier = NULL; - ctrl_iface_dir = strdup("/var/run/wpa_supplicant"); + ctrl_iface_dir = strdup("/run/wpa_supplicant"); parse_argv(); diff --git a/wpa_supplicant/wpa_priv.c b/wpa_supplicant/wpa_priv.c index ad6a080..cf9a5a8 100644 --- a/wpa_supplicant/wpa_priv.c +++ b/wpa_supplicant/wpa_priv.c @@ -956,7 +956,7 @@ int main(int argc, char *argv[]) int ret = -1; char *pid_file = NULL; int daemonize = 0; - char *ctrl_dir = "/var/run/wpa_priv"; + char *ctrl_dir = "/run/wpa_priv"; struct wpa_priv_interface *interfaces = NULL, *iface; if (os_program_init()) diff --git a/wpa_supplicant/wpa_supplicant.conf b/wpa_supplicant/wpa_supplicant.conf index 18460b8..592b73f 100644 --- a/wpa_supplicant/wpa_supplicant.conf +++ b/wpa_supplicant/wpa_supplicant.conf @@ -38,8 +38,8 @@ # The socket file will be named based on the interface name, so multiple # wpa_supplicant processes can be run at the same time if more than one # interface is used. -# /var/run/wpa_supplicant is the recommended directory for sockets and by -# default, wpa_cli will use it when trying to connect with wpa_supplicant. +# /run/wpa_supplicant is the recommended directory for sockets and by default, +# wpa_cli will use it when trying to connect with wpa_supplicant. # # Access control for the control interface can be configured by setting the # directory to allow only members of a group to use sockets. This way, it is @@ -55,8 +55,8 @@ # value it got by default when the directory or socket was created. # # When configuring both the directory and group, use following format: -# DIR=/var/run/wpa_supplicant GROUP=wheel -# DIR=/var/run/wpa_supplicant GROUP=0 +# DIR=/run/wpa_supplicant GROUP=wheel +# DIR=/run/wpa_supplicant GROUP=0 # (group can be either group name or gid) # # For UDP connections (default on Windows): The value will be ignored. This @@ -72,7 +72,7 @@ # DACL (which will reject all connections). See README-Windows.txt for more # information about SDDL string format. # -ctrl_interface=/var/run/wpa_supplicant +ctrl_interface=/run/wpa_supplicant # IEEE 802.1X/EAPOL version # wpa_supplicant is implemented based on IEEE Std 802.1X-2004 which defines
Follow an FHS proposal[1] that is already implemented on some major distributions. [1] https://bugs.linuxfoundation.org/show_bug.cgi?id=718 Signed-off-by: Jouke Witteveen <j.witteveen@gmail.com> --- wpa_supplicant/ChangeLog | 1 + wpa_supplicant/README | 32 +++++++++++----------- wpa_supplicant/README-P2P | 2 +- wpa_supplicant/README-WPS | 2 +- wpa_supplicant/config.h | 8 +++--- wpa_supplicant/doc/docbook/wpa_priv.sgml | 12 ++++---- .../doc/docbook/wpa_supplicant.conf.sgml | 12 ++++---- wpa_supplicant/examples/ieee8021x.conf | 2 +- wpa_supplicant/examples/plaintext.conf | 2 +- wpa_supplicant/examples/wep.conf | 2 +- wpa_supplicant/examples/wpa-psk-tkip.conf | 2 +- wpa_supplicant/examples/wpa2-eap-ccmp.conf | 2 +- wpa_supplicant/examples/wps-nfc.py | 2 +- wpa_supplicant/wpa_cli.c | 2 +- wpa_supplicant/wpa_gui-qt4/wpagui.cpp | 2 +- wpa_supplicant/wpa_priv.c | 2 +- wpa_supplicant/wpa_supplicant.conf | 10 +++---- 17 files changed, 49 insertions(+), 48 deletions(-)