[{"id":1761093,"web_url":"http://patchwork.ozlabs.org/comment/1761093/","msgid":"","list_archive_url":null,"date":"2017-08-31T15:01:12","subject":"Re: [swupdate] Make socket paths and TMPDIR configurable?","submitter":{"id":5771,"url":"http://patchwork.ozlabs.org/api/people/5771/","name":"Stefano Babic","email":"sbabic@denx.de"},"content":"Hi Christian,\n\nOn 31/08/2017 16:07, Christian Storm wrote:\n> Hi,\n> \n> I'd like to see the various socket locations be configurable so that I\n> can put them into different directories and, e.g., give progress clients\n> access to the progress IPC socket only but not to, say, the control IPC\n> socket, including the ability to \"see\" the control socket at all.\n> Currently, they're all residing in /tmp/, hard-coded.\nRight, they are hard-coded.\n\n> \n> As a quick hack, consider something along the lines of the following:\n> ```\n> --- a/Kconfig\n> +++ b/Kconfig\n> @@ -110,6 +110,25 @@ config SW_VERSIONS_FILE\n> \t but in some cases it can be required to do it. Having a check,\n> \t the risky-component is not always updated.\n> \n> +config SOCKET_CTRL_PATH\n> +\tstring \"SWUpdate control socket path\"\n> +\tdefault \"/tmp/sockinstctrl\"\n> +\thelp\n> +\t Path to SWUpdate's IPC socket.\n> +\n> +config SOCKET_PROGRESS_PATH\n> +\tstring \"SWUpdate progress socket path\"\n> +\tdefault \"/tmp/swupdateprog\"\n> +\thelp\n> +\t Path to the socket progress information is sent to.\n> +\n\nThe thing is how to export this for the clients. We have an API, that is\nthe install interface (sockinstctrl) and progress. Both can be used by\nexternal programs to drive SWUpdate. We can set that the client\ninterface \"must\" be linked to own software, but it remains a strange\nsituation. We still should guarantee that software built outside\nSWUpdate works.\n\n\n> +config SOCKET_REMOTE_HANDLER_DIRECTORY\n> +\tstring \"SWUpdate remote handler socket directory\"\n> +\tdefault \"/tmp/\"\n> +\thelp\n> +\t Directory where sockets to remote handler processes\n> +\t are expected to be found.\n> +\n> \n> --- a/handlers/remote_handler.c\n> +++ b/handlers/remote_handler.c\n> @@ -167,7 +167,7 @@ static int install_remote_image(struct img_type *img,\n> \tstruct RHmsg RHmessage;\n> \tchar bufcmd[80];\n> \n> -\tlen = strlen(img->type_data) + strlen(TMPDIR) + strlen(\"ipc://\") + 4;\n> +\tlen = strlen(img->type_data) + strlen(CONFIG_SOCKET_REMOTE_HANDLER_DIRECTORY) + strlen(\"ipc://\") + 4;\n\nThis is more difficult because this interface allows to bind an external\nhandler, maybe under a closed license.\n\n> \n> \t/*\n> \t * Allocate maximum string\n> @@ -177,7 +177,7 @@ static int install_remote_image(struct img_type *img,\n> \t\tERROR(\"Not enough memory\");\n> \t\treturn -ENOMEM;\n> \t}\n> -\tsnprintf(connect_string, len, \"ipc://%s%s\", TMPDIR,\n> +\tsnprintf(connect_string, len, \"ipc://%s%s\", CONFIG_SOCKET_REMOTE_HANDLER_DIRECTORY,\n> \t\t\timg->type_data);\n> \n> \tret = zmq_connect(request, connect_string);\n> \n> \n> --- a/include/network_ipc.h\n> +++ b/include/network_ipc.h\n> @@ -24,7 +24,7 @@\n> #include \"swupdate_status.h\"\n> \n> #define IPC_MAGIC\t\t0x14052001\n> -#define SOCKET_CTRL_PATH\t\"/tmp/sockinstctrl\"\n> +#define SOCKET_CTRL_PATH\tCONFIG_SOCKET_CTRL_PATH\n> \n> typedef enum {\n> \tREQ_INSTALL,\n> \n> \n> --- a/include/progress.h\n> +++ b/include/progress.h\n> @@ -24,7 +24,7 @@\n> \n> #include \n> \n> -#define SOCKET_PROGRESS_PATH \"/tmp/swupdateprog\"\n> +#define SOCKET_PROGRESS_PATH CONFIG_SOCKET_PROGRESS_PATH\n> \n> /*\n> * Message sent via socket\n> ```\n> \n> This, however, breaks progress clients if they're compiled out-of-tree\n> without a proper include/generated/autoconf.h defining, e.g.,\n\nRight, but it is bad to export autoconf.h. We should find another way.\n\n> CONFIG_SOCKET_CTRL_PATH. Hence, progress clients should get a command\n> line parameter -s /path/to/socket specifying the path to the progress\n> IPC socket (and a \"sane\" default as fallback which is the current\n> hard-coded location in /tmp). The same is true for the other sockets.\n> \n> \n> Carrying things further, TMPDIR as defined in include/util.h:115 and\n> used in various locations may also be split according to the concern at\n> hand so that not all temporary files regardless of their concern reside\n> in /tmp.\n\nok\n\n> \n> \n> What do you think about this?\n\nPossible, but I do not know how to guarantee API consistency.\n\nAnother way is to put the sockets inside the configuration file instead\nof defining it via CONFIG_. They are not anymore hard-coded.\n\nThis can be read from the client, too - but clients should also link\nlibconfig to parse it.\n\n> \n> \n> As a side note, what do you think about including systemd's socket-based\n> activation as an optional feature? Then, if a process wants to talk to\n> the control IPC socket created by systemd, systemd spawns SWUpdate and\n> hands over the socket to SWUpdate...\n\nI do not know if currently work. SWUpdate is monitoring the processes\nlistening to interfaces, and that means it is the spawner. Then, for\nsystemd I understand that these processes will run independently from\nSWUpdate \"core\", and then it does not monitor them anymore. It works\njust with external processes with client library. Or can you better\ndetail this proposal ?\n\nRegards,\nStefano","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=googlegroups.com\n\t(client-ip=2a00:1450:400c:c0c::239;\n\thelo=mail-wr0-x239.google.com;\n\tenvelope-from=swupdate+bncbaabbqojudgqkgqeucpsojq@googlegroups.com;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=googlegroups.com header.i=@googlegroups.com\n\theader.b=\"DIgrYRU+\"; dkim-atps=neutral"],"Received":["from mail-wr0-x239.google.com (mail-wr0-x239.google.com\n\t[IPv6:2a00:1450:400c:c0c::239])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjlv937QGz9s7M\n\tfor ;\n\tFri, 1 Sep 2017 01:01:24 +1000 (AEST)","by mail-wr0-x239.google.com with SMTP id y7sf270768wry.0\n\tfor ;\n\tThu, 31 Aug 2017 08:01:24 -0700 (PDT)","by 10.28.152.85 with SMTP id a82ls1380898wme.11.canary-gmail; Thu,\n\t31 Aug 2017 08:01:21 -0700 (PDT)","from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.9])\n\tby gmr-mx.google.com with ESMTPS id\n\tc83si12894wmd.6.2017.08.31.08.01.20 for \n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 31 Aug 2017 08:01:20 -0700 (PDT)","from frontend01.mail.m-online.net (unknown [192.168.8.182])\n\tby mail-out.m-online.net (Postfix) with ESMTP id 3xjlv45bdyz1rNbj;\n\tThu, 31 Aug 2017 17:01:20 +0200 (CEST)","from localhost (dynscan1.mnet-online.de [192.168.6.70])\n\tby mail.m-online.net (Postfix) with ESMTP id 3xjlv45GcXz3hhTB;\n\tThu, 31 Aug 2017 17:01:20 +0200 (CEST)","from mail.mnet-online.de ([192.168.8.182])\n\tby localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id UPfSsGFXhqJE; Thu, 31 Aug 2017 17:01:19 +0200 (CEST)","from babic.homelinux.org\n\t(host-88-217-136-221.customer.m-online.net [88.217.136.221])\n\t(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mail.mnet-online.de (Postfix) with ESMTPS;\n\tThu, 31 Aug 2017 17:01:19 +0200 (CEST)","from localhost (mail.babic.homelinux.org [127.0.0.1])\n\tby babic.homelinux.org (Postfix) with ESMTP id 1C1044540507;\n\tThu, 31 Aug 2017 17:01:19 +0200 (CEST)","from babic.homelinux.org ([127.0.0.1])\n\tby localhost (mail.babic.homelinux.org [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id Xpk4c16g3RMO; Thu, 31 Aug 2017 17:01:12 +0200 (CEST)","from [192.168.178.132] (papero.fritz.box [192.168.178.132])\n\tby babic.homelinux.org (Postfix) with ESMTP id 835014540443;\n\tThu, 31 Aug 2017 17:01:12 +0200 (CEST)"],"ARC-Seal":["i=2; a=rsa-sha256; t=1504191681; cv=pass;\n\td=google.com; s=arc-20160816;\n\tb=scsLwk/mgt0ruRReri2CTYaqKndX6iYj1jYz7tX0589PwVIqemyvAukChnpQRTIKag\n\t4ATl1PT7FRRer5+KrW7iIGhHmThSZfOVqYA8rxMRLoFsZBC0eW0Ya/bE9GWar4hWrxnn\n\ti47/dImz0wxfVqK/g3IpiqT1tY7WX+UY4iozrzVuUpVG8Y4T6WrWkllj/tUlqJg6A+2L\n\tGWnpgQOtaq+IR3QJSc7swPAtxnyijZLKQbPFW06SSi85sPiFjHB9VWYWAZnM2z7WuXj1\n\tpIyVqTKjKYi4IlT8bX2itVEoVP1/3MeVndFtHlIdpi2BoccZ8SRXzAJSxArL7P67Vj+Z\n\tLgQw==","i=1; a=rsa-sha256; t=1504191680; cv=none;\n\td=google.com; s=arc-20160816;\n\tb=kOQedUhp97XfHz2+daPNWRlC1p/Ju7Aq7cTV24PUH+fMhhIftkQuSOAvO/6JWEwAz+\n\tlajZmKp9VySinnpQAlQ4LofMJj5SntFYDWSdcqjmQi+ojWKpo2Srgnnaw1d2iLzwnCcd\n\twy3mpO+FNXnOJlgpJEic+CTRk7rRcbECYuslnPeM3Mt8EznxykSv42hADlgdH6zuK5au\n\tvoC8X9YxK8JIh2wLyFSXqRFWZ8Akg3vvrkZNwMG3j5gabsMXXvWwYrKe+Km3K3gVKYEI\n\tx06kTEwpAHXutugv+O3yd2eCywZFpt7vj+sGwHgE0tO90hyren3HDcbU+4Dt5MZs8XPL\n\tBKTg=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=arc-20160816; \n\th=list-unsubscribe:list-subscribe:list-archive:list-help:list-post\n\t:list-id:mailing-list:precedence:content-language:in-reply-to\n\t:mime-version:user-agent:date:message-id:from:cc:references:to\n\t:subject:arc-authentication-results:arc-message-signature:sender\n\t:dkim-signature:arc-authentication-results;\n\tbh=DyYlbLOd/xV44/+ZEAgZ54/uTymDSrbQrkP/HrOdcL8=;\n\tb=0pW4UZIULO296cWiMyKTlNqtUFPOwNs/krazFblVx9nl6C5w9jpFFZzIKvmV7XL6kd\n\t66akYzR4KctOYdf+5Dal66jI4fEPVepb6EIg6SU67axq8/ionlEW88t52HYfqk16O9Oj\n\tr2Tz8wuSR513mEO5OVxWuWp0AORPYNjCFzlRRgPmLGXI9+S503+lAzttciSIyPAaxTwM\n\tm8idjZsxQKRguUAeDoHiJf3IFNkGSjkXuDdpReQn471JKEpaSjjdlzLBEM0JuyXAN8kf\n\tvD5dZbn/L1Uc6ZL1BcBH4DFKCIp6v7r9GoPB5JLl9lhulEoTPMyOxAKNfkBCXdSaOyUH\n\tsy6A==","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=arc-20160816; \n\th=content-transfer-encoding:content-language:in-reply-to:mime-version\n\t:user-agent:date:message-id:from:cc:references:to:subject\n\t:arc-authentication-results;\n\tbh=gUimeD0PXdSjgypT7wx3peZzr6cuQ7vdduZMDw1SYWI=;\n\tb=ppJA7MZEVPCRoPrYrXyAcbf/E1fbXGSGW/87xLxCUK6q02DkEPpiyzF1YLVotTlaXv\n\tTFcXUgLPW/j3E1AmCSfeCGbfXBhF4Kr5azynJq5I++2sA09dF8f+F6Q9a5LOYo1Ud4L6\n\tRAMthbAEuX4amva0hYXE6tC/hS0U//vzPkRBW1sUXpx9vgIeOJE6lR2vocMoVdeueIFc\n\t8CwRsptSSL241Y+tgrVdrwsXzDZxAmWPcQn1YcuoiH36R68ZxTkpHJyL7tW8Qar8m5OC\n\t1R57XKIEgIG7MTPQOXxx3Lzy3JOjd51HbHOp9sOeFJCHDNLBL7WpGIHz0LcSp5FJVhNV\n\tW0wg=="],"ARC-Authentication-Results":["i=2; gmr-mx.google.com;\n\tspf=neutral (google.com: 212.18.0.9 is neither permitted nor denied\n\tby best guess record for domain of sbabic@denx.de)\n\tsmtp.mailfrom=sbabic@denx.de","i=1; gmr-mx.google.com;\n\tspf=neutral (google.com: 212.18.0.9 is neither permitted nor denied\n\tby best guess record for domain of sbabic@denx.de)\n\tsmtp.mailfrom=sbabic@denx.de"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=googlegroups.com; s=20161025;\n\th=sender:subject:to:references:cc:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:x-original-sender\n\t:x-original-authentication-results:precedence:mailing-list:list-id\n\t:list-post:list-help:list-archive:list-subscribe:list-unsubscribe;\n\tbh=DyYlbLOd/xV44/+ZEAgZ54/uTymDSrbQrkP/HrOdcL8=;\n\tb=DIgrYRU+dAUDCylmzE14TlVeaM9OoMnCpFFRHh87C00b0nfdIxD67aFYTNRm988aR2\n\tkI+RDAtANjrcNfRwyezi4/KqApEBQ5ajqOZt7F9FZE7c9O7MSDslljWU4Vp/csnHSJ5l\n\tYqPA+VOIAppESi0XLjGDodVFoMX5d/jQWJFCKejozjfPtW/RU4oxm0HmaETChmObpXFp\n\taSsA1//hYPcr1XTmGq6VYJ9kABfM78lIJsxXdOsj8CMRqoh0Q3mTPAWyZ3wW394uceXo\n\tw2Hz3eLsg7D+WRSdKIjc6tmQjKWeGXoRmjU4OWjq/MHXULgodC8a3zdBozZJXA0Epo6k\n\tOL3Q==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=sender:x-gm-message-state:subject:to:references:cc:from:message-id\n\t:date:user-agent:mime-version:in-reply-to:content-language\n\t:x-original-sender:x-original-authentication-results:precedence\n\t:mailing-list:list-id:x-spam-checked-in-group:list-post:list-help\n\t:list-archive:list-subscribe:list-unsubscribe;\n\tbh=DyYlbLOd/xV44/+ZEAgZ54/uTymDSrbQrkP/HrOdcL8=;\n\tb=WJXbHlAKSVkiA8c1IBdDYL9iaMYXqQoAq+mSFd5CUsBxW9AOwvjW29wOmBoZC9+i5R\n\tHxzKVJHu+ij7xZj83HypJAGMyrGOlE+WthNQfy99HejFi8YHj52Wn8d9o0dYW1GsdrfL\n\tQpofEwTAqJhpgkej9fxV99+OJS/8DzgJEdK5n6G3NfYY/G4lNfgQ+EfSnE+b+m5Ob7LG\n\t/6/NXtirEuSjKOZj+pMqJDh+W0YnQ0OmhfXMdm9wf2lz0YGbotZMEjraBKXmE/qlmeeb\n\tEJK1zYI/QVuRdzdZjB+SoIXX/NJ2ILRQI4REe2ZornutLRr9FPflx3Z8ot1Dp8aTGf/x\n\t25DA==","Sender":"swupdate@googlegroups.com","X-Gm-Message-State":"AHYfb5jnTnazqrJYaYigx2KYZNH+8aEhqoFVV4eTLfrKG+KL0uIEFpZK\n\tVyZfXeG+3liCKA==","X-Google-Smtp-Source":"ADKCNb5j98wS00xIEBNW+t4F1ZE5h/HTaym/1JSxFgQvPQogfkWH4atsYSvG1IbczL7hx/OeNmUCVA==","X-Received":["by 10.28.7.194 with SMTP id 185mr9212wmh.13.1504191681462;\n\tThu, 31 Aug 2017 08:01:21 -0700 (PDT)","by 10.223.198.72 with SMTP id u8mr352810wrg.14.1504191681026;\n\tThu, 31 Aug 2017 08:01:21 -0700 (PDT)"],"X-BeenThere":"swupdate@googlegroups.com","Received-SPF":"neutral (google.com: 212.18.0.9 is neither permitted nor\n\tdenied by best guess record for domain of sbabic@denx.de)\n\tclient-ip=212.18.0.9; ","X-Virus-Scanned":["amavisd-new at mnet-online.de","Debian amavisd-new at babic.homelinux.org"],"Subject":"Re: [swupdate] Make socket paths and TMPDIR configurable?","To":"swupdate@googlegroups.com","References":"<20170831140759.436kek42e27kqebj@MD1KR9XC.ww002.siemens.net>","Cc":"Christian Storm ","From":"Stefano Babic ","Message-ID":"","Date":"Thu, 31 Aug 2017 17:01:12 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170831140759.436kek42e27kqebj@MD1KR9XC.ww002.siemens.net>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Language":"en-US","X-Original-Sender":"sbabic@denx.de","X-Original-Authentication-Results":"gmr-mx.google.com; spf=neutral\n\t(google.com: 212.18.0.9 is neither permitted nor denied by best guess\n\trecord\n\tfor domain of sbabic@denx.de) smtp.mailfrom=sbabic@denx.de","Precedence":"list","Mailing-list":"list swupdate@googlegroups.com;\n\tcontact swupdate+owners@googlegroups.com","List-ID":"","X-Spam-Checked-In-Group":"swupdate@googlegroups.com","X-Google-Group-Id":"605343134186","List-Post":",\n\t","List-Help":",\n\t","List-Archive":",\n\t","List-Unsubscribe":",\n\t"}},{"id":1761529,"web_url":"http://patchwork.ozlabs.org/comment/1761529/","msgid":"<20170901090416.33j65fu3slzzg2ke@MD1KR9XC.ww002.siemens.net>","list_archive_url":null,"date":"2017-09-01T09:04:16","subject":"Re: [swupdate] Make socket paths and TMPDIR configurable?","submitter":{"id":72180,"url":"http://patchwork.ozlabs.org/api/people/72180/","name":"Storm, Christian","email":"christian.storm@siemens.com"},"content":"Hi Stefano,\n\n> > I'd like to see the various socket locations be configurable so that I\n> > can put them into different directories and, e.g., give progress clients\n> > access to the progress IPC socket only but not to, say, the control IPC\n> > socket, including the ability to \"see\" the control socket at all.\n> > Currently, they're all residing in /tmp/, hard-coded.\n> Right, they are hard-coded.\n> \n> > \n> > As a quick hack, consider something along the lines of the following:\n> > ```\n> > --- a/Kconfig\n> > +++ b/Kconfig\n> > @@ -110,6 +110,25 @@ config SW_VERSIONS_FILE\n> > \t but in some cases it can be required to do it. Having a check,\n> > \t the risky-component is not always updated.\n> > \n> > +config SOCKET_CTRL_PATH\n> > +\tstring \"SWUpdate control socket path\"\n> > +\tdefault \"/tmp/sockinstctrl\"\n> > +\thelp\n> > +\t Path to SWUpdate's IPC socket.\n> > +\n> > +config SOCKET_PROGRESS_PATH\n> > +\tstring \"SWUpdate progress socket path\"\n> > +\tdefault \"/tmp/swupdateprog\"\n> > +\thelp\n> > +\t Path to the socket progress information is sent to.\n> > +\n> \n> The thing is how to export this for the clients. We have an API, that is\n> the install interface (sockinstctrl) and progress. Both can be used by\n> external programs to drive SWUpdate. We can set that the client\n> interface \"must\" be linked to own software, but it remains a strange\n> situation. We still should guarantee that software built outside\n> SWUpdate works.\n\nYes, I absolutely agree. It boils down to whether the *location* of the\nsocket is considered as part of the API or not.\nIf the answer is yes, then we shouldn't do it :)\nIf the answer is no or don't care, then we may as well introduce a\ncommand line flag to the progress clients specifying the socket\nlocation. If we're doing so, at least the progress socket doesn't have\nto be co-located to the other sockets. And we may define a sane\ndefault for the progress socket resembling the current location. So, it\nwon't break but it gives you the possibility to place the progress\nsocket somewhere else. In this case, it's on you to configure the\nsoftware stack to work together as you deviated from the default. If\nyou're sticking to the default, then everything works as it does now\nbecause both, SWUpdate and progress clients, \"agreed\" on the location,\nper convention, and this remains the default.\n\n\n> > +config SOCKET_REMOTE_HANDLER_DIRECTORY\n> > +\tstring \"SWUpdate remote handler socket directory\"\n> > +\tdefault \"/tmp/\"\n> > +\thelp\n> > +\t Directory where sockets to remote handler processes\n> > +\t are expected to be found.\n> > +\n> > \n> > --- a/handlers/remote_handler.c\n> > +++ b/handlers/remote_handler.c\n> > @@ -167,7 +167,7 @@ static int install_remote_image(struct img_type *img,\n> > \tstruct RHmsg RHmessage;\n> > \tchar bufcmd[80];\n> > \n> > -\tlen = strlen(img->type_data) + strlen(TMPDIR) + strlen(\"ipc://\") + 4;\n> > +\tlen = strlen(img->type_data) + strlen(CONFIG_SOCKET_REMOTE_HANDLER_DIRECTORY) + strlen(\"ipc://\") + 4;\n> \n> This is more difficult because this interface allows to bind an external\n> handler, maybe under a closed license.\n\nYes, but again having a sane default and the option to configure it\nwould be nice in my opinion. You have to tie the external handler to\nSWUpdate by means of integration work anyway. Then, while integrating,\nyou're left with the choice to go with the default or chose a different\nlocation. Or do I miss the point here?\n\n\n> > \t/*\n> > \t * Allocate maximum string\n> > @@ -177,7 +177,7 @@ static int install_remote_image(struct img_type *img,\n> > \t\tERROR(\"Not enough memory\");\n> > \t\treturn -ENOMEM;\n> > \t}\n> > -\tsnprintf(connect_string, len, \"ipc://%s%s\", TMPDIR,\n> > +\tsnprintf(connect_string, len, \"ipc://%s%s\", CONFIG_SOCKET_REMOTE_HANDLER_DIRECTORY,\n> > \t\t\timg->type_data);\n> > \n> > \tret = zmq_connect(request, connect_string);\n> > \n> > \n> > --- a/include/network_ipc.h\n> > +++ b/include/network_ipc.h\n> > @@ -24,7 +24,7 @@\n> > #include \"swupdate_status.h\"\n> > \n> > #define IPC_MAGIC\t\t0x14052001\n> > -#define SOCKET_CTRL_PATH\t\"/tmp/sockinstctrl\"\n> > +#define SOCKET_CTRL_PATH\tCONFIG_SOCKET_CTRL_PATH\n> > \n> > typedef enum {\n> > \tREQ_INSTALL,\n> > \n> > \n> > --- a/include/progress.h\n> > +++ b/include/progress.h\n> > @@ -24,7 +24,7 @@\n> > \n> > #include \n> > \n> > -#define SOCKET_PROGRESS_PATH \"/tmp/swupdateprog\"\n> > +#define SOCKET_PROGRESS_PATH CONFIG_SOCKET_PROGRESS_PATH\n> > \n> > /*\n> > * Message sent via socket\n> > ```\n> > \n> > This, however, breaks progress clients if they're compiled out-of-tree\n> > without a proper include/generated/autoconf.h defining, e.g.,\n> \n> Right, but it is bad to export autoconf.h. We should find another way.\n\nYes, I mentioned autoconf.h to illustrate where the #define is coming\nfrom. I don't mean to export the whole SWUpdate config to progress\nclients just for this one #define, this is indeed bad :)\nAs said, I'd like to have a sane default resembling the current\nlocations to not break things but with the option to configure them\nelsewhere, then, of course, putting the obligation of giving the\nprogress clients the right path onto my shoulders.\n\n\n> > CONFIG_SOCKET_CTRL_PATH. Hence, progress clients should get a command\n> > line parameter -s /path/to/socket specifying the path to the progress\n> > IPC socket (and a \"sane\" default as fallback which is the current\n> > hard-coded location in /tmp). The same is true for the other sockets.\n> > \n> > \n> > Carrying things further, TMPDIR as defined in include/util.h:115 and\n> > used in various locations may also be split according to the concern at\n> > hand so that not all temporary files regardless of their concern reside\n> > in /tmp.\n> \n> ok\n> \n> > \n> > \n> > What do you think about this?\n> \n> Possible, but I do not know how to guarantee API consistency.\n> \n> Another way is to put the sockets inside the configuration file instead\n> of defining it via CONFIG_. They are not anymore hard-coded.\n> \n> This can be read from the client, too - but clients should also link\n> libconfig to parse it.\n\nYes, I think this makes them needlessly complicated. You have to\nsupply code for doing so to every progress client implementation. As\nit's just the location, I think a command line flag specifying the\nsocket path and a sane default fall-back would do the trick. Besides,\nthe argumentation above applies here as well: You're supplying the full\nSWUpdate configuration just for one parameter, which is, in my opinion,\na bit too much and the progress clients shouldn't be concerned with the\nother configuration for SWUpdate.\nAPI consistency is given if you're running the default configuration as\nnothing really changes. But, you have the flexibility to do otherwise\nbut then, of course, you have to do the integration work yourself. I\nguess that's fair :)\n\n\n> > As a side note, what do you think about including systemd's socket-based\n> > activation as an optional feature? Then, if a process wants to talk to\n> > the control IPC socket created by systemd, systemd spawns SWUpdate and\n> > hands over the socket to SWUpdate...\n> \n> I do not know if currently work. SWUpdate is monitoring the processes\n> listening to interfaces, and that means it is the spawner. Then, for\n> systemd I understand that these processes will run independently from\n> SWUpdate \"core\", and then it does not monitor them anymore. It works\n> just with external processes with client library. Or can you better\n> detail this proposal ?\n\nWell, this came to my mind while I was thinking about the socket\nlocations and I thought that systemd may as well provide the sockets to\nSWUpdate, if you're using systemd as init, that is. If systemd is not\nused as init, of course, the current behavior remains.\nSo, with the optional feature systemd enabled, there's a swupdate.socket\nunit specifying the sockets and systemd creates those sockets if the\nunit is enabled and started. Upon accessing a socket, systemd starts the\nrelated swupdate.service unit that executes SWUpdate and hands over\nthe sockets systemd created to SWUpdate. Of course, you can start\nswupdate.service right away to start SWUpdate without using socket-based\nactivation.\nWith this, SWUpdate still spawns and monitors the subprocesses but may\nget started in two different ways: either by accessing a socket or\nexplicitly.\nGiven that systemd created the sockets, one has to configure the socket\nlocations in systemd parlance. If this configuration sticks to the\ndefaults, then nothing breaks. Otherwise, one has to give the socket\nlocations to the clients. For this, SWUpdate has to be adapted to spawn\nthose clients with the according socket paths or systemd is used for\nspawning and monitoring the clients.\nAs systemd is very much capable of spawning and supervising the clients,\nit may as well be used for this purpose on systems having systemd. For\nsystems running other init systems not that capable, I would use\nSWUpdate's spawn and supervise capabilities.\n\n\n\nSo, what do you think about all this?\n\n\nKind regards,\n Christian","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=googlegroups.com\n\t(client-ip=2a00:1450:400c:c0c::238;\n\thelo=mail-wr0-x238.google.com;\n\tenvelope-from=swupdate+bncbdd6bwv65qpbbgogutgqkgqejqvllmy@googlegroups.com;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=googlegroups.com header.i=@googlegroups.com\n\theader.b=\"IFoMABnQ\"; dkim-atps=neutral"],"Received":["from mail-wr0-x238.google.com (mail-wr0-x238.google.com\n\t[IPv6:2a00:1450:400c:c0c::238])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkCzK4cB7z9t2r\n\tfor ;\n\tFri, 1 Sep 2017 19:06:36 +1000 (AEST)","by mail-wr0-x238.google.com with SMTP id j3sf619944wrb.6\n\tfor ;\n\tFri, 01 Sep 2017 02:06:36 -0700 (PDT)","by 10.28.145.147 with SMTP id t141ls163376wmd.12.canary-gmail; Fri,\n\t01 Sep 2017 02:06:33 -0700 (PDT)","from david.siemens.de (david.siemens.de. [192.35.17.14])\n\tby gmr-mx.google.com with ESMTPS id\n\tq186si90087wmb.7.2017.09.01.02.06.33\n\tfor \n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 01 Sep 2017 02:06:33 -0700 (PDT)","from mail1.siemens.de (mail1.siemens.de [139.23.33.14])\n\tby david.siemens.de (8.15.2/8.15.2) with ESMTPS id v8196W7j027985\n\t(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)\n\tfor ; Fri, 1 Sep 2017 11:06:32 +0200","from localhost ([139.25.69.251])\n\tby mail1.siemens.de (8.15.2/8.15.2) with ESMTPS id v8196Wrc024881\n\t(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)\n\tfor ; Fri, 1 Sep 2017 11:06:32 +0200"],"ARC-Seal":["i=2; a=rsa-sha256; t=1504256793; cv=pass;\n\td=google.com; s=arc-20160816;\n\tb=t8bOWOi9OIS7PNxI/94N8meUV6WXrhszc0tV6XCGTr7eJYZwBl+jxsEJF9eV7uJKZl\n\tskR9+e0tCxwpQxph3nxUolkz+nTBzkvsiGaZOvkOftAkLyFW/s14f9eC79O7Rul8Bbp2\n\tg3XCnYapurEswW0sRoQjvG3DLD7HtR1FI0yH5wvArGUBYYMlgJ6k1saMnreIoA5bImgi\n\toxktla2ERmbtu3KXFf+RQIVu5O7ZA637CNocjWKhnbUcB16B7i+1GgbD0/3fWKW4Mvun\n\tEmkSzX2kcdfsnp3GqNQ5RnzmpvmBWEkpK86+PzS/wMFp3rOUrjUb4nSwwggclpsVvgFV\n\tsJmw==","i=1; a=rsa-sha256; t=1504256793; cv=none;\n\td=google.com; s=arc-20160816;\n\tb=StjJyjFhgtqPG9XwKteysiADEDnDhSrBAe2Yy+Q5hUJmfty3MeYYGbKxhiYH3V4fXL\n\tbxA0g6zHtQKVNZbauFo8T3pP7D0FzRBW56jNCgwJ0ybn//0tFbmVR53lkWbOwnq3mWUN\n\tzFTDm67qVXzCblf1N7h3yl6rYk6ihX4D20uuINMfp9Pldw+OVxsJnTrz+LmeypV68JY2\n\tzO4UcWLbVtefZn3VHSDhj5/A+ryRdOBa7xx/xz73SvPgWVGg+5u4xvNyYZ9oMbSkZTvB\n\tQmEPuKeVsGVM89iJK0P87c/OVu7CcHEvZq45UHWqwnHoEtdBsX6WS5aiwX9AtTXChvUR\n\tXSGA=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=arc-20160816; \n\th=list-unsubscribe:list-subscribe:list-archive:list-help:list-post\n\t:list-id:mailing-list:precedence:user-agent:in-reply-to\n\t:content-transfer-encoding:content-disposition:mime-version\n\t:mail-followup-to:message-id:subject:to:from:date\n\t:arc-authentication-results:arc-message-signature:sender\n\t:dkim-signature:arc-authentication-results;\n\tbh=PozqpQSVkjjn/fdkhE1PdcnZ7k6SG9gNgQ5ysCTkHE0=;\n\tb=XRMyh9JfVIjkHdZmGoALjvCFnKlQ9n1zC8xM7nEtnPHjGU7Shio8pkP0u0l8FFjkeU\n\tZjgKnXp1pL1BIqi65dI89faH+yI/xDtUfCwFVBXQLECM/Y3oTjVfrkL7T1VJNbWwJl8Z\n\t3LfOFY2Frt7l5Ab+6NgXJNh+THIXZiJAqkI6zj5LK6TJzAYgdGRFv4QP2FB0Kknpg3rA\n\tBlRglYhd5osxjx5ov3uR7koFmTKylyelXDV+N4xb9BklgI6M6x+z+FyuJf0/LCRDi4cQ\n\t4LW+AMe8w/g/BGsq+xrsk3u2okLgFx6Fv8ee1jhG/lML99zad+X26JTRRS+P/sZxCPC3\n\tVnmQ==","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=arc-20160816; \n\th=user-agent:in-reply-to:content-transfer-encoding\n\t:content-disposition:mime-version:mail-followup-to:message-id\n\t:subject:to:from:date:arc-authentication-results;\n\tbh=0vlfgQzyJT7FlU3g4D1theWQ5ImfEK4nu/cuZTo6ax4=;\n\tb=aYfhVMa4MU4/xFSa2ibPJuOqYTIG8jEaZ4mzG1tP9sdTSFekbkFAhpoc8+nN/nY6gV\n\tvmDPus1rxZsSZ6nPHq4RDib6eNo6JUTBlVaAtKLQmU/fY+Thu7mr3/8275lf6Zjo1lWV\n\tJcpjQynA5WoR4Dtq/xVZTLzA3LMSSBoY9tDeeSLL7R3+BqQZDcK7e8VpyJKUmDoQgldS\n\t8maoU8xfpTtPqwQSNM46HztKgY9pzbsqOY1fnO7PIBEUO8jpYqDjw/mPwbfwumKHGf+f\n\tHOZY/ewPNJk0tzXD9/5+zpnMWypo2Uk+izWNBwLSptCcXUBg+hoK+oCwyThZnhZ3XiKy\n\t9B+Q=="],"ARC-Authentication-Results":["i=2; gmr-mx.google.com;\n\tspf=neutral (google.com: 192.35.17.14 is neither permitted nor denied\n\tby best guess record for domain of\n\tchristian.storm@siemens.com)\n\tsmtp.mailfrom=christian.storm@siemens.com","i=1; gmr-mx.google.com;\n\tspf=neutral (google.com: 192.35.17.14 is neither permitted nor denied\n\tby best guess record for domain of\n\tchristian.storm@siemens.com)\n\tsmtp.mailfrom=christian.storm@siemens.com"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=googlegroups.com; s=20161025;\n\th=sender:date:from:to:subject:message-id:mail-followup-to\n\t:mime-version:content-disposition:content-transfer-encoding\n\t:in-reply-to:user-agent:x-original-sender\n\t:x-original-authentication-results:precedence:mailing-list:list-id\n\t:list-post:list-help:list-archive:list-subscribe:list-unsubscribe;\n\tbh=PozqpQSVkjjn/fdkhE1PdcnZ7k6SG9gNgQ5ysCTkHE0=;\n\tb=IFoMABnQFkS3vK6TPUjFXK7B0r2dzTCcUMFoh7bXzyK2qnb1lW8TEqhZlWc3KXQLuC\n\tHRZsszBpxk2Fi8cqG9hfo/Q4EgjzLhEcFkjgXUbcYqwZoEgxCSPIu59//f+o/4GzMSGc\n\txTTLYSKPcY9lGc+2lEvx3swQZqTeIe937x/ff6zMGtlxB0wl9Ke8L08T8OjYhg7iDAQZ\n\tkkbh3jEBU1Q41hIHGEOKBbVNc2OGGaWnf/RspWqngU4JsO5CrrDJrWJc8V4/wZtQwG+m\n\tYaPRW3yyT/bp5DyKELupvcuWBl4NRhiOowkans/7O3GJFCeJJSiSwDned7U9vPJaKuDS\n\tgtvg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=sender:x-gm-message-state:date:from:to:subject:message-id\n\t:mail-followup-to:mime-version:content-disposition\n\t:content-transfer-encoding:in-reply-to:user-agent:x-original-sender\n\t:x-original-authentication-results:precedence:mailing-list:list-id\n\t:x-spam-checked-in-group:list-post:list-help:list-archive\n\t:list-subscribe:list-unsubscribe;\n\tbh=PozqpQSVkjjn/fdkhE1PdcnZ7k6SG9gNgQ5ysCTkHE0=;\n\tb=HUqisdh206o4EPrpYYP6+G2wsyAhl6Mi8vo7Y7Ge4vhXQduFHOaSMUbpRvh9OEA61H\n\tcADWztixQFjRz+Kxlijp14Dd4Iiu3/i1JyNmOFWnO0eoEW3OnQqbX9I69+OVzko3L5dd\n\tw13aOkZx69IiHhGNj2uGerHlFb9h9O8JeZrvAn9WTBbNFv20rEr9hXvEB/eMRZOsw3IF\n\t9oNpyK4QMwkln9EfgpSHXBy6swYmxwYm1FRcpwCqWBFJTK1eiMNnf95gGKyVItEoXdkl\n\t2aI12aOioTZjQytAf4ORyxApwYod86f8Sz4cp6+iwCdZG5T+Uy+BVfQSsEPHnHvdltWd\n\tk+AA==","Sender":"swupdate@googlegroups.com","X-Gm-Message-State":"AHPjjUiCJI7xwNksMwzFsUmm+AKrz22nhCVDxNaxEq+YT/ANfg4R2xNd\n\tVQ8yqy8B2ByrGw==","X-Google-Smtp-Source":"ADKCNb4gf4V2X4T08svo/VffjbNRf0z3nkEP/MjdnyYnIjK9t/zq/L5lOADlQPYeg6JqyEeCIzhL2g==","X-Received":["by 10.28.48.150 with SMTP id w144mr1312wmw.13.1504256793670;\n\tFri, 01 Sep 2017 02:06:33 -0700 (PDT)","by 10.28.13.4 with SMTP id 4mr91799wmn.32.1504256793274;\n\tFri, 01 Sep 2017 02:06:33 -0700 (PDT)"],"X-BeenThere":"swupdate@googlegroups.com","Received-SPF":"neutral (google.com: 192.35.17.14 is neither permitted nor\n\tdenied by best guess record for domain of\n\tchristian.storm@siemens.com) client-ip=192.35.17.14; ","Date":"Fri, 1 Sep 2017 11:04:16 +0200","From":"Christian Storm ","To":"swupdate@googlegroups.com","Subject":"Re: [swupdate] Make socket paths and TMPDIR configurable?","Message-ID":"<20170901090416.33j65fu3slzzg2ke@MD1KR9XC.ww002.siemens.net>","Mail-Followup-To":"swupdate@googlegroups.com","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Disposition":"inline","Content-Transfer-Encoding":"quoted-printable","In-Reply-To":"","User-Agent":"Mutt/20170113 (1.7.2)","X-Original-Sender":"christian.storm@siemens.com","X-Original-Authentication-Results":"gmr-mx.google.com; spf=neutral\n\t(google.com: 192.35.17.14 is neither permitted nor denied by best\n\tguess\n\trecord for domain of christian.storm@siemens.com)\n\tsmtp.mailfrom=christian.storm@siemens.com","Precedence":"list","Mailing-list":"list swupdate@googlegroups.com;\n\tcontact swupdate+owners@googlegroups.com","List-ID":"","X-Spam-Checked-In-Group":"swupdate@googlegroups.com","X-Google-Group-Id":"605343134186","List-Post":",\n\t","List-Help":",\n\t","List-Archive":",\n\t","List-Unsubscribe":",\n\t"}},{"id":1761599,"web_url":"http://patchwork.ozlabs.org/comment/1761599/","msgid":"<1e738f69-9e64-89f8-e4c5-b0b49cb4e424@denx.de>","list_archive_url":null,"date":"2017-09-01T11:22:57","subject":"Re: [swupdate] Make socket paths and TMPDIR configurable?","submitter":{"id":5771,"url":"http://patchwork.ozlabs.org/api/people/5771/","name":"Stefano Babic","email":"sbabic@denx.de"},"content":"Hi Christian,\n\nOn 01/09/2017 11:04, Christian Storm wrote:\n> Hi Stefano,\n> \n>>> I'd like to see the various socket locations be configurable so that I\n>>> can put them into different directories and, e.g., give progress clients\n>>> access to the progress IPC socket only but not to, say, the control IPC\n>>> socket, including the ability to \"see\" the control socket at all.\n>>> Currently, they're all residing in /tmp/, hard-coded.\n>> Right, they are hard-coded.\n>>\n>>>\n>>> As a quick hack, consider something along the lines of the following:\n>>> ```\n>>> --- a/Kconfig\n>>> +++ b/Kconfig\n>>> @@ -110,6 +110,25 @@ config SW_VERSIONS_FILE\n>>> \t but in some cases it can be required to do it. Having a check,\n>>> \t the risky-component is not always updated.\n>>> \n>>> +config SOCKET_CTRL_PATH\n>>> +\tstring \"SWUpdate control socket path\"\n>>> +\tdefault \"/tmp/sockinstctrl\"\n>>> +\thelp\n>>> +\t Path to SWUpdate's IPC socket.\n>>> +\n>>> +config SOCKET_PROGRESS_PATH\n>>> +\tstring \"SWUpdate progress socket path\"\n>>> +\tdefault \"/tmp/swupdateprog\"\n>>> +\thelp\n>>> +\t Path to the socket progress information is sent to.\n>>> +\n>>\n>> The thing is how to export this for the clients. We have an API, that is\n>> the install interface (sockinstctrl) and progress. Both can be used by\n>> external programs to drive SWUpdate. We can set that the client\n>> interface \"must\" be linked to own software, but it remains a strange\n>> situation. We still should guarantee that software built outside\n>> SWUpdate works.\n> \n> Yes, I absolutely agree. It boils down to whether the *location* of the\n> socket is considered as part of the API or not.\n> If the answer is yes, then we shouldn't do it :)\n> If the answer is no or don't care, then we may as well introduce a\n> command line flag to the progress clients specifying the socket\n> location.\n\nIt seems to me a reasonable solution. I would avoid that client are\nconstrained to link libconfig or whatever and try to let the interface\nsimple. Witch command line parameter and fallback to default we reach\nalready the goal.\n\n> If we're doing so, at least the progress socket doesn't have\n> to be co-located to the other sockets. And we may define a sane\n> default for the progress socket resembling the current location. So, it\n> won't break but it gives you the possibility to place the progress\n> socket somewhere else. In this case, it's on you to configure the\n> software stack to work together as you deviated from the default. If\n> you're sticking to the default, then everything works as it does now\n> because both, SWUpdate and progress clients, \"agreed\" on the location,\n> per convention, and this remains the default.\n\nFine with me.\n\n> \n> \n>>> +config SOCKET_REMOTE_HANDLER_DIRECTORY\n>>> +\tstring \"SWUpdate remote handler socket directory\"\n>>> +\tdefault \"/tmp/\"\n>>> +\thelp\n>>> +\t Directory where sockets to remote handler processes\n>>> +\t are expected to be found.\n>>> +\n>>>\n>>> --- a/handlers/remote_handler.c\n>>> +++ b/handlers/remote_handler.c\n>>> @@ -167,7 +167,7 @@ static int install_remote_image(struct img_type *img,\n>>> \tstruct RHmsg RHmessage;\n>>> \tchar bufcmd[80];\n>>> \n>>> -\tlen = strlen(img->type_data) + strlen(TMPDIR) + strlen(\"ipc://\") + 4;\n>>> +\tlen = strlen(img->type_data) + strlen(CONFIG_SOCKET_REMOTE_HANDLER_DIRECTORY) + strlen(\"ipc://\") + 4;\n>>\n>> This is more difficult because this interface allows to bind an external\n>> handler, maybe under a closed license.\n> \n> Yes, but again having a sane default and the option to configure it\n> would be nice in my opinion. You have to tie the external handler to\n> SWUpdate by means of integration work anyway. Then, while integrating,\n> you're left with the choice to go with the default or chose a different\n> location. Or do I miss the point here?\n\nNo, it is ok.\n\n> \n> \n>>> \t/*\n>>> \t * Allocate maximum string\n>>> @@ -177,7 +177,7 @@ static int install_remote_image(struct img_type *img,\n>>> \t\tERROR(\"Not enough memory\");\n>>> \t\treturn -ENOMEM;\n>>> \t}\n>>> -\tsnprintf(connect_string, len, \"ipc://%s%s\", TMPDIR,\n>>> +\tsnprintf(connect_string, len, \"ipc://%s%s\", CONFIG_SOCKET_REMOTE_HANDLER_DIRECTORY,\n>>> \t\t\timg->type_data);\n>>> \n>>> \tret = zmq_connect(request, connect_string);\n>>>\n>>>\n>>> --- a/include/network_ipc.h\n>>> +++ b/include/network_ipc.h\n>>> @@ -24,7 +24,7 @@\n>>> #include \"swupdate_status.h\"\n>>> \n>>> #define IPC_MAGIC\t\t0x14052001\n>>> -#define SOCKET_CTRL_PATH\t\"/tmp/sockinstctrl\"\n>>> +#define SOCKET_CTRL_PATH\tCONFIG_SOCKET_CTRL_PATH\n>>> \n>>> typedef enum {\n>>> \tREQ_INSTALL,\n>>>\n>>>\n>>> --- a/include/progress.h\n>>> +++ b/include/progress.h\n>>> @@ -24,7 +24,7 @@\n>>> \n>>> #include \n>>> \n>>> -#define SOCKET_PROGRESS_PATH \"/tmp/swupdateprog\"\n>>> +#define SOCKET_PROGRESS_PATH CONFIG_SOCKET_PROGRESS_PATH\n>>> \n>>> /*\n>>> * Message sent via socket\n>>> ```\n>>>\n>>> This, however, breaks progress clients if they're compiled out-of-tree\n>>> without a proper include/generated/autoconf.h defining, e.g.,\n>>\n>> Right, but it is bad to export autoconf.h. We should find another way.\n> \n> Yes, I mentioned autoconf.h to illustrate where the #define is coming\n> from. I don't mean to export the whole SWUpdate config to progress\n> clients just for this one #define, this is indeed bad :)\n> As said, I'd like to have a sane default resembling the current\n> locations to not break things but with the option to configure them\n> elsewhere, then, of course, putting the obligation of giving the\n> progress clients the right path onto my shoulders.\n\nOk, we agree. I think that for sockinstctrl we could even think to\nexport the client library and this has the right configuration for\n\"sockinstctrl\". IMHO this is better as simply export the socket, because\nthe internal API is not required to the external installer.\n\n> \n> \n>>> CONFIG_SOCKET_CTRL_PATH. Hence, progress clients should get a command\n>>> line parameter -s /path/to/socket specifying the path to the progress\n>>> IPC socket (and a \"sane\" default as fallback which is the current\n>>> hard-coded location in /tmp). The same is true for the other sockets.\n>>>\n>>>\n>>> Carrying things further, TMPDIR as defined in include/util.h:115 and\n>>> used in various locations may also be split according to the concern at\n>>> hand so that not all temporary files regardless of their concern reside\n>>> in /tmp.\n>>\n>> ok\n>>\n>>>\n>>>\n>>> What do you think about this?\n>>\n>> Possible, but I do not know how to guarantee API consistency.\n>>\n>> Another way is to put the sockets inside the configuration file instead\n>> of defining it via CONFIG_. They are not anymore hard-coded.\n>>\n>> This can be read from the client, too - but clients should also link\n>> libconfig to parse it.\n> \n> Yes, I think this makes them needlessly complicated.\n\nAnd I would like to avoid this.\n\n> You have to\n> supply code for doing so to every progress client implementation. As\n> it's just the location, I think a command line flag specifying the\n> socket path and a sane default fall-back would do the trick.\n\nRight, I agree.\n\n> Besides,\n> the argumentation above applies here as well: You're supplying the full\n> SWUpdate configuration just for one parameter, which is, in my opinion,\n> a bit too much and the progress clients shouldn't be concerned with the\n> other configuration for SWUpdate.\n> API consistency is given if you're running the default configuration as\n> nothing really changes. But, you have the flexibility to do otherwise\n> but then, of course, you have to do the integration work yourself. I\n> guess that's fair :)\n> \n> \n>>> As a side note, what do you think about including systemd's socket-based\n>>> activation as an optional feature? Then, if a process wants to talk to\n>>> the control IPC socket created by systemd, systemd spawns SWUpdate and\n>>> hands over the socket to SWUpdate...\n>>\n>> I do not know if currently work. SWUpdate is monitoring the processes\n>> listening to interfaces, and that means it is the spawner. Then, for\n>> systemd I understand that these processes will run independently from\n>> SWUpdate \"core\", and then it does not monitor them anymore. It works\n>> just with external processes with client library. Or can you better\n>> detail this proposal ?\n> \n> Well, this came to my mind while I was thinking about the socket\n> locations and I thought that systemd may as well provide the sockets to\n> SWUpdate, if you're using systemd as init, that is. If systemd is not\n> used as init, of course, the current behavior remains.\n> So, with the optional feature systemd enabled, there's a swupdate.socket\n> unit specifying the sockets and systemd creates those sockets if the\n> unit is enabled and started. Upon accessing a socket, systemd starts the\n> related swupdate.service unit that executes SWUpdate and hands over\n> the sockets systemd created to SWUpdate. Of course, you can start\n> swupdate.service right away to start SWUpdate without using socket-based\n> activation.\n> With this, SWUpdate still spawns and monitors the subprocesses but may\n> get started in two different ways: either by accessing a socket or\n> explicitly.\n> Given that systemd created the sockets, one has to configure the socket\n> locations in systemd parlance. If this configuration sticks to the\n> defaults, then nothing breaks. Otherwise, one has to give the socket\n> locations to the clients. For this, SWUpdate has to be adapted to spawn\n> those clients with the according socket paths or systemd is used for\n> spawning and monitoring the clients.\n> As systemd is very much capable of spawning and supervising the clients,\n> it may as well be used for this purpose on systems having systemd. For\n> systems running other init systems not that capable, I would use\n> SWUpdate's spawn and supervise capabilities.\n> \n> \n> \n> So, what do you think about all this?\n\nCurrently, I would try to avoid to have a different runtime behaviour.\nIf we have processes sometimes spawned by SWUpdate, sometimes from\nsystemd, we increase the constellation to test and possible\nrace-condition. And internal processes use an anonymous socket to\ncommunicate with the installer that is not visible outside.\n\nBest regards,\nStefano","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=googlegroups.com\n\t(client-ip=2a00:1450:400c:c09::237;\n\thelo=mail-wm0-x237.google.com;\n\tenvelope-from=swupdate+bncbaabbfuguxgqkgqe6rf2eoi@googlegroups.com;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=googlegroups.com header.i=@googlegroups.com\n\theader.b=\"AIS/UaE6\"; dkim-atps=neutral"],"Received":["from mail-wm0-x237.google.com (mail-wm0-x237.google.com\n\t[IPv6:2a00:1450:400c:c09::237])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkH0q6gSSz9s72\n\tfor ;\n\tFri, 1 Sep 2017 21:23:05 +1000 (AEST)","by mail-wm0-x237.google.com with SMTP id r75sf534926wmf.16\n\tfor ;\n\tFri, 01 Sep 2017 04:23:05 -0700 (PDT)","by 10.28.165.198 with SMTP id o189ls171985wme.24.canary-gmail; Fri,\n\t01 Sep 2017 04:23:02 -0700 (PDT)","from mail-out.m-online.net (mail-out.m-online.net.\n\t[2001:a60:0:28:0:1:25:1]) by gmr-mx.google.com with ESMTPS id\n\ty62si123969wme.1.2017.09.01.04.23.02\n\tfor \n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 01 Sep 2017 04:23:02 -0700 (PDT)","from frontend01.mail.m-online.net (unknown [192.168.8.182])\n\tby mail-out.m-online.net (Postfix) with ESMTP id 3xkH0k0Bntz1qw7N;\n\tFri, 1 Sep 2017 13:23:02 +0200 (CEST)","from localhost (dynscan1.mnet-online.de [192.168.6.70])\n\tby mail.m-online.net (Postfix) with ESMTP id 3xkH0j6Jssz3hht8;\n\tFri, 1 Sep 2017 13:23:01 +0200 (CEST)","from mail.mnet-online.de ([192.168.8.182])\n\tby localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id BvLhCYGGXq-e; Fri, 1 Sep 2017 13:23:00 +0200 (CEST)","from babic.homelinux.org\n\t(host-88-217-136-221.customer.m-online.net [88.217.136.221])\n\t(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mail.mnet-online.de (Postfix) with ESMTPS;\n\tFri, 1 Sep 2017 13:23:00 +0200 (CEST)","from localhost (mail.babic.homelinux.org [127.0.0.1])\n\tby babic.homelinux.org (Postfix) with ESMTP id 021F74540535;\n\tFri, 1 Sep 2017 13:23:00 +0200 (CEST)","from babic.homelinux.org ([127.0.0.1])\n\tby localhost (mail.babic.homelinux.org [127.0.0.1]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id M4pjetWFLOpX; Fri, 1 Sep 2017 13:22:57 +0200 (CEST)","from [192.168.178.132] (papero.fritz.box [192.168.178.132])\n\tby babic.homelinux.org (Postfix) with ESMTP id 3DE7945400DB;\n\tFri, 1 Sep 2017 13:22:57 +0200 (CEST)"],"ARC-Seal":["i=2; a=rsa-sha256; t=1504264983; cv=pass;\n\td=google.com; s=arc-20160816;\n\tb=v+9Ek4hIxmyIcrjyJKtP7IyubZPM2UN6Kgs4p0ba+A4UHhHwyMmoxoV6Pwpi7yBWa/\n\tCQOiWoxxLHPYl1yk1VCh2NwZMUMUpRZDB8rDJAINpJLtwfRMLWUm4UCv0YkX3pCSR09i\n\t2U3zbs2qiK7M28VJXjddUW2sspdEDWZqJjE2LE2SA3Fw+iNSrcMiGPtO9cNxUoJXHt6c\n\tBNqohLgeJrV0QKXOm9hceyyZTlMt4Io/tuX556wIO2KxhLTp+kl17VVNS9PAIFxwrN/D\n\tGhZIgYobtA0JWby+56Udr4QghcY0vNsAVbwryjwcIyH7zIZJ5P7WpC2UDdMRkPVkBsfG\n\tsyzw==","i=1; a=rsa-sha256; t=1504264982; cv=none;\n\td=google.com; s=arc-20160816;\n\tb=Zf7N/t2yXuD+DgHPuTtYg/serrSFFYeFwtu+p+yASF95sIgW9GUrInN1pZKpib1j9u\n\tDfFimiHqoLhpYJgKqhdhRRFLJ6+SaFbwvGNEZnd/Lmk6AqDiYgRI63oiq1n82JvJDYQc\n\tT9bLhu2R5lqS0c422Rf4rTuyF3mWDPMxxjluaazL+MHj6M9eIKmcIW9LcH/JT0Uj7rJj\n\tSkeqNH8tkgpGxI8QkhIyUTW06YwUfHDtFxwgoMNNBuubl5fYj8EbtcPtJajnA3/QMkTx\n\tHw4qkxJ70TybqLg039sSnrSgmh787gSkQRnnj8LKYi2kFQ/Y6O0nZg+kmzaTpHkgRmxB\n\tVbIg=="],"ARC-Message-Signature":["i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=arc-20160816; \n\th=list-unsubscribe:list-subscribe:list-archive:list-help:list-post\n\t:list-id:mailing-list:precedence:content-language:in-reply-to\n\t:mime-version:user-agent:date:message-id:from:references:to:subject\n\t:arc-authentication-results:arc-message-signature:sender\n\t:dkim-signature:arc-authentication-results;\n\tbh=2SARkznVNueKMiA54P9bUyvvX10ncut599Wl49eixFU=;\n\tb=F6JTyvl6ea5QyjY1vT/fFK3UHjuQF7uc2aYETHXJimsqSmszAfcsE3+0Rf+f1q7Ueq\n\tTwQ6Cv9OieoMF9RwfDEkaSmoYud7JayHXe1vicebwwxsG0VkCYJuhD6A3lqqyOC4hfoS\n\tad/fVZGxHotTaveRy3LWT8RPWR6rpAQOW+KMIBQqurGIneEF5UdeYx/bDeXwuzOp+ASS\n\tLrOrccikdzz0SUtNksIb7MC7+LGddr8pjdE8LY5+S/ztzYjRfVv91IMninQG6HKLRO0f\n\t2LqEPo/F/kr+be5+SKasOOV06dAEDzSIhSsgCP15MFKpHTyOoTsarzYk/9MKQjRHP18n\n\t94og==","i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n\ts=arc-20160816; \n\th=content-transfer-encoding:content-language:in-reply-to:mime-version\n\t:user-agent:date:message-id:from:references:to:subject\n\t:arc-authentication-results;\n\tbh=fCgpoLVQY2EGIhRKE0BV9BCq6n8O2kbUS6/Pn2sEMnE=;\n\tb=slGienzQ7aezzxYtlvA7gMSJCD0kgUVzC2IkQRVuTTkA932aaKWew1rcqairIcbcGZ\n\thYKAaUJBUKs1UcegyZwM5J6w3jZ/ZAdNgpsR1Xx+E5Qd68UiMpY8p6vroUvhF+uzLBOo\n\tf6QmtadGHvcm2HFEtN/kxXLNi2LoFj+ZMDiue7bR8oTzPVKqDE1nqu9SmUXvh6yuPw9q\n\t9Mn1cJBImiwknO0eaqcrOi0op8JiODKcBclGOAtDBmO4seG0kdgWgj6q+zmb0iPUjEP7\n\tj3G/8A5jcHswSc010Ox55+GVSm8mRFaUstbp+LDbPBDBveShYvh0u/nv6AjuACVBcUyh\n\tD66Q=="],"ARC-Authentication-Results":["i=2; gmr-mx.google.com;\n\tspf=neutral (google.com: 2001:a60:0:28:0:1:25:1 is neither permitted\n\tnor denied by best guess record for domain of sbabic@denx.de)\n\tsmtp.mailfrom=sbabic@denx.de","i=1; gmr-mx.google.com;\n\tspf=neutral (google.com: 2001:a60:0:28:0:1:25:1 is neither permitted\n\tnor denied by best guess record for domain of sbabic@denx.de)\n\tsmtp.mailfrom=sbabic@denx.de"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=googlegroups.com; s=20161025;\n\th=sender:subject:to:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:x-original-sender\n\t:x-original-authentication-results:precedence:mailing-list:list-id\n\t:list-post:list-help:list-archive:list-subscribe:list-unsubscribe;\n\tbh=2SARkznVNueKMiA54P9bUyvvX10ncut599Wl49eixFU=;\n\tb=AIS/UaE6aRWxVxdIxU6q88n43XJ3jSe2k9hE57f03oapb/0TveoMmifdoPdryYeq26\n\tStWhQVVC2LO21SfvD/Mxd0Xw7XYvqWV3ZIXWlh03xPLwW3oGLEsPTp+B2gxzHK4uoyT4\n\t/KyqFqxSwllcI2EvU8ZOCNVAt7rbg6JHH71DW8YEeeHH0EGoHIwG4tI3ZlAdDCNaXKAx\n\tARguT/3Mq6xJPa3wHGZ/NoaOgy/wC0yX0utKwns9n4scmNiP5knsW+YHBPVjTsmVTWH7\n\tepd8ukLQgzeRusAO6u6O4f3/3fPuLmBPfoAsLwu7GGfXT5JDwlw010oWNrzzjM4qRLW3\n\tBajQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=sender:x-gm-message-state:subject:to:references:from:message-id\n\t:date:user-agent:mime-version:in-reply-to:content-language\n\t:x-original-sender:x-original-authentication-results:precedence\n\t:mailing-list:list-id:x-spam-checked-in-group:list-post:list-help\n\t:list-archive:list-subscribe:list-unsubscribe;\n\tbh=2SARkznVNueKMiA54P9bUyvvX10ncut599Wl49eixFU=;\n\tb=RiSIENdpd8Nuq1Zk7FsLlvNfQLin9Rw8sAaOVt7vQkyz7OZW/AjzD6IOUPeD4QTU+/\n\tJ70g/oSQarAliRFE91Kojoy9E6bCMlT7BDHaAvPZXqGAW6JG1ZK/6ALiZTHxl+bI+mOD\n\tgn5uHqf/wsBzploG42P6ItjB+tvhgk3wCQmqV3xEPd2n+iNTVSu3SGG4B3K2aW4VtRao\n\tPQnUSbFPFq9c6jDRXR9iy7Z5k6ddCbuGaUWNqCVlGfI4UWiFo2wTBU7T9kogzhv9qJIC\n\t9yTuSVh7YyXAJrZzYSyb5gX78p51mmc5cBE8w5/4E0GniG9YgfC2zKitzjKgxQimVqL/\n\tdGzg==","Sender":"swupdate@googlegroups.com","X-Gm-Message-State":"AHPjjUgkwU2Dbevq9eNCYYqOId4NJEwawcjKiew0PtsIM7TlYzzZqFDk\n\tFdx3857K/+wRxg==","X-Google-Smtp-Source":"ADKCNb58CQxTxu3hSaZyj4gXzjQ2GICgrgRZgncS0y9dIviEgKouma4ORC/N+Wg3QTw3XVUcU1bKhQ==","X-Received":["by 10.28.16.200 with SMTP id 191mr359wmq.29.1504264982899;\n\tFri, 01 Sep 2017 04:23:02 -0700 (PDT)","by 10.28.178.12 with SMTP id b12mr28330wmf.3.1504264982468;\n\tFri, 01 Sep 2017 04:23:02 -0700 (PDT)"],"X-BeenThere":"swupdate@googlegroups.com","Received-SPF":"neutral (google.com: 2001:a60:0:28:0:1:25:1 is neither\n\tpermitted nor denied by best guess record for domain of\n\tsbabic@denx.de) client-ip=2001:a60:0:28:0:1:25:1; ","X-Virus-Scanned":["amavisd-new at mnet-online.de","Debian amavisd-new at babic.homelinux.org"],"Subject":"Re: [swupdate] Make socket paths and TMPDIR configurable?","To":"swupdate@googlegroups.com, Christian Storm ","References":"<20170901090416.33j65fu3slzzg2ke@MD1KR9XC.ww002.siemens.net>","From":"Stefano Babic ","Message-ID":"<1e738f69-9e64-89f8-e4c5-b0b49cb4e424@denx.de>","Date":"Fri, 1 Sep 2017 13:22:57 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170901090416.33j65fu3slzzg2ke@MD1KR9XC.ww002.siemens.net>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Language":"de-DE","X-Original-Sender":"sbabic@denx.de","X-Original-Authentication-Results":"gmr-mx.google.com; spf=neutral\n\t(google.com: 2001:a60:0:28:0:1:25:1 is neither permitted nor denied\n\tby best\n\tguess record for domain of sbabic@denx.de)\n\tsmtp.mailfrom=sbabic@denx.de","Precedence":"list","Mailing-list":"list swupdate@googlegroups.com;\n\tcontact swupdate+owners@googlegroups.com","List-ID":"","X-Spam-Checked-In-Group":"swupdate@googlegroups.com","X-Google-Group-Id":"605343134186","List-Post":",\n\t","List-Help":",\n\t","List-Archive":",\n\t","List-Unsubscribe":",\n\t"}}]