Could you implemet and option 'admin menu' which gets displayed
when an 'admin' is logged in.  This menu could e.g. also include 'Delete'
while the normal menu would not.

> Could you implemet and option 'admin menu' which gets displayed
> when an 'admin' is logged in.  This menu could e.g. also include 'Delete'
> while the normal menu would not.

You can achieve the same via

Allow delete = <admin name>

I have a computer that has a different idea of its name from the DNS 
server. When I run ELOG and someone clicks "Search" I get a page not found.
I tried starting with "-n <hostname>", but elog still uses gethostname.
The example is that DNS says my machine is "abc.company.com" and netstat -
a says elog is listening on 8080 abc.personaldomain.com

Here is the code from elogd.c:

   /* get host name for mail notification */
   gethostname(host_name, sizeof(host_name));
   phe = gethostbyname(host_name);
   if (phe != NULL)
      phe = gethostbyaddr(phe->h_addr, sizeof(int), AF_INET);
   /* if domain name is not in host name, hope to get it from phe */
   if (strchr(host_name, '.') == NULL && phe != NULL)
      strcpy(host_name, phe->h_name);

I think you should be using tcp_hostname instead of gethostname if it is 
specified.

> I think you should be using tcp_hostname instead of gethostname if it is 
> specified.

Sorry my late reply, I was ill for some time. I implemented your suggestion in
revision 1.522 which is available from CVS.

Note that there is also the "URL = xxx" option in the configuration file which
lets you specify the whole URL including the host name.

