I solved it.
I don't really know if I really needed to compile it but I complied this on the NAS itself so now it is 100% compatible (I believe)

Per

 I managed to package Elog v2.92 build 2462 into and QNAP installer QPKG package.

This is for x86 based QNAP NAS only.

Note: You must have adduser package installed prior to installation.
Login to the NAS with SSH and type:
apt-get update
apt-get install adduser

BR,

Per

Ubuntu LTS 20.04 and others have elog PDF preview disabled by default. To enable,
please follow these steps, see https://daq00.triumf.ca/DaqWiki/index.php/Ubuntu#Enable_elog_PDF_preview

Enable elog PDF preview
see https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion

xemacs -nw /etc/ImageMagick-6/policy.xml
remove this section at the end:
<!-- disable ghostscript format types -->
<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="PS2" />
<policy domain="coder" rights="none" pattern="PS3" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />

K.O.

I think what you want already exists, for example, when I reply to this message, there is this "Category" selection box with predefined answers 
"Info", "Bug report", etc. For your case, replace "Category" with "Wafer type ID", replace "Info" with "1", "Bug report" with "2", etc. You numeric 
values will be strings containing numbers "1", "2", etc. That works for you? K.O.

Please tell me how to share my elog with people.

> > > In order to avoid having to remember multiple usernames/passwords for
> > > different systems, is it possible for ELOG to use external authentication
> > > via Active Directory, etc?
> > 
> > Not yet.
> 
> I would note that this is a request that comes in fairly frequently, but to
> Stephan's credit (and looking back at previous comments) the task of trying to
> implement authentication that would *not* be a maintenance nightmare basically
> pushes such a request down to the bottom of the list.
> 
> The only common denominator that could possibly cover all contingencies would
> be LDAP authentication.  One way of doing this in a more-or-less universal
> fashion is to offload the auth task from eLog itself and place the burden on
> Apache.  This means figuring out how to get Apache to pass auth info to eLog
> when eLog operates behind Apache.  In the end, anything that can use LDAP as an
> authentication mechanism (like AD) can host eLog - as long as eLog can glom off
> of Apache's ability to do the actual authenticating.  
> 
> For our twiki (source from twiki.org) website, we use the following config:
> 
> -- In Apache http.conf
> LoadModule auth_ldap_module   libexec/auth_ldap.so
> 
> AddModule auth_ldap.c
> 
> AccessFileName .htaccess
> 
> # Twiki
> Include /proj/www/twiki/conf/httpd.conf
> 
> 
> -- The http.conf in the Twiki directory
> <VirtualHost *>
>         DocumentRoot "/proj/www/twiki/html"
>         ServerName twiki
>         ErrorLog error_log
>         CustomLog access_log combined
>         <Directory "/proj/www/twiki/html/bin/">
>                 Options +ExecCGI
>                 allow from all
>                 AllowOverride Authconfig FileInfo Indexes Limit Options
>         </Directory>
>         <Location /bin>
>                 Options +ExecCGI
>                 AuthType Basic
>                 AuthName CoreID
>         CustomLog access_log combined
>         <Directory "/proj/www/twiki/html/bin/">
>                 Options +ExecCGI
>                 allow from all
>                 AllowOverride Authconfig FileInfo Indexes Limit Options
>         </Directory>
>         <Location /bin>
>                 Options +ExecCGI
>                 AuthType Basic
>                 AuthName ID
>                 AuthLDAPURL
> ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
>                 require valid-user
>                 allow from all
>                 <Limit OPTIONS>
>                         Order Deny,Allow
>                         Deny from all
>                 </LIMIT>
>         </Location>
> </VirtualHost>
> 
> --- Then the DocumentRoot ("/proj/www/twiki/html") has a '.htaccess' file with
> the following:
> 
> RedirectPermenant       /       http://twiki.co.com/bin/view.cgi
> 
> --- Also in the /bin directory we have:
> 
> Redirect http://twiki.sps.mot.com/index.html http://twiki.sps.mot.com/bin/view.cgi
> 
> AuthType                 Basic
> AuthName                 "LDAP Login"
> AuthLDAPURL
> ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
> 
> 
> SetHandler cgi-script
> 
> ErrorDocument 401 /bin/oops.cgi/TWiki/TWikiRegistration?template=oopsauth
> 
> <Files ~ "[^/]*\.html$">
>        SetHandler blabla
>        allow from all
> </Files>
> 
> <Files "*">
>        require valid-user
>         allow from all
> </Files>
> -------------------------
> 
> Whether this is at all relevant, well . . . . 

Food for thought--thanks!

Can you consider implementing the following additions to the functionality

1) Subt on edit <attribute> = xyz 

This would be fantastic for implementing version control so you can see who 
has edited a posted or a db entry.

2) Have a SORT fieldname flag so you can decide which column to sort things 
by on a display listing in conjunction to the display flags, it current 
defaults to the # column and I find i am directly linking to a sorted 
display

3) Have the elogd.conf track actual log entries people have changed 
detailing date and time etc.

4) Ability to export contents of the log books to files on disk for backup 
purposes as all data is contained within a single log file which causes 
problem for command line searches.


Many thanks 

I suspect that this might be a Debian packaging issue; however no one replied to my help request on the Debian forums so I try posting the question also here. I insatlled Elog on my Debian Jessie machine, I can open it with a browser but when entering a new post just a simple plain text editing box is shown instead of the WYSIWYG editor, and no drag and drop area for attachments is shown. When I start the elog service with "systemctl start elog" I get this suspect message in the journal: "FCKedit NOT detected". Indeed, I see that the elog installation creates a symlink which I guess is supposed to point to the fckeditor installation, which nevertheless is missing:

root@static-3-080:/usr/share/elog/scripts# ll fckeditor
lrwxrwxrwx 1 root root 15 Oct 25  2014 fckeditor -> ../../fckeditor
root@static-3-080:/usr/share/elog/scripts# ll ../../fckeditor
ls: cannot access ../../fckeditor: No such file or directory

Is this a Deban misconfiguration or a bug in Elog? thanks