Hi,

EPEL retired the ELOG package for security reason.

You can build from GIT source as described in elog:Forum/69732 .

As SPECfile don't manage el8/9, you have to activate manually service thru "systemctl enable elogd" then "systemctl start elogd".

> EPEL retired the ELOG package for security reason

no, this is not what happened, we (I) requested removal of elog packages from epel, debian and ubuntu because they had obsolete pre-cve (insecure) 
versions that should not be used. they were very pleasant, quick and efficient dealing with this. (but obviously they could not retroactively 
remove elog from old versions of ubuntu and debian).

we opted to not reclaim ownership of these packages (original person who created these packages had drifted away) because
none of us know how to create debian packages and all of us (speaking for myself) know how much PITA is building RPM packages.
plus I do not know if Stefan has access to el8 and el9 machines (I do not, we are moving to ubuntu/debian wholesale).

I recommend building elog from git sources. it is simple, two commands (git clone + make) vs one command (rpm install),
it ensures you always have the latest version available, it is easy to update (git pull + make) and you do not
get any surprise updates (from nightly apt update/upgrade).

K.O.

> > EPEL retired the ELOG package for security reason
> 
> no, this is not what happened, we (I) requested removal of elog packages from epel, debian and ubuntu because they had obsolete pre-cve (insecure) 
> versions that should not be used. they were very pleasant, quick and efficient dealing with this. (but obviously they could not retroactively 
> remove elog from old versions of ubuntu and debian).

Yep i remind now. Finally the result was the same :-(
if CVEs had been fixed in repo, you should make a new official ELOG version and update download site with tarball, .exe and RPMS. Almost End-users do not use git repo...

> we opted to not reclaim ownership of these packages (original person who created these packages had drifted away) because
> none of us know how to create debian packages and all of us (speaking for myself) know how much PITA is building RPM packages.
> plus I do not know if Stefan has access to el8 and el9 machines (I do not, we are moving to ubuntu/debian wholesale).
 
I spent one hour yesterday to install almalinux in VM on my laptop, clone repo, rebuild ELOG RPM, install the new rpm and start elogd. 
You should have several VM on a shield for that :-P 

> I recommend building elog from git sources. it is simple, two commands (git clone + make) vs one command (rpm install),
> it ensures you always have the latest version available, it is easy to update (git pull + make) and you do not
> get any surprise updates (from nightly apt update/upgrade).

The problem of building ELOG is that it needs a development machine with C++ and dependencies installed. This is not present (or forbidden) in production machine/VM...
End users need simple package (rpm/pkg/*) to install it as all other products, with the confidence that this package has been testing...
Also, "git clone and make" should be surprising, as the devs use a particular environment that should be different from user's one. 

The future is maybe something more universal as Flatpak/SNAP/... 

Btw thanks for ELOG program and support.

Bye
Laurent

> I spent one hour yesterday to install almalinux in VM on my laptop, clone repo, rebuild ELOG RPM, install the new rpm and start elogd. 
> You should have several VM on a shield for that :-P 

Right. One hour to install linux X, another hour for linux Y. Building RPMs is a constant challenge taking lots of time. If we 
find someone who volunteers to build the RPMs and EXEs from the sources and takes over the responsibility for the next years, 
I would be more than happy to upload the resulting files. I simply don't have time for that given all my other responsibilities.

Best,
Stefan

> > I spent one hour yesterday to install almalinux in VM on my laptop, clone repo, rebuild ELOG RPM, install the new rpm and start elogd. 
> > You should have several VM on a shield for that :-P 
> 
> Right. One hour to install linux X, another hour for linux Y. Building RPMs is a constant challenge taking lots of time. If we 
> find someone who volunteers to build the RPMs and EXEs from the sources and takes over the responsibility for the next years, 
> I would be more than happy to upload the resulting files. I simply don't have time for that given all my other responsibilities.
> 
> Best,
> Stefan

Hi Stephan,

I understand your time problem. In fact, the "One hour" is the kickstart. Update is poweron VM, dnf update, git clone & rpmbuild x.y.z, then scp *.rpm to website. 10 mins. It could be scripted on your dev server if any VM manager is available from it.

You can also use automatic build plaform as COPR (https://copr.fedorainfracloud.org/) for RPM, and Bitbucket for Debian/Ubuntu (native). Bitbucket accepts OSS projects for Free.

With BitBucket, it's possible to configure personal runners for CI/CD (systems with pipeline client installed, as RHEL, Fedora, Windows, etc...). The pipeline scripts can build, test and generate the packages automatically, depend on system runners. 
As CI/CD, the process is automatically done after commits in git repo... A lot of work to make it in place, but when it's running, the delivery process is done
This is also possible with GitLab and other big platorms.

Maybe you should try. 

For my curiosity, I've just clone ELOG repo on Bitbucket to try the process. That's pity : pipelines are currently broken (incident traced in status page https://status.atlassian.com/). 
The goal is to build elog and pkg file for Ubuntu (docker images list : https://status.atlassian.com/). Next steps should to create a AlmaLinux VM to try RPM builds. 

Have nice day,
Laurent

> For my curiosity, I've just clone ELOG repo on Bitbucket to try the process. That's pity : pipelines are currently broken (incident traced in status page https://status.atlassian.com/). 
> The goal is to build elog and pkg file for Ubuntu (docker images list : https://status.atlassian.com/). Next steps should to create a AlmaLinux VM to try RPM builds. 

I fixed the bitbucket pipeline. I compiled it for an (old) GCC 6.3, and even if I installed cmake there, it was not running (maybe I needed cmake3?). Anyhow, I switched GCC 10.2 and now it's fine.

> With BitBucket, it's possible to configure personal runners for CI/CD (systems with pipeline client installed, as RHEL, Fedora, Windows, etc...). The pipeline scripts can build, test and generate the packages automatically, depend on system runners. 
> As CI/CD, the process is automatically done after commits in git repo... A lot of work to make it in place, but when it's running, the delivery process is done
> This is also possible with GitLab and other big platorms.

As you saw I use the bitbucket pipeline for CI/CD. The current bitbucket-pipelines.yml is pretty simple (see attachment). If you make me one which does the rpmbuild automatically, I'm more than happy to upload and use it. The downside there is that it only works for so long. As you saw at the 
error above, the pipeline worked a few years ago when I installed it. But in meantime things changed apparently and need to be fixed. ELOG is around since last century (literally!), and I'm kind of tired to fix things every once in a while. If somebody else could take over the responsibility to 
deliver the RPMs I would be more than delighted.

Stefan

> > "file not found" should return http code 404. elogd returns code 200 together
> > with a page containing text "404 not found". This pollutes the browser cache
> > with wrong content (in this case, we are trying to load a css file, and the browser
> > is trying to use text "404 not found" as if it were a css. bad. file not found
> > should return http code 404. K.O.
> 
> Yes. That's quite a problem when interacting with ELOG programmatically. Only way to 
> find whether response succeeded or failed with 404 is to parse response body
> 
> When file is not found send_file_direct calls show_html_header which in turn calls 
> show_http_header which sets HTTP code 200 unconditionally. It's reasonably easy to 
> patch around.

I fixed the code to properly return "404 Not Found" in case a non-existing file is requested.

Stefan

Thanks for the fix, I committed it. Please give it a quicky try sinc I cannot test it here (don't use webserver authentication...)

Stefan