r and that's it.
Br,
Tomasz
Hi Tomasz,
On Fri, Apr 10, 2015 at 9:17 AM, Tomasz Bursztyka
wrote:
Hi,
As it has been discussed in the systemd hackfest during the Linux
Conference
Europe, one daemon could centralize the management of all network proxy
configurations. Idea is somet
n Fri, Apr 10, 2015 at 9:17 AM, Tomasz Bursztyka
wrote:
Hi,
As it has been discussed in the systemd hackfest during the Linux Conference
Europe, one daemon could centralize the management of all network proxy
configurations. Idea is something user can do per-application (like in
firefox for in
Hi David,
On Fri Apr 10 05:17:37 PDT 2015, Tomasz Bursztyka wrote:
As it has been discussed in the systemd hackfest during the Linux Conference
Europe, one daemon could centralize the management of all network proxy
configurations. Idea is something user can do per-application (like in
Hi David,
On Fri, Apr 10, 2015 at 2:17 PM, Tomasz Bursztyka wrote:
+ - support IPv6
This we should probably have from the beginning, any reason you kept
it IPv4 only for now (apart from keeping it simple as a POC)?
Wow, yeah. This far into the 21st century, you basically have to go out
of
Hi David,
+static int method_find_proxy(sd_bus *bus, sd_bus_message *message,
void *userdata, sd_bus_error *error) {
+_cleanup_free_ char *p = strdup("DIRECT");
+Manager *m = userdata;
+int r;
+
+assert(bus);
+assert(message);
+assert(m);
+
+
Hi,
Have you looked into MuJS instead of duktape? http://mujs.com/
It has a C api similar to Lua, with all state encapsulated in an
opaque structure, that you interface with via a virtual stack.
It could be easily tested. I did so the PAC related code is contained in
a specific
place, sharin
Hi Lennart,
Hmm, is this right? Shouldn't we return the error code to the client
instead of eating up and returning "DIRECT"?
Also, why allocate "DIRECT" with strdup() at all?
There are no errors. Either you get a proxy directive or you return
DIRECT to indicate no proxy. What would you do in
Hi Lennart and Marcel,
I'll stick to the thread solution for now, moving the dbus handling in
the main process.
I forgot to check about this issue.
We could have a timeout in the pac runtime, so it would cancel the
duktape context
relevantly, so no need to track the threads from the main proc
Le 10/04/2015 18:49, Lennart Poettering a écrit :
On Fri, 10.04.15 15:17, Tomasz Bursztyka (tomasz.burszt...@linux.intel.com)
wrote:
+struct PAC {
+duk_context *ctx;
+};
+
+static int get_addresses_from_interface(int ifindex, union in_addr_union
*address) {
+struct ifreq ifr
Hi Tom,
--- a/Makefile.am
+++ b/Makefile.am
@@ -5895,12 +5895,19 @@ rootlibexec_PROGRAMS += \
systemd-proxy-discoveryd
systemd_proxy_discoveryd_SOURCES = \
+ src/proxy-discovery/duktape.h \
+ src/proxy-discovery/duktape.c \
These files are not included in the patch, how
Hi Marcel and Lennart,
The config file will be in /etc/systemd/proxy/.conf
It currently only load "Proxy" parts, with the key PAC. Rest is ignored.
The PAC keyword is a path to a .pac file (a specific js script for proxy
configuration).
Only one PAC based proxy configuration will be loaded at
Hi Zbigniew,
+
+[Service]
+Restart=on-failure
+ExecStart=@rootlibexecdir@/systemd-proxy-discoveryd
+StandardOutput=null
What privileges does this daemon require? I'd guess it can run as normal
user at least... Since this is supposed to be executing untrusted javascript
code, let's lock it down
Hi Lennart,
+
+[Unit]
+Description=Proxy service
+DefaultDependencies=no
Hmm, should this really be an early-boot service? Can you explain?
That's a mistake indeed.
+Requires=dbus.socket
+After=dbus.socket
+Before=remote-fs.target
Which this dependency?
Took that quickly from pacrunner.s
Hi Tom,
+int manager_new(Manager **ret);
+Manager *manager_free(Manager *m);
+
+DEFINE_TRIVIAL_CLEANUP_FUNC(Manager*, manager_free);
+#define _cleanup_manager_free_ _cleanup_(manager_freep)
We generally try to avoid this define in internal code, and just use
_cleanup_(manager_freep) inline.
O
14 matches
Mail list logo
