It is the default. If you install ELOG on your PC and run it, then every access will be directly to the ELOG web service. If you want to have Apache inbetween, it is some extra effort.

I am no Windows expert. An option is to write your own application and use the "elog" command to post the output of the application to your ELOG.
There is as well a python library to access ELOG via http: https://github.com/paulscherrerinstitute/py_elog

Now you've totally lost me.

elogd is a web service. You connect to it with a web browser. You don't pass arguments at startup of the service that refers to specific atrributes. I have no idea what you intend to do, you need to explain a lot more.

 
> it would be good if the current state was listed in https://elog.psi.ch/elogs/Vulnerabilities/ 
> It seems there's now updated builds for at least windows, and the debian package still outdated?
> 
> Personally, I don't think removing download links and pulling packages should be more than a temporary measure.
> Treating people fairly IMHO means they should be able to reach a safe version by the same means that brought and left them exposed.
> 
> A clear central source would be best, one that has 
> 
> - package autobuilds
> - source
> - cve list
> 
> If I understand correctly, currently only the source is up to date?
> 
> 
> (I found py_elog on Github, so it could be an easy option to mirror ELOG there and let some free service handle the autobuilds.
> I don't know how well one can flag vulnerabilities there, but likely it's possible, and ideally more people would help there.)
> 
> 
> p.s.: My hat is off to the sysadmin who checked carefully, I wanted to introduce ELOG in a windows-centric place and I can't swear I would have checked this (official) download as well.

Very good ideas! Go ahead and implement them! We very much appreciate your contribution.

We have 68 logbooks and currently 60 GB data total. We run it as well on a VM, in our case with 8GB RAM.
The speed of ELOG is mostly given by the filesystem: when we had AFS it was very slow. With NFS it was better. But we now use a local disk on the VM: that is much better.
If you want to have the best performance (upload of large files can still slow down all users) then I would recomment local SSD for the file system of elogd.

You might talk to your system administrator: they can likely provide a local SSD on the VM server host.

It looks to me like only an author of an article can contradict a deletion. I did not find a single method to even comment on the deletion.
I am not an Wikipedia expert, can anyone suggest on how to push for the article to be restored? Or do we just write it again, until people stop deleting it?

It appears to me that this is a really stupid problem: the article provides many links to sources, but they are just links, not "references". That does not count, since links could be something else than references.

I'll try to edit it and transform the list of external links into references to verify the text. Lets hope that this will suffice.

Okay: found three articles about applications of ELOG and put them under references. I took the liberty to submit the draft: it shows that they expect some month delay for a review. I have no idea if that was what they want, but it is worth a try.

I do run elog under:

But that does not change the location of my certificates: they are in "/usr/local/elog/ssl".
My guess: you just copied the .pem file to the /ssl directory, but did not rename it to server.crt?
And of course you need to overwrite server.key as well.

Kind Regards
Andreas