Message ID | 20210423161534.32738-1-robin.roevens@disroot.org |
---|---|
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4FRfYH2tYPz44R4 for <patchwork@web04.haj.ipfire.org>; Fri, 23 Apr 2021 16:16:19 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4FRfYG1f2wzyR; Fri, 23 Apr 2021 16:16:18 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4FRfYF6sSBz2y0s; Fri, 23 Apr 2021 16:16:17 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4FRfYD2JL8z2xNg for <development@lists.ipfire.org>; Fri, 23 Apr 2021 16:16:16 +0000 (UTC) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPS id 4FRfXw6W9Yz5Z for <development@lists.ipfire.org>; Fri, 23 Apr 2021 16:16:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 6013C5302E for <development@lists.ipfire.org>; Fri, 23 Apr 2021 18:15:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9sEUiGeKmmU for <development@lists.ipfire.org>; Fri, 23 Apr 2021 18:15:58 +0200 (CEST) Received: from amaterasu.sicho.home ([192.168.0.1] helo=chojin.sicho.home) by filekeeper.sicho.home with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <robin.roevens@disroot.org>) id 1lZyT6-0007uY-EP for development@lists.ipfire.org; Fri, 23 Apr 2021 18:15:48 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1619194558; bh=FRoQd1NPH2kQFQlJ+g26wcArTc+2jzPftNH2U5weSws=; h=From:To:Subject:Date; b=fW5WbFCH+rARKk9ftncLRcWC0ZuDZrMiRgbRReVJvQ0NeX1jbHseRtn04BABkWtJa QBzWIcii4iJ3vNjURtFXqQmrNTYpCVeKt+rF/euExQqVmSqCQCCr2FB6tHDUjuz7Mr UPnqC9YrDpHfdu/HxU2kxga5JNADGE8GslEYgMrXIS0iesmxsfB5SLyhfSgTszsUE8 2PrE7Yi9F8DcoXVfaQ0/p3WpPUnczHfFMXsOMu36IE496XOpqca/AOIM4WZ5Wmsw6s wAhCtSBTXg8M+EUyJeFvE3Wn97Xjgnt4sOtaEMw/BMslLacf+ndM8jmcWNQZew4VF1 4rgCWmmL6BW5Q== From: Robin Roevens <robin.roevens@disroot.org> To: development@lists.ipfire.org Subject: [PATCH 0/3] Pakfile metadata enhancements Date: Fri, 23 Apr 2021 18:15:31 +0200 Message-Id: <20210423161534.32738-1-robin.roevens@disroot.org> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-filekeeper-MailScanner-ID: 1lZyT6-0007uY-EP X-filekeeper-MailScanner: Found to be clean X-filekeeper-MailScanner-From: robin.roevens@disroot.org X-filekeeper-MailScanner-Watermark: 1619799349.20219@Udwzwtuk5vEaeTXtebXmCg ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1619194561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=hqcJYNtPaUHhjli4mqrFAbKE3e/M0qnqk13HbYrpmeY=; b=hZRO79q1qC5OL/TX0NZIiHPzxQB7Chff+FhRS5n5JVPPBjKuq8iFcbPqMV5Kvx/EgOMGSb iQUBn0MMdZslD7oQjKnNeyz9owsrXJa7/iZXVEjQofW3oxqzw5BerBAEkf3jZ03It0KfW3 CfKhgT8Z2sPQb07ygW1vqDZ1ACIOt09vfSdnbS4Ciar+NsnINgA9CMixlVWpDTEA6PkCez 9vd0wzeY4amPeoZrYLvT3dfwk2gx3LRD4w+Q5uBoFkLyopauFlMN5XDgHVeSPIMRHv3UL0 NFwkr5ZvuCqV54maG6CSzJo8VmHifJuyfsXrMEjgdTjWOAA7o8X2YL+aiPV5tw== ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b=fW5WbFCH; spf=pass (mail01.ipfire.org: domain of robin.roevens@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=robin.roevens@disroot.org ARC-Seal: i=1; s=202003rsa; d=lists.ipfire.org; t=1619194561; a=rsa-sha256; cv=none; b=WOkKjuQI7UxcOlsiwKU7mgwDW16D1oeuHdx4wwpQqLgirQsOCzO1rO0vh7y/GcDyRQe7Kq Y2IYeZ/wP6mWn3zk/55aDSosm9gyIrRtmAG6ymEdUgl4s0DYuiRW0Bc9XvCQogUIO855GZ ZU3FqhrgvylhhuzFT2IgS33HLlwhuRYGo7RTr+Lzsv6r6zOMcyrQtHiFNjvCnkRTK+1YJw WEwhp6r/Q0l50NKBOttsMYy4Kz08OjEw8QWmwEyD1lsXgvQPuArW6TKPofgOAsi6Hlz7tq wFyyxO0SOdnr1fto0p8P64CBfcGvNN2WQ9IJyfG7+SUTtEbQq21PRMdCGZYdrw== X-Rspamd-Server: mail01.haj.ipfire.org X-Spamd-Result: default: False [-1.59 / 11.00]; ARC_NA(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; R_DKIM_ALLOW(-0.20)[disroot.org:s=mail]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_MISSING_CHARSET(2.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[development@lists.ipfire.org]; BROKEN_CONTENT_TYPE(1.50)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[disroot.org:+]; DMARC_POLICY_ALLOW(-0.50)[disroot.org,quarantine]; MID_CONTAINS_FROM(1.00)[]; BLOCKLISTDE_FAIL(0.00)[178.21.23.139:query timed out]; IP_REPUTATION_HAM(-2.42)[asn: 50673(-0.34), country: NL(-0.01), ip: 178.21.23.139(-0.86)]; NEURAL_HAM(-1.00)[-1.000]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:50673, ipnet:178.21.23.0/24, country:NL]; BAYES_HAM(-2.67)[98.57%] X-Rspamd-Queue-Id: 4FRfXw6W9Yz5Z Authentication-Results: mail01.ipfire.org; dkim=pass header.d=disroot.org header.s=mail header.b=fW5WbFCH; dmarc=pass (policy=quarantine) header.from=disroot.org; spf=pass (mail01.ipfire.org: domain of robin.roevens@disroot.org designates 178.21.23.139 as permitted sender) smtp.mailfrom=robin.roevens@disroot.org X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
Pakfile metadata enhancements
|
|
Message
Robin Roevens
April 23, 2021, 4:15 p.m. UTC
Hi folks During my discussion with Michael in the zabbix_agentd patchset thread about knowing what addon services should be running or not, it came up that it would be handy for several reasons if we had a bit more metadata for pak-files as we currently have. Mostly knowing which services (initscripts) are installed by a pak-file. This would allow for services.cgi to not have to manually try to find out if an installed addon actually has an initscript or not. Also paks like libvirt install 2 initscripts, those can now both be displayed on the services.cgi page. Idem for monitoring agents, which was my main objective. So here is an attempt to achieve this. This is not yet a patchset to be applied yet, but rather a proposal as this change would require all addon LFS-files to be changed. But I didn't want to do that yet as this patchset may very wel be rejected completely :-). The first patch introduces 2 new macro's: - SUMMARY for a short, one-line summary of the package - INITSCRIPTS for a space seperated list of initscripts provided by the package. And an alternative INSTALL_INITSCRIPTS method instead of the current INSTALL_INITSCRIPT method. As we now have all initscripts in the INITSCRIPTS macro, the INSTALL_INITSCRIPTS will install all initscripts listed in that macro, so a simple call to INSTALL_INITSCRIPTS will now do the job instead of multiple calls in case of multiple initscripts (for example libvirt. I noticed clamav actually uses 1 initscript for starting 2 services, this could maybe also be split up again) I included 2 examples in the first patch: libvirt and zabbix_agentd. But when implemented ofcourse all makefiles should be updated. During the pak packaging process in the build procedure, those new macro's will be inheritted in the generated pakfire meta-* files. The second patch adds an extra 'info <pak(s)>' commandline parameter to pakfire, which will in turn call a new Pakfire::pakinfo function. This function wil parse the meta-* file of the requested pak and functions in 2 modes: - "latest" which is the behaviour of the info parameter. This will display the latest available metadata of the pak and the status of the pak on the system as in: is it installed?, and if so, is it up-to-date. - "installed" wich will display only information about the currently installed pak and bail out of the requested pak is not currently installed. This function was added to provide a 'central' point/method to get pak information. I don't know if there are other scripts beside services.cgi that currently try parsing meta-* files. But they should then be changed to use this function instead. Example output of the new pakfire info command: `pakfire info zabbix_agentd`: when installed and up-to-date: --- Name: zabbix_agentd Version: 4.2.6-4 Summary: Zabbix Agent Size: 250.00 KB Dependencies: Pakfile: zabbix_agentd-4.2.6-4.ipfire InitScripts: zabbix_agentd Installed: Yes Status: up-to-date --- When an update is available: --- Name: zabbix_agentd Version: 5.0.10-5 Summary: Zabbix Agent Size: 276.00 KB Dependencies: fping Pakfile: zabbix_agentd-5.0.10-5.ipfire InitScripts: zabbix_agentd Installed: Yes Status: outdated (version 4.2.6-4 is installed) --- Or when a pak was discontinued and no longer supplied by ipfire, but still installed on the system: --- Name: zabbix_agentd Version: - Summary: Zabbix Agent Size: 250.00 KB Dependencies: Pakfile: zabbix_agentd-4.2.6-4.ipfire InitScripts: zabbix_agentd Installed: Yes Status: obsolete (version 4.2.6-4 is installed) --- and at last when a pak is available, but not installed: --- Name: zabbix_agentd Version: 5.0.10-5 Summary: Zabbix Agent Size: 276.00 KB Dependencies: fping Pakfile: zabbix_agentd-5.0.10-5.ipfire InitScripts: zabbix_agentd Installed: No Status: not installed --- And then the last patch is an update of service.cgi now using the new Pakfire::pakinfo function in "installed"-mode. If there are any suggestions on more metadata.. I think this is the moment to throw them at me. And ofcourse suggestions/comments are welcome as this is currently only a proposal for change. But I think we win in robustness of services.cgi and user experience in both using pakfire and ability to provide available services to monitoring agents. On top of that could the whole meta-* files system be overhauled in the future, if wanted, with only pakfire itself needing change as the rest will then depend on pakfire for correctly parsing it's "database". Regards Robin
Comments
A gentle reminder to the group, please check out this proposal for adding and consulting extra metadata to paks, and comment on it, maybe suggest other metadata besides initscripts and summary that I implemented in this proposal patch-set, that could be handy for other addons or cgi pages or just plain info to the user... Thanks.. Robin Robin Roevens schreef op vr 23-04-2021 om 18:15 [+0200]: > Hi folks > > During my discussion with Michael in the zabbix_agentd patchset > thread > about knowing what addon services should be running or not, it came > up > that it would be handy for several reasons if we had a bit more > metadata > for pak-files as we currently have. Mostly knowing which services > (initscripts) are installed by a pak-file. > This would allow for services.cgi to not have to manually try to find > out if an installed addon actually has an initscript or not. > Also paks like libvirt install 2 initscripts, those can now both be > displayed on the services.cgi page. > Idem for monitoring agents, which was my main objective. > > So here is an attempt to achieve this. This is not yet a patchset to > be applied yet, but rather a proposal as this change would require > all > addon LFS-files to be changed. But I didn't want to do that yet as > this patchset may very wel be rejected completely :-). > > The first patch introduces 2 new macro's: > - SUMMARY for a short, one-line summary of the package > - INITSCRIPTS for a space seperated list of initscripts provided by > the > package. > And an alternative INSTALL_INITSCRIPTS method instead of the current > INSTALL_INITSCRIPT method. As we now have all initscripts in the > INITSCRIPTS macro, the INSTALL_INITSCRIPTS will install all > initscripts > listed in that macro, so a simple call to INSTALL_INITSCRIPTS will > now > do the job instead of multiple calls in case of multiple initscripts > (for example libvirt. I noticed clamav actually uses 1 initscript for > starting 2 services, this could maybe also be split up again) > I included 2 examples in the first patch: libvirt and zabbix_agentd. > But > when implemented ofcourse all makefiles should be updated. > > During the pak packaging process in the build procedure, those new > macro's will be inheritted in the generated pakfire meta-* files. > > The second patch adds an extra 'info <pak(s)>' commandline parameter > to > pakfire, which will in turn call a new Pakfire::pakinfo function. > This function wil parse the meta-* file of the requested pak and > functions in 2 modes: > - "latest" which is the behaviour of the info parameter. This will > display the latest available metadata of the pak and the status of > the pak on the system as in: is it installed?, and if so, is it > up-to-date. > - "installed" wich will display only information about the currently > installed pak and bail out of the requested pak is not currently > installed. > This function was added to provide a 'central' point/method to get > pak > information. I don't know if there are other scripts beside > services.cgi > that currently try parsing meta-* files. But they should then be > changed > to use this function instead. > > Example output of the new pakfire info command: `pakfire info > zabbix_agentd`: > when installed and up-to-date: > --- > Name: zabbix_agentd > Version: 4.2.6-4 > Summary: Zabbix Agent > Size: 250.00 KB > Dependencies: > Pakfile: zabbix_agentd-4.2.6-4.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: up-to-date > --- > When an update is available: > --- > Name: zabbix_agentd > Version: 5.0.10-5 > Summary: Zabbix Agent > Size: 276.00 KB > Dependencies: fping > Pakfile: zabbix_agentd-5.0.10-5.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: outdated (version 4.2.6-4 is installed) > --- > Or when a pak was discontinued and no longer supplied by ipfire, but > still installed on the system: > --- > Name: zabbix_agentd > Version: - > Summary: Zabbix Agent > Size: 250.00 KB > Dependencies: > Pakfile: zabbix_agentd-4.2.6-4.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: obsolete (version 4.2.6-4 is installed) > --- > and at last when a pak is available, but not installed: > --- > Name: zabbix_agentd > Version: 5.0.10-5 > Summary: Zabbix Agent > Size: 276.00 KB > Dependencies: fping > Pakfile: zabbix_agentd-5.0.10-5.ipfire > InitScripts: zabbix_agentd > Installed: No > Status: not installed > --- > > And then the last patch is an update of service.cgi now using the new > Pakfire::pakinfo function in "installed"-mode. > > If there are any suggestions on more metadata.. I think this is the > moment to throw them at me. > And ofcourse suggestions/comments are welcome as this is currently > only > a proposal for change. But I think we win in robustness of > services.cgi > and user experience in both using pakfire and ability to provide > available services to monitoring agents. > On top of that could the whole meta-* files system be overhauled in > the > future, if wanted, with only pakfire itself needing change as the > rest > will then depend on pakfire for correctly parsing it's "database". > > > Regards > Robin > > >
Hi, > Am 23.04.2021 um 18:16 schrieb Robin Roevens <robin.roevens@disroot.org>: > > Hi folks > > During my discussion with Michael in the zabbix_agentd patchset thread > about knowing what addon services should be running or not, it came up > that it would be handy for several reasons if we had a bit more metadata > for pak-files as we currently have. Mostly knowing which services > (initscripts) are installed by a pak-file. > This would allow for services.cgi to not have to manually try to find > out if an installed addon actually has an initscript or not. > Also paks like libvirt install 2 initscripts, those can now both be > displayed on the services.cgi page. > Idem for monitoring agents, which was my main objective. > > So here is an attempt to achieve this. This is not yet a patchset to > be applied yet, but rather a proposal as this change would require all > addon LFS-files to be changed. But I didn't want to do that yet as > this patchset may very wel be rejected completely :-). > The first patch introduces 2 new macro's: So it could be done in two separate patches or even better patch sets. Makes reviewing easier and patches shorter :-) > - SUMMARY for a short, one-line summary of the package > - INITSCRIPTS for a space seperated list of initscripts provided by the > package. How it is supposed to be handled when a package (like libvirt) install its own init scripts? So not a initscript we have in our source, but which is delivered in the source of the package itself. If we put this in the list, the macro will break. If we leave it out we lose information. Do you did some research how other distribution handle this problem? ( If they handle it at all.) Another approach which comes to my mind: Why not parsing the root file for /etc/rc.d/init.d/ (I currently do not know if it is the right path)? So trying to detect which initscripts are part of the root file? > And an alternative INSTALL_INITSCRIPTS method instead of the current > INSTALL_INITSCRIPT method. As we now have all initscripts in the > INITSCRIPTS macro, the INSTALL_INITSCRIPTS will install all initscripts > listed in that macro, so a simple call to INSTALL_INITSCRIPTS will now > do the job instead of multiple calls in case of multiple initscripts > (for example libvirt. I noticed clamav actually uses 1 initscript for > starting 2 services, this could maybe also be split up again) > I included 2 examples in the first patch: libvirt and zabbix_agentd. But > when implemented ofcourse all makefiles should be updated. > > During the pak packaging process in the build procedure, those new > macro's will be inheritted in the generated pakfire meta-* files. > > The second patch adds an extra 'info <pak(s)>' commandline parameter to > pakfire, which will in turn call a new Pakfire::pakinfo function. > This function wil parse the meta-* file of the requested pak and > functions in 2 modes: > - "latest" which is the behaviour of the info parameter. This will > display the latest available metadata of the pak and the status of > the pak on the system as in: is it installed?, and if so, is it > up-to-date. > - "installed" wich will display only information about the currently > installed pak and bail out of the requested pak is not currently > installed. > This function was added to provide a 'central' point/method to get pak > information. I don't know if there are other scripts beside services.cgi > that currently try parsing meta-* files. But they should then be changed > to use this function instead. > > Example output of the new pakfire info command: `pakfire info zabbix_agentd`: > when installed and up-to-date: > --- > Name: zabbix_agentd > Version: 4.2.6-4 > Summary: Zabbix Agent > Size: 250.00 KB > Dependencies: > Pakfile: zabbix_agentd-4.2.6-4.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: up-to-date > --- > When an update is available: > --- > Name: zabbix_agentd > Version: 5.0.10-5 > Summary: Zabbix Agent > Size: 276.00 KB > Dependencies: fping > Pakfile: zabbix_agentd-5.0.10-5.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: outdated (version 4.2.6-4 is installed) > --- > Or when a pak was discontinued and no longer supplied by ipfire, but > still installed on the system: > --- > Name: zabbix_agentd > Version: - > Summary: Zabbix Agent > Size: 250.00 KB > Dependencies: > Pakfile: zabbix_agentd-4.2.6-4.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: obsolete (version 4.2.6-4 is installed) > --- > and at last when a pak is available, but not installed: > --- > Name: zabbix_agentd > Version: 5.0.10-5 > Summary: Zabbix Agent > Size: 276.00 KB > Dependencies: fping > Pakfile: zabbix_agentd-5.0.10-5.ipfire > InitScripts: zabbix_agentd > Installed: No > Status: not installed > --- > > And then the last patch is an update of service.cgi now using the new > Pakfire::pakinfo function in "installed"-mode. > > If there are any suggestions on more metadata.. I think this is the > moment to throw them at me. > And ofcourse suggestions/comments are welcome as this is currently only > a proposal for change. But I think we win in robustness of services.cgi > and user experience in both using pakfire and ability to provide > available services to monitoring agents. Just want to say thank you for taking this way, which might be “harder” but yields better result from my experience. Please do not take my points as “this is not right”, more like “there might me other ways, are they better?”. Greetings Jonatan > On top of that could the whole meta-* files system be overhauled in the > future, if wanted, with only pakfire itself needing change as the rest > will then depend on pakfire for correctly parsing it's "database". > > > Regards > Robin > > > > -- > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. >
Hi Jonatan Jonatan Schlag schreef op wo 12-05-2021 om 20:45 [+0200]: > Hi, > > > Am 23.04.2021 um 18:16 schrieb Robin Roevens < > > robin.roevens@disroot.org>: > > > > Hi folks > > > > During my discussion with Michael in the zabbix_agentd patchset > > thread > > about knowing what addon services should be running or not, it came > > up > > that it would be handy for several reasons if we had a bit more > > metadata > > for pak-files as we currently have. Mostly knowing which services > > (initscripts) are installed by a pak-file. > > This would allow for services.cgi to not have to manually try to find > > out if an installed addon actually has an initscript or not. > > Also paks like libvirt install 2 initscripts, those can now both be > > displayed on the services.cgi page. > > Idem for monitoring agents, which was my main objective. > > > > So here is an attempt to achieve this. This is not yet a patchset to > > be applied yet, but rather a proposal as this change would require > > all > > addon LFS-files to be changed. But I didn't want to do that yet as > > this patchset may very wel be rejected completely :-). > > The first patch introduces 2 new macro's: > So it could be done in two separate patches or even better patch sets. > Makes reviewing easier and patches shorter :-) > > - SUMMARY for a short, one-line summary of the package > > - INITSCRIPTS for a space seperated list of initscripts provided by > > the > > package. > > How it is supposed to be handled when a package (like libvirt) install > its own init scripts? So not a initscript we have in our source, but > which is delivered in the source of the package itself. If we put this > in the list, the macro will break. If we leave it out we lose > information. > You have a point there. In the case of libvirt it, as you point out in your other mail, is indeed an initscript that does not start a service so does not pose a problem using this method. But it is not unthinkable that another pak (or a possible future pak) includes an initscript in the source itself. So this is may indeed be something to take into account.. > Do you did some research how other distribution handle this problem? > ( If they handle it at all.) "normal" distributions generally don't really care which packages run which services and if/or those are actually services. However most modern distro's use systemd making it easier to know which units are services, and which are so called one-shots as you can just ask systemd. It has a lot more info about all "initscripts" which would make this task easier. But we don't have systemd here :-) Also Zabbix monitoring agent for example has no built-in methods to automatically discover available and/or running services when the monitored distro is not running systemd. While it already does this for decades for Windows hosts. And more recently also for systemd. In Suse, each package containing a service also created a link /usr/sbin/rc<servicename> which links to the 'service' command which currently is a wrapper script to systemd. Not sure how they did it before systemd, possibly those rc-binaries where just symlinks to the actual initscripts. That is maybe something we may also need to consider, but then rather for better user cli experience as I don't immediately see that solving the problem you posed. > > Another approach which comes to my mind: > Why not parsing the root file for /etc/rc.d/init.d/ (I currently do not > know if it is the right path)? So trying to detect which initscripts > are part of the root file? > As you concluded in your other mail, not all initscripts are services/daemons so that would probably require some hardcoded exceptions and alike. Which is exactly what we are trying to avoid and is currently done in services.cgi. :-) To tackle the problem with service-initscripts included in and installed by the source in my approach; I currently see 2 possible solutions: - also provide the old INSTALL_INITSCRIPT macro to manually install one or more initscripts, so you are able to skip initscripts listed in INITSCRIPTS but which are installed by the source. - make it a common practice to prevent the source from installing an initscript, extracting it and installing it the IPFire way. (I think initscript investigation is probably required anyway to make sure it is compatible on IPFire..) > > And an alternative INSTALL_INITSCRIPTS method instead of the > > current > > INSTALL_INITSCRIPT method. As we now have all initscripts in the > > INITSCRIPTS macro, the INSTALL_INITSCRIPTS will install all > > initscripts > > listed in that macro, so a simple call to INSTALL_INITSCRIPTS will > > now > > do the job instead of multiple calls in case of multiple > > initscripts > > (for example libvirt. I noticed clamav actually uses 1 initscript > > for > > starting 2 services, this could maybe also be split up again) > > I included 2 examples in the first patch: libvirt and > > zabbix_agentd. But > > when implemented ofcourse all makefiles should be updated. > > > > During the pak packaging process in the build procedure, those new > > macro's will be inheritted in the generated pakfire meta-* files. > > > > The second patch adds an extra 'info <pak(s)>' commandline > > parameter to > > pakfire, which will in turn call a new Pakfire::pakinfo function. > > This function wil parse the meta-* file of the requested pak and > > functions in 2 modes: > > - "latest" which is the behaviour of the info parameter. This will > > display the latest available metadata of the pak and the status of > > the pak on the system as in: is it installed?, and if so, is it > > up-to-date. > > - "installed" wich will display only information about the > > currently > > installed pak and bail out of the requested pak is not currently > > installed. > > This function was added to provide a 'central' point/method to get > > pak > > information. I don't know if there are other scripts beside > > services.cgi > > that currently try parsing meta-* files. But they should then be > > changed > > to use this function instead. > > > > Example output of the new pakfire info command: `pakfire info > > zabbix_agentd`: > > when installed and up-to-date: > > --- > > Name: zabbix_agentd > > Version: 4.2.6-4 > > Summary: Zabbix Agent > > Size: 250.00 KB > > Dependencies: > > Pakfile: zabbix_agentd-4.2.6-4.ipfire > > InitScripts: zabbix_agentd > > Installed: Yes > > Status: up-to-date > > --- > > When an update is available: > > --- > > Name: zabbix_agentd > > Version: 5.0.10-5 > > Summary: Zabbix Agent > > Size: 276.00 KB > > Dependencies: fping > > Pakfile: zabbix_agentd-5.0.10-5.ipfire > > InitScripts: zabbix_agentd > > Installed: Yes > > Status: outdated (version 4.2.6-4 is installed) > > --- > > Or when a pak was discontinued and no longer supplied by ipfire, > > but > > still installed on the system: > > --- > > Name: zabbix_agentd > > Version: - > > Summary: Zabbix Agent > > Size: 250.00 KB > > Dependencies: > > Pakfile: zabbix_agentd-4.2.6-4.ipfire > > InitScripts: zabbix_agentd > > Installed: Yes > > Status: obsolete (version 4.2.6-4 is installed) > > --- > > and at last when a pak is available, but not installed: > > --- > > Name: zabbix_agentd > > Version: 5.0.10-5 > > Summary: Zabbix Agent > > Size: 276.00 KB > > Dependencies: fping > > Pakfile: zabbix_agentd-5.0.10-5.ipfire > > InitScripts: zabbix_agentd > > Installed: No > > Status: not installed > > --- > > > > And then the last patch is an update of service.cgi now using the > > new > > Pakfire::pakinfo function in "installed"-mode. > > > > If there are any suggestions on more metadata.. I think this is the > > moment to throw them at me. > > And ofcourse suggestions/comments are welcome as this is currently > > only > > a proposal for change. But I think we win in robustness of > > services.cgi > > and user experience in both using pakfire and ability to provide > > available services to monitoring agents. > Just want to say thank you for taking this way, which might be > “harder” but yields better result from my experience. Please do not > take my points as “this is not right”, more like “there might me > other ways, are they better?”. > That is exactly why I threw this in the group; to check if there are better idea's/approaches/things I overlooked/.. So thank you for your constructive comments! Regards Robin > Greetings Jonatan > > On top of that could the whole meta-* files system be overhauled in > > the > > future, if wanted, with only pakfire itself needing change as the > > rest > > will then depend on pakfire for correctly parsing it's "database". > > > > > > Regards > > Robin > > > > > > > > -- > > Dit bericht is gescanned op virussen en andere gevaarlijke > > inhoud door MailScanner en lijkt schoon te zijn. > > >
Hi Robin, On 13/05/2021 00:31, Robin Roevens wrote: > Hi Jonatan > > Jonatan Schlag schreef op wo 12-05-2021 om 20:45 [+0200]: >> Hi, >> >>> Am 23.04.2021 um 18:16 schrieb Robin Roevens < >>> robin.roevens@disroot.org>: >>> >>> Hi folks >>> >>> During my discussion with Michael in the zabbix_agentd patchset >>> thread >>> about knowing what addon services should be running or not, it came >>> up >>> that it would be handy for several reasons if we had a bit more >>> metadata >>> for pak-files as we currently have. Mostly knowing which services >>> (initscripts) are installed by a pak-file. >>> This would allow for services.cgi to not have to manually try to find >>> out if an installed addon actually has an initscript or not. >>> Also paks like libvirt install 2 initscripts, those can now both be >>> displayed on the services.cgi page. >>> Idem for monitoring agents, which was my main objective. >>> >>> So here is an attempt to achieve this. This is not yet a patchset to >>> be applied yet, but rather a proposal as this change would require >>> all >>> addon LFS-files to be changed. But I didn't want to do that yet as >>> this patchset may very wel be rejected completely :-). >>> The first patch introduces 2 new macro's: >> So it could be done in two separate patches or even better patch sets. >> Makes reviewing easier and patches shorter :-) >>> - SUMMARY for a short, one-line summary of the package >>> - INITSCRIPTS for a space seperated list of initscripts provided by >>> the >>> package. >> How it is supposed to be handled when a package (like libvirt) install >> its own init scripts? So not a initscript we have in our source, but >> which is delivered in the source of the package itself. If we put this >> in the list, the macro will break. If we leave it out we lose >> information. >> > You have a point there. In the case of libvirt it, as you point out in > your other mail, is indeed an initscript that does not start a service > so does not pose a problem using this method. > But it is not unthinkable that another pak (or a possible future pak) > includes an initscript in the source itself. > So this is may indeed be something to take into account.. > >> Do you did some research how other distribution handle this problem? >> ( If they handle it at all.) > "normal" distributions generally don't really care which packages run > which services and if/or those are actually services. > However most modern distro's use systemd making it easier to know which > units are services, and which are so called one-shots as you can just > ask systemd. It has a lot more info about all "initscripts" which would > make this task easier. But we don't have systemd here :-) > > Also Zabbix monitoring agent for example has no built-in methods to > automatically discover available and/or running services when the > monitored distro is not running systemd. While it already does this for > decades for Windows hosts. And more recently also for systemd. > > In Suse, each package containing a service also created a link > /usr/sbin/rc<servicename> which links to the 'service' command which > currently is a wrapper script to systemd. Not sure how they did it > before systemd, possibly those rc-binaries where just symlinks to the > actual initscripts. > That is maybe something we may also need to consider, but then rather > for better user cli experience as I don't immediately see that solving > the problem you posed. > >> Another approach which comes to my mind: >> Why not parsing the root file for /etc/rc.d/init.d/ (I currently do not >> know if it is the right path)? So trying to detect which initscripts >> are part of the root file? >> > As you concluded in your other mail, not all initscripts are > services/daemons so that would probably require some hardcoded > exceptions and alike. Which is exactly what we are trying to avoid and > is currently done in services.cgi. :-) > > To tackle the problem with service-initscripts included in and > installed by the source in my approach; I currently see 2 possible > solutions: > > - also provide the old INSTALL_INITSCRIPT macro to manually install one > or more initscripts, so you are able to skip initscripts listed in > INITSCRIPTS but which are installed by the source. > > - make it a common practice to prevent the source from installing an > initscript, extracting it and installing it the IPFire way. (I think > initscript investigation is probably required anyway to make sure it is > compatible on IPFire..) I don't believe that a source automatically installing an initscript is something I have ever come across. As the package is from source then the package has limited idea on what initscript system (System V, systemd, upstart etc) is being used and what the locations for the scripts should be. The closest I have come is the bacula source file which also has a range of different startup options available which it can choose based on the distro it detects but the user has to specifically run make install-autostart in the build after make install, so it doesn't happen automatically, you have to choose to do it. So I think you shouldn't have to worry about auto installation of initscripts. Regards, Adolf. > >>> And an alternative INSTALL_INITSCRIPTS method instead of the >>> current >>> INSTALL_INITSCRIPT method. As we now have all initscripts in the >>> INITSCRIPTS macro, the INSTALL_INITSCRIPTS will install all >>> initscripts >>> listed in that macro, so a simple call to INSTALL_INITSCRIPTS will >>> now >>> do the job instead of multiple calls in case of multiple >>> initscripts >>> (for example libvirt. I noticed clamav actually uses 1 initscript >>> for >>> starting 2 services, this could maybe also be split up again) >>> I included 2 examples in the first patch: libvirt and >>> zabbix_agentd. But >>> when implemented ofcourse all makefiles should be updated. >>> >>> During the pak packaging process in the build procedure, those new >>> macro's will be inheritted in the generated pakfire meta-* files. >>> >>> The second patch adds an extra 'info <pak(s)>' commandline >>> parameter to >>> pakfire, which will in turn call a new Pakfire::pakinfo function. >>> This function wil parse the meta-* file of the requested pak and >>> functions in 2 modes: >>> - "latest" which is the behaviour of the info parameter. This will >>> display the latest available metadata of the pak and the status of >>> the pak on the system as in: is it installed?, and if so, is it >>> up-to-date. >>> - "installed" wich will display only information about the >>> currently >>> installed pak and bail out of the requested pak is not currently >>> installed. >>> This function was added to provide a 'central' point/method to get >>> pak >>> information. I don't know if there are other scripts beside >>> services.cgi >>> that currently try parsing meta-* files. But they should then be >>> changed >>> to use this function instead. >>> >>> Example output of the new pakfire info command: `pakfire info >>> zabbix_agentd`: >>> when installed and up-to-date: >>> --- >>> Name: zabbix_agentd >>> Version: 4.2.6-4 >>> Summary: Zabbix Agent >>> Size: 250.00 KB >>> Dependencies: >>> Pakfile: zabbix_agentd-4.2.6-4.ipfire >>> InitScripts: zabbix_agentd >>> Installed: Yes >>> Status: up-to-date >>> --- >>> When an update is available: >>> --- >>> Name: zabbix_agentd >>> Version: 5.0.10-5 >>> Summary: Zabbix Agent >>> Size: 276.00 KB >>> Dependencies: fping >>> Pakfile: zabbix_agentd-5.0.10-5.ipfire >>> InitScripts: zabbix_agentd >>> Installed: Yes >>> Status: outdated (version 4.2.6-4 is installed) >>> --- >>> Or when a pak was discontinued and no longer supplied by ipfire, >>> but >>> still installed on the system: >>> --- >>> Name: zabbix_agentd >>> Version: - >>> Summary: Zabbix Agent >>> Size: 250.00 KB >>> Dependencies: >>> Pakfile: zabbix_agentd-4.2.6-4.ipfire >>> InitScripts: zabbix_agentd >>> Installed: Yes >>> Status: obsolete (version 4.2.6-4 is installed) >>> --- >>> and at last when a pak is available, but not installed: >>> --- >>> Name: zabbix_agentd >>> Version: 5.0.10-5 >>> Summary: Zabbix Agent >>> Size: 276.00 KB >>> Dependencies: fping >>> Pakfile: zabbix_agentd-5.0.10-5.ipfire >>> InitScripts: zabbix_agentd >>> Installed: No >>> Status: not installed >>> --- >>> >>> And then the last patch is an update of service.cgi now using the >>> new >>> Pakfire::pakinfo function in "installed"-mode. >>> >>> If there are any suggestions on more metadata.. I think this is the >>> moment to throw them at me. >>> And ofcourse suggestions/comments are welcome as this is currently >>> only >>> a proposal for change. But I think we win in robustness of >>> services.cgi >>> and user experience in both using pakfire and ability to provide >>> available services to monitoring agents. >> Just want to say thank you for taking this way, which might be >> “harder” but yields better result from my experience. Please do not >> take my points as “this is not right”, more like “there might me >> other ways, are they better?”. >> > That is exactly why I threw this in the group; to check if there are > better idea's/approaches/things I overlooked/.. > So thank you for your constructive comments! > > Regards > Robin > >> Greetings Jonatan >>> On top of that could the whole meta-* files system be overhauled in >>> the >>> future, if wanted, with only pakfire itself needing change as the >>> rest >>> will then depend on pakfire for correctly parsing it's "database". >>> >>> >>> Regards >>> Robin >>> >>> >>> >>> -- >>> Dit bericht is gescanned op virussen en andere gevaarlijke >>> inhoud door MailScanner en lijkt schoon te zijn. >>> >