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?

Thanks,
Steve

> > > 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!

How can I exclude the access of a number of users in one (out of two) logbooks running in the same server and URL?

Hi,

As mentionned before, we happen to fail to receive email messages related to updates on elog entries at our site. My understanding is that the SMTP header Message-Id MUST be unique for each email message. Whereas all elogd email messages get something like <logbook>-<entryId>@<domain>. See source code. For this header to become unique, there should be a random part in it.

Having the same Message-Id in multiple email messages results in only the first one being delivered on some email systems.

Moreover, elogd sets the In-Reply-To: header in the same manner (<logbook>-<entryId>@<domain>). Which is incorrect because this header relates to email messages, not elog entries, and should contain the email Message-Id of the email message to which it replies, itself handled by the email messaing system. But elogd hasn't received any email messsage in the first place. So I believe this header should simply be dropped.

I think I can provide a pull request on bitbucket for the Message-Id issue, and probably also for the In-Reply-To: if you decide it can be removed.

Cheers

Pull-request posted. Cheers.

I attempted to install the newest version of elog on our site elog server from an old old version.  Around 2008 I believe.  I then received an application failed to initialize properly 0xc0150002 after installing the newest version.  I then tried installing the Feb 2013 version and received the same message.  Panicked, I rolled back our server to its state yesterday.  I would like to update our elog software, anyone know why I am receiving this error??

Andreas Luedeke wrote:

Norm wrote: I attempted to install the newest version of elog on our site elog server from an old old version.  Around 2008 I believe.  I then received an application failed to initialize properly 0xc0150002 after installing the newest version.  I then tried installing the Feb 2013 version and received the same message.  Panicked, I rolled back our server to its state yesterday.  I would like to update our elog software, anyone know why I am receiving this error??  Hi Norm. I have not much experience with windows, but I can give you my two cent on how to proceed: Check the old elogd version. It is shown at the bottom of your elog web page (this forum shows ELOG V2.9.2-2475). Copy your logbook data to a different PC, maybe your office PC. Then compile the latest elog on your office PC, run it with the copied data and access it as http://localhost:8080 (or whatever port number you are using) If it is still crashing: re-compile it using "make debug" and run it from a debugger (I don't know any C-debugger for Windows). Post the precise error message.   Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English   Good luck!

 Thanks for the reply.  I just got back from a business trip and I will try this ASAP.  Thanks and I will be posting the error message.