know that illness...  :-(  but was the last of the family of 4 people

i'd like to ask for an other usefull change togehter with this and how url's are 
handled by elog:

since there may be spaces in the name of a logbook (ex. "1stWordOfLogbook 
2ndWordOfLogbook") it is very userfriendly to name logbooks. also it's easy th 
make a reference for a other entry by copy and paste:

Display ThisURL = http://localhost:8080/$logbook/$message id

however, using spaces in the logbook name may give a wrong result, because the 
url would be http://localhost:8080/1stWordOfLogbook

and the space as well as the 2ndWordOfLogbook//$message id is only normal text.

may it be possible stefan, to replace the space in an url (starting 
with "http://") with a "+" or "%20"? this would allow to automate some things. 
actual the logbook name has to be hardcoded.


> > I think you should be using tcp_hostname instead of gethostname if it is 
> > specified.
> 
> Sorry my late reply, I was ill for some time. I implemented your suggestion in
> revision 1.522 which is available from CVS.
> 
> Note that there is also the "URL = xxx" option in the configuration file which
> lets you specify the whole URL including the host name.

Ok, I changed that in version 2.5.5-3. Note that one can also use the "elog:..."
substitution, like

Display ThisURL = elog:$logbook/$message id

hello, 

i need to use a perl script with LWP to automatically update our elog
entries. we use ELOG internally.

however, I am not sure what elog checks for when doing the post through
form. and the auto-submit script always failed and returns "200 EOF". i can
get to the login part and grab form entry. its only the submittion failed.

let me know if you need more info to help me solve the problem.

thanks.


QiAng

> however, I am not sure what elog checks for when doing the post through
> form. and the auto-submit script always failed and returns "200 EOF". i can
> get to the login part and grab form entry. its only the submittion failed.

What you can do is run the elog submit utility with the "-v" flag (verbose) and
grap the output. It's HTML code, but you should see any error message there.

I happened to find something interesting when trying my perl script. it hangs the
elog system with hand-crafted http header.

I also sent email with more detail on this. just want to make sure you are aware of
this.

Qiang

> > however, I am not sure what elog checks for when doing the post through
> > form. and the auto-submit script always failed and returns "200 EOF". i can
> > get to the login part and grab form entry. its only the submittion failed.
> 
> What you can do is run the elog submit utility with the "-v" flag (verbose) and
> grap the output. It's HTML code, but you should see any error message there.

> I happened to find something interesting when trying my perl script. it hangs the
> elog system with hand-crafted http header.

This bug has been fixed in revision 1.524 of elogd.c available from CVS.

I just submitted a reply to elog:847 (the reply is elog:853).
Normally the thead containing the reply should now be listed as
the top thread.  Instead only the original message of the thread
(elog:820) is listed but the remaining messages in the thread are not 
listed.  It seems the problem is that for elog:820 the 'reply to this'
header is missing.  And elog:820 and elog:824 are the same messages
except that for elog:824 the subject is missing.  Actually ALL attributes
for elog:824 are missing.

I guess you could fix things up if you:
- add 'reply to this: 823' to elog:820
- remove entry elog:824

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.

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

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

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

That sounds to me like a great idea. If anybody gets this working, people would be
grateful if this could be submitted to the "Contributions" section of this forum.

> > 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.  
> 
> That sounds to me like a great idea. If anybody gets this working, people would be
> grateful if this could be submitted to the "Contributions" section of this forum.

Ah, you test me!  Perhaps I will attempt to dig into this but I may have to leave the
integration up to you, Stefan.  Seems that there would be two roads to go:
1> Move away from standalone and start to rely on Apache
2> Continue with the standalone theme and build in LDAP authentication (which could
also give you groups functions as well). 

I think I would opt for <2>

> Ah, you test me!  Perhaps I will attempt to dig into this but I may have to leave the
> integration up to you, Stefan.  Seems that there would be two roads to go:
> 1> Move away from standalone and start to rely on Apache
> 2> Continue with the standalone theme and build in LDAP authentication (which could
> also give you groups functions as well). 
> 
> I think I would opt for <2>

<1> would only make sense if the functionality could be completely implemented inside
Apache, without (much) modification of elog. Otherwise I agree that <2> would be more
following the general lines of elog. I was considering to implement PAM (pluggable
authorization module) support into elog, which is quite easy to implement and gives you
to power of having LDAP, Kerberos, Unix username, Windows NT Domain and much more. But
that would them be restricted to elog running under Linux (and Solaris I guess), since
I'm not aware of a PAM implementation under Windows.

Implementing LDAP directly into elog gives me the problem that we don't use LDAP
authentication at our institute (it's Kerberos in fact). So I would have to set up my own
LDAP server for testing, plus we at our institute don't have a direct benefit from that,
which would make it hard for me to justify to spend time on.

> > Ah, you test me!  Perhaps I will attempt to dig into this but I may have to leave the
> > integration up to you, Stefan.  Seems that there would be two roads to go:
> > 1> Move away from standalone and start to rely on Apache
> > 2> Continue with the standalone theme and build in LDAP authentication (which could
> > also give you groups functions as well). 
> > 
> > I think I would opt for <2>
> 
> <1> would only make sense if the functionality could be completely implemented inside
> Apache, without (much) modification of elog. Otherwise I agree that <2> would be more
> following the general lines of elog. I was considering to implement PAM (pluggable
> authorization module) support into elog, which is quite easy to implement and gives you
> to power of having LDAP, Kerberos, Unix username, Windows NT Domain and much more. But
> that would them be restricted to elog running under Linux (and Solaris I guess), since
> I'm not aware of a PAM implementation under Windows.
> 
> Implementing LDAP directly into elog gives me the problem that we don't use LDAP
> authentication at our institute (it's Kerberos in fact). So I would have to set up my own
> LDAP server for testing, plus we at our institute don't have a direct benefit from that,
> which would make it hard for me to justify to spend time on.


Yes, PAM is highly dependent upon Unix and PAM would work under Solaris just fine.  Your
problem lies with Windows - hence my LDAP suggestion.

And LDAP isn't an easy thing to setup, but I bet there is a quick and dirty "test" bench that
could be rigged using OpenLDAP.  Like I indicated, I'll see what I can dig up on this front -
but I make no promises wrt delivery time!

Hi all,

We currently have Elog postings mirrored on to a majordomo email list. 
Invariably, people on this list reply to the listserv and not to the Elog. 
Has anyone tried getting emails to a listserv to autoformat and register as
proper elog entries.  Didn't see any mention of this in the docs or forums.

Thx 

> We currently have Elog postings mirrored on to a majordomo email list. 
> Invariably, people on this list reply to the listserv and not to the Elog. 
> Has anyone tried getting emails to a listserv to autoformat and register as
> proper elog entries.  Didn't see any mention of this in the docs or forums.

I personally use Elog *instead* a majordomo email list. You can either specify
a email list in the elogd.cfg file, or you can keep a list of users in the
password file with automatic email notifications, that's how this forum works
for example. But I don't know if you can give up your majordomo list.

Right. Number of options is limited to 100.

> Right. Number of options is limited to 100.
hi, i found the MAX_N_LIST macro and increased it

> > Right. Number of options is limited to 100.
> hi, i found the MAX_N_LIST macro and increased it

Please note that if you make it too big, you will get a stack overflow and
elogd will crash.

hi
the back button/liunk does not work
if i click on an entry and then back, it does not work properly, i see the 
same entry
if i click on the new button or the find button,  and then back, it does 
not work properly
mfg guenter

> hi
> the back button/liunk does not work
> if i click on an entry and then back, it does not work properly, i see the 
> same entry
> if i click on the new button or the find button,  and then back, it does 
> not work properly
> mfg guenter

Thanks for reporting that bug, it has been fixed in the curreny CVS version.

> > hi
> > the back button/liunk does not work
> > if i click on an entry and then back, it does not work properly, i see the 
> > same entry
> > if i click on the new button or the find button,  and then back, it does 
> > not work properly
> > mfg guenter
> 
> Thanks for reporting that bug, it has been fixed in the curreny CVS version.

thanks