Created attachment 245995 [details] Patch for revival of www/elog The attachment to this report makes possible the revival of www/elog. I volunteer to become the new maintainer. Note that the port currently has no record in the file MOVED in the ports tree.
Thank you for your submission. Here are some comments: - are the UID/GID values the same ones the port had before it was removed? If not, check if they can be made the same. - CC=c++ is our default setting, but is not correct to hard code. Ports must obey whatever value CC is set to. I recommend you change the Makefile patch to just remove any assignment to CC, CFLAGS, etc. If you do that, the Makefile should grab the right values from the environment. Failing that, you may be able to add CC=... to MAKE_ARGS. - why is the elog user needed? I don't see any file owned by it nor an rc.d script or similar? Please either remove the elog user/group or explain why it exists and how it is used. - check if @sample should be used with the configuration file you install. - move the installation steps for the documentation to target do-install-DOCS-on so they are only run when DOCS is enabled Port looks ok otherwise. Will proceed with a build test once you address these issues.
Created attachment 246912 [details] Improved patch for revival of www/elog Hi Robert, I attach a new patch trying to accommodate your points - comments follow: - are the UID/GID values the same ones the port had before it was removed? If not, check if they can be made the same. ** I was unable to find this information anywhere in the latest, expired commit @ https://svnweb.freebsd.org/ports/head/www/elog/?pathrev=366982. Is there anywhere else to look? I found this URL via freshports. - CC=c++ is our default setting, but is not correct to hard code. Ports must obey whatever value CC is set to. I recommend you change the Makefile patch to just remove any assignment to CC, CFLAGS, etc. If you do that, the Makefile should grab the right values from the environment. Failing that, you may be able to add CC=... to MAKE_ARGS. ** Should be fixed - turns out what is actually meant in the Makefile is `CXX`, not `CC`. - why is the elog user needed? I don't see any file owned by it nor an rc.d script or similar? Please either remove the elog user/group or explain why it exists and how it is used. ** elog comes with a .service file for systemd and the like, but no rc.d script. I added a file elogd.in to this new patch - please let me know if it looks ok. The elog daemon assumes a user and a group by the names of "elog" when it runs. This can be changed in the elog configuration, but it is not standard for the service. - check if @sample should be used with the configuration file you install. ** I tried doing this - does it look ok? - move the installation steps for the documentation to target do-install-DOCS-on so they are only run when DOCS is enabled ** Should be good. Thanks, Erik
I'm sorry for the delay. I'm currently not able to process bugs on account of having to update my setup to FreeBSD 14.0. Maybe someone else has time for it. Otherwise expect a response early January.
No worries - took me a while to respond to your points as well, so it is only fair!
Thank you for the update. It seems to address my previous questions. I have since found some time to review your patch: - in a recent change, the MANPREFIX variable has been eliminated. Instead use ${PREFIX}/share/man (preferred) or ${PREFIX}/man - as your port is currently set up, the daemon configured by the rc.d/elog file runs as root, not the elog user you added. Is this intentional? Try setting elog_user and elog_group in the script to run the daemon with the given user. It could also be that your daemon changes the user on its own, I didn't check. - all the files in WWWDIR are owned by elog. This means that if your daemon runs as that user, all these files are writable by the daemon. This can be a security problem: if an attacker manages to compromise the elog daemon, he can persist himself by infecting these files. Unless files need to be written by the elog daemon, it is generally a good idea to give them to root:wheel as usual. Only give files and directories to elog:elog if they need to be written by the daemon. It is usually best to lay out files such that paths with daemon-writable files and those without are clearly separated. - check if you can place the configuration file in ${PREFIX}/etc as is convention. There can be exceptions, but it's usually better to have the configuration in the usual places. - your port installs a server key pair. This is usually wrong: each installation needs its own key pair, so the pair can't be shipped in the binary package. Many daemons can be configured to generate a key pair on first start if none exists. Check if that would do the trick. Alternatively, add a post-install script or some magic to the rc.d script to generate the key pair after installation.
Created attachment 252114 [details] Refined patch for revival of www/elog Hello Robert, I finally found some time to return to working on the revival of this port. I attach a new patch, addressing the issues which you pointed out some time ago. Specifically, - man-pathing in pkg-plist has been fixed - elog_user and elog_group have been added to the rc script - elog:elog ownership is now restricted to ${PREFIX}/etc/elogd.cfg, ${WWWDIR}/{logbooks,ssl} - the config file has been placed in ${PREFIX}/etc - private key and certificate is now generated by the rc script, if they are absent Cheers!
I apologise for the long delay without any progress. I took a break from ports work as I had a bunch of other stuff on my table. UID and GID 346 have been allocated in the meanwhile, I've picked 364/364 instead. Is there any particular reason why the elog program is in libexec? It looks like it is supposed to be user-accessible and should thus go into bin. The same applies to the elconv program. libexec is for programs that should not be executed by the user, but are rather for internal use by your package. I'll move both to bin unless you object. Port looks fine and will be committed with my next batch if there are no objections on your part.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=334b84977f4b42edb5115125c8d242e629f6df8c commit 334b84977f4b42edb5115125c8d242e629f6df8c Author: Erik Jensen <erik@tenku.dk> AuthorDate: 2024-09-11 15:39:53 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2024-09-16 20:14:20 +0000 www/elog: Fast and lightweight, customizable weblog The Electronic Logbook (ELOG) provides a Web interface to manage notes. Its general purpose is to make it easy for people to put and access information online; in the form of short, time stamped text messages with optional HTML markup for presentation, and optional file attachments. WWW: https://elog.psi.ch/elog/ PR: 274813 GIDs | 2 +- UIDs | 2 +- www/Makefile | 1 + www/elog/Makefile (new) | 38 ++ www/elog/distinfo (new) | 3 + www/elog/files/elogd.in (new) | 50 +++ www/elog/files/patch-Makefile (new) | 55 +++ www/elog/pkg-descr (new) | 5 + www/elog/pkg-plist (new) | 706 ++++++++++++++++++++++++++++++++++++ 9 files changed, 860 insertions(+), 2 deletions(-)
Thank you for the submission.
I was on the fence about placing those two executables in libexec or bin, but a user who knows what they are doing might want to use either of the two, so I agree with the change. Thank you very much for the feedback. Cheers!