[openFATE 305914] PAC support for 'system wide proxy configuration'
Feature added by: Dominique Leuenberger (dimstar) Feature #305914, revision 1, last change by Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enugh to have the advantage of no longer needing to 'guess' what proxy to use. What is now: - You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234) This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: - Use System Proxy (as configured in yast) - Use proxy configuration (static, same options as in yast) - Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Dominique Leuenberger (dimstar) Feature #305914, revision 3 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as - much use of it as possible. A big advantage is the ability to parse PAC - (Proxy AutoConfiguration) without the need for this in every - application. Simply linking against libproxy with it's very simple API - (3 API calls, 2 without parameters) is enugh to have the advantage of - no longer needing to 'guess' what proxy to use. What is now: - You can - set in yast / proxy a general proxy to be used - (http://foo.proxy.com:1234) This is bascially put into http_proxy - envvar. In gnome you can set user proxy configuration as: - Use System - Proxy (as configured in yast) - Use proxy configuration (static, same - options as in yast) - Use automatic proxy configuration script Yast - lacks the option to specify a PAC script on system wide level. This is - only possible in the user sessions configuration. This made sense as - most applications don't know how to handle pac files anyway. But with - libroxy, this hurdle can be taken away from every single application - and can thus be offered. I'm glad to elaborate on questions; I'm sure - there are some :-) + much use of it as possible. + A big advantage is the ability to parse PAC (Proxy AutoConfiguration) + without the need for this to be implemented in every application. + Simply linking against libproxy with it's very simple API (3 API calls, + 2 without parameters) is enough to have the advantage of no longer + needing to 'guess' what proxy to use. + Current situation: + * You can set in yast / proxy a general proxy to be used + (http://foo.proxy.com:1234). This is bascially put into http_proxy + envvar. + In gnome you can set user proxy configuration as: + * Use System Proxy (as configured in yast) + * Use proxy configuration (static, same options as in yast) + * Use automatic proxy configuration script + Yast lacks the option to specify a PAC script on system wide level. + This is only possible in the user sessions configuration. This made + sense as most applications don't know how to handle pac files anyway. + But with libroxy, this hurdle can be taken away from every single + application and can thus be offered. I'm glad to elaborate on + questions; I'm sure there are some :-) -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Michael Löffler (michl19) Feature #305914, revision 5 Title: PAC support for 'system wide proxy configuration' - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Jiri Srain (jsrain) Feature #305914, revision 7 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important + Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) + Discussion: + #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) + Dominique, I don't really understand what's needed on the YaST side + (probably mostly because of the lack of my knowledge), could you, + please, provide more informaiton on what you want to achieve (from the + YaST point of view)? Is it just writing proxy information to another + configuraiton file for libproxy? -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Dominique Leuenberger (dimstar) Feature #305914, revision 8 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? + #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to + #1) + That might be one case, but not even needed, as libproxy reads the + configurations from gnome/kde settings for example (current running + env). + yast wouuld need the enhancement to allow to also set proxy + autoconfiguration as source for proxy (at this time, you can only 'hard + code' some proxy, http, https, ftp and socks. It's not possible to + define wpad and pac. + Besides that, the 'underlying' tools, like wget, aria and the like, + spawned by yast and that connect to the net, will need libproxy + support. (for aria2c there is a enhancement request open already). -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Jiri Srain (jsrain) Feature #305914, revision 10 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). + #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) + OK, I understand what is needed for the underlying tools, but still + don't get YaST. YaST Proxy module only sets the settings into sysconfig + (just another storage for proxy information), it is task for the + applications to either get proxy info from these variables or via + libproxy, no matter how it gets it. -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Dominique Leuenberger (dimstar) Feature #305914, revision 11 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. + #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to + #3) + so far correct, but let's have a look at the mask Yast2 / Proxy: + The settings available are: + > [ ] Enable Proxy + > HTTP Proxy URL + > HTTPS Proxy URL + > FTP Proxy URL + > [ ] Use the Same Proxy for All Protocols + > No Proxy Domains + > Proxy Authentication Username / Password + + It is not possible in the current mask to define a PAC URL for the + Proxy settings.(or WPAD:// for what it matters) + I hope this helps. Otherwise we can maybe discuss the matter on IRC? -- openSUSE Feature: https://features.opensuse.org/305914
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password
Feature changed by: Jiri Srain (jsrain) Feature #305914, revision 12 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are: - It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC? + #5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) + I understand, the question is: What shall YaST do with this + information? Write it to sysconfig where almost nobody reads it? -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Dominique Leuenberger (dimstar) Feature #305914, revision 13 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? + #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to + #5) + It should be written to sysconfig and with the same logic appear in envvar + as normal. + The envvar for PAC scripts is formatted in this way: + http_proxy="pac+http://my.webserver.com/proxy.pac" + Optionally, it might not be wrong to also write it to the libproxy + configuration file. But this is optional and might be to much + 'enforced' as opposed to the envvar. -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Christoph Thiel (cthiel1) Feature #305914, revision 14 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. + #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) + Novell currently doesn't have the resources to implement something like + this for openSUSE 11.2. -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Stephan Kulow (coolo) Feature #305914, revision 15 Title: PAC support for 'system wide proxy configuration' - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-08-12 11:23:55 + reject reason: no volunteer to work on it and only 1 vote (I guess the + requester :) Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) Novell currently doesn't have the resources to implement something like this for openSUSE 11.2. -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Manuel Ramirez (elpreto) Feature #305914, revision 16 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:23:55 reject reason: no volunteer to work on it and only 1 vote (I guess the requester :) Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) Novell currently doesn't have the resources to implement something like this for openSUSE 11.2. + #8: Manuel Ramirez (elpreto) (2009-08-28 04:53:36) + Oh, this is really important, a lot of entrerprises use that proxy + authentication mode, i have the same problem in my work, this feature + is really important to adopt openSUSE in enterprises. Suse Enterprise + Desktop have this option?? -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Dominique Leuenberger (dimstar) Feature #305914, revision 17 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:23:55 reject reason: no volunteer to work on it and only 1 vote (I guess the requester :) Priority Requester: Important Projectmanager: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) Novell currently doesn't have the resources to implement something like this for openSUSE 11.2. #8: Manuel Ramirez (elpreto) (2009-08-28 04:53:36) Oh, this is really important, a lot of entrerprises use that proxy authentication mode, i have the same problem in my work, this feature is really important to adopt openSUSE in enterprises. Suse Enterprise Desktop have this option?? + #9: Dominique Leuenberger (dimstar) (2009-08-28 15:45:56) (reply to + #8) + Nothing like this to my knowledge yet. The best choice you have at the moment + is setting the proxy properly in GNOME to use the pac script. But + having gnome on 'system proxy' and having system proxy set + appropriately would be cleaner solution. + + FWIW: wget should get libproxy support soon. -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Dominique Leuenberger (dimstar) Feature #305914, revision 18 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:23:55 reject reason: no volunteer to work on it and only 1 vote (I guess the requester :) Priority Requester: Important Projectmanager: Important + openSUSE-11.4: Unconfirmed + Priority + Requester: Desirable Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) Novell currently doesn't have the resources to implement something like this for openSUSE 11.2. #8: Manuel Ramirez (elpreto) (2009-08-28 04:53:36) Oh, this is really important, a lot of entrerprises use that proxy authentication mode, i have the same problem in my work, this feature is really important to adopt openSUSE in enterprises. Suse Enterprise Desktop have this option?? #9: Dominique Leuenberger (dimstar) (2009-08-28 15:45:56) (reply to #8) Nothing like this to my knowledge yet. The best choice you have at the moment is setting the proxy properly in GNOME to use the pac script. But having gnome on 'system proxy' and having system proxy set appropriately would be cleaner solution. FWIW: wget should get libproxy support soon. -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Lukas Ocilka (locilka) Feature #305914, revision 19 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:23:55 reject reason: no volunteer to work on it and only 1 vote (I guess the requester :) Priority Requester: Important Projectmanager: Important openSUSE-11.4: Unconfirmed Priority Requester: Desirable Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) - Project Manager: Christoph Thiel (cthiel1) Partner organization: openSUSE.org Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) Novell currently doesn't have the resources to implement something like this for openSUSE 11.2. #8: Manuel Ramirez (elpreto) (2009-08-28 04:53:36) Oh, this is really important, a lot of entrerprises use that proxy authentication mode, i have the same problem in my work, this feature is really important to adopt openSUSE in enterprises. Suse Enterprise Desktop have this option?? #9: Dominique Leuenberger (dimstar) (2009-08-28 15:45:56) (reply to #8) Nothing like this to my knowledge yet. The best choice you have at the moment is setting the proxy properly in GNOME to use the pac script. But having gnome on 'system proxy' and having system proxy set appropriately would be cleaner solution. - FWIW: wget should get libproxy support soon. -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Raul Gomez (NachoGomez) Feature #305914, revision 20 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:23:55 reject reason: no volunteer to work on it and only 1 vote (I guess the requester :) Priority Requester: Important Projectmanager: Important openSUSE-11.4: Unconfirmed Priority Requester: Desirable Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Partner organization: openSUSE.org Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) Novell currently doesn't have the resources to implement something like this for openSUSE 11.2. #8: Manuel Ramirez (elpreto) (2009-08-28 04:53:36) Oh, this is really important, a lot of entrerprises use that proxy authentication mode, i have the same problem in my work, this feature is really important to adopt openSUSE in enterprises. Suse Enterprise Desktop have this option?? #9: Dominique Leuenberger (dimstar) (2009-08-28 15:45:56) (reply to #8) Nothing like this to my knowledge yet. The best choice you have at the moment is setting the proxy properly in GNOME to use the pac script. But having gnome on 'system proxy' and having system proxy set appropriately would be cleaner solution. FWIW: wget should get libproxy support soon. + #10: Raul Gomez (nachogomez) (2015-12-05 00:17:15) + Well, it's been a while since the last post of this thread, but I think + is really important for Yast to support PAC/WPAD authentication, it has + been enforced yesterday here in my office (big corporation) and now I'm + prevented to install/update packages using Yast + I've seen the options in KDE5 (I'm using openSUSE Leap 42.1), but it + doesn't seem to work for Yast -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Raul Gomez (NachoGomez) Feature #305914, revision 21 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:23:55 reject reason: no volunteer to work on it and only 1 vote (I guess the requester :) Priority Requester: Important Projectmanager: Important openSUSE-11.4: Unconfirmed Priority Requester: Desirable + openSUSE Distribution: Unconfirmed + Priority + Requester: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Partner organization: openSUSE.org Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) Novell currently doesn't have the resources to implement something like this for openSUSE 11.2. #8: Manuel Ramirez (elpreto) (2009-08-28 04:53:36) Oh, this is really important, a lot of entrerprises use that proxy authentication mode, i have the same problem in my work, this feature is really important to adopt openSUSE in enterprises. Suse Enterprise Desktop have this option?? #9: Dominique Leuenberger (dimstar) (2009-08-28 15:45:56) (reply to #8) Nothing like this to my knowledge yet. The best choice you have at the moment is setting the proxy properly in GNOME to use the pac script. But having gnome on 'system proxy' and having system proxy set appropriately would be cleaner solution. FWIW: wget should get libproxy support soon. #10: Raul Gomez (nachogomez) (2015-12-05 00:17:15) Well, it's been a while since the last post of this thread, but I think is really important for Yast to support PAC/WPAD authentication, it has been enforced yesterday here in my office (big corporation) and now I'm prevented to install/update packages using Yast I've seen the options in KDE5 (I'm using openSUSE Leap 42.1), but it doesn't seem to work for Yast -- openSUSE Feature: https://features.opensuse.org/305914
Feature changed by: Raul Gomez (NachoGomez) Feature #305914, revision 22 Title: PAC support for 'system wide proxy configuration' openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 11:23:55 reject reason: no volunteer to work on it and only 1 vote (I guess the requester :) Priority Requester: Important Projectmanager: Important openSUSE-11.4: Unconfirmed Priority Requester: Desirable openSUSE Distribution: Unconfirmed Priority Requester: Important Info Provider: Dominique Leuenberger (dimstar) Requested by: Dominique Leuenberger (dimstar) Partner organization: openSUSE.org Description: The distribution now contains libproxy and we should try to make as much use of it as possible. A big advantage is the ability to parse PAC (Proxy AutoConfiguration) without the need for this to be implemented in every application. Simply linking against libproxy with it's very simple API (3 API calls, 2 without parameters) is enough to have the advantage of no longer needing to 'guess' what proxy to use. Current situation: * You can set in yast / proxy a general proxy to be used (http://foo.proxy.com:1234). This is bascially put into http_proxy envvar. In gnome you can set user proxy configuration as: * Use System Proxy (as configured in yast) * Use proxy configuration (static, same options as in yast) * Use automatic proxy configuration script Yast lacks the option to specify a PAC script on system wide level. This is only possible in the user sessions configuration. This made sense as most applications don't know how to handle pac files anyway. But with libroxy, this hurdle can be taken away from every single application and can thus be offered. I'm glad to elaborate on questions; I'm sure there are some :-) Discussion: #1: Jiri Srain (jsrain) (2009-06-02 10:19:21) Dominique, I don't really understand what's needed on the YaST side (probably mostly because of the lack of my knowledge), could you, please, provide more informaiton on what you want to achieve (from the YaST point of view)? Is it just writing proxy information to another configuraiton file for libproxy? #2: Dominique Leuenberger (dimstar) (2009-06-02 10:24:34) (reply to #1) That might be one case, but not even needed, as libproxy reads the configurations from gnome/kde settings for example (current running env). yast wouuld need the enhancement to allow to also set proxy autoconfiguration as source for proxy (at this time, you can only 'hard code' some proxy, http, https, ftp and socks. It's not possible to define wpad and pac. Besides that, the 'underlying' tools, like wget, aria and the like, spawned by yast and that connect to the net, will need libproxy support. (for aria2c there is a enhancement request open already). #3: Jiri Srain (jsrain) (2009-06-23 09:09:43) (reply to #2) OK, I understand what is needed for the underlying tools, but still don't get YaST. YaST Proxy module only sets the settings into sysconfig (just another storage for proxy information), it is task for the applications to either get proxy info from these variables or via libproxy, no matter how it gets it. #4: Dominique Leuenberger (dimstar) (2009-06-23 10:05:14) (reply to #3) so far correct, but let's have a look at the mask Yast2 / Proxy: The settings available are:
[ ] Enable Proxy HTTP Proxy URL HTTPS Proxy URL FTP Proxy URL [ ] Use the Same Proxy for All Protocols No Proxy Domains Proxy Authentication Username / Password It is not possible in the current mask to define a PAC URL for the Proxy settings.(or WPAD:// for what it matters) I hope this helps. Otherwise we can maybe discuss the matter on IRC?
#5: Jiri Srain (jsrain) (2009-06-23 10:13:21) (reply to #4) I understand, the question is: What shall YaST do with this information? Write it to sysconfig where almost nobody reads it? #6: Dominique Leuenberger (dimstar) (2009-06-23 10:21:18) (reply to #5) It should be written to sysconfig and with the same logic appear in envvar as normal. The envvar for PAC scripts is formatted in this way: http_proxy="pac+http://my.webserver.com/proxy.pac" Optionally, it might not be wrong to also write it to the libproxy configuration file. But this is optional and might be to much 'enforced' as opposed to the envvar. #7: Christoph Thiel (cthiel1) (2009-07-16 11:44:07) Novell currently doesn't have the resources to implement something like this for openSUSE 11.2. #8: Manuel Ramirez (elpreto) (2009-08-28 04:53:36) Oh, this is really important, a lot of entrerprises use that proxy authentication mode, i have the same problem in my work, this feature is really important to adopt openSUSE in enterprises. Suse Enterprise Desktop have this option?? #9: Dominique Leuenberger (dimstar) (2009-08-28 15:45:56) (reply to #8) Nothing like this to my knowledge yet. The best choice you have at the moment is setting the proxy properly in GNOME to use the pac script. But having gnome on 'system proxy' and having system proxy set appropriately would be cleaner solution. FWIW: wget should get libproxy support soon. #10: Raul Gomez (nachogomez) (2015-12-05 00:17:15) Well, it's been a while since the last post of this thread, but I think is really important for Yast to support PAC/WPAD authentication, it has been enforced yesterday here in my office (big corporation) and now I'm prevented to install/update packages using Yast I've seen the options in KDE5 (I'm using openSUSE Leap 42.1), but it doesn't seem to work for Yast + #11: Raul Gomez (nachogomez) (2015-12-05 05:48:09) + Actually, I volunteer for adding this functionality, given someone + experienced can guide me through it. I'm a skilled Python programmer, + and I think this is a great opportunity to learn Ruby! + Cheers! -- openSUSE Feature: https://features.opensuse.org/305914
participants (1)
-
fate_noreply＠suse.de