From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: [PATCH 0/3] Pakfile metadata enhancements Date: Sat, 15 May 2021 14:10:56 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3231223169276597435==" List-Id: --===============3231223169276597435== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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(a)disroot.org>: >>> >>> =EF=BB=BFHi 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.=C2=A0 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 >>> =C2=A0package. >> 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 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 somet= hing 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) i= s 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 d= ifferent 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 b= uild after make install, so it doesn't happen automatically, you have to choo= se 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 ' 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 >>> =C2=A0display the latest available metadata of the pak and the status of >>> =C2=A0the pak on the system as in: is it installed?, and if so, is it >>> =C2=A0up-to-date. >>> - "installed" wich will display only information about the >>> currently >>> =C2=A0installed pak and bail out of the requested pak is not currently >>> =C2=A0installed. >>> 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 >> =E2=80=9Charder=E2=80=9D but yields better result from my experience. Plea= se do not >> take my points as =E2=80=9Cthis is not right=E2=80=9D, more like =E2=80=9C= there might me >> other ways, are they better?=E2=80=9D. >> > 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 >>> >>> >>> >>> --=20 >>> Dit bericht is gescanned op virussen en andere gevaarlijke >>> inhoud door MailScanner en lijkt schoon te zijn. >>> > --===============3231223169276597435==--