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

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

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

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.

Hi,

right now I'm testing Elog to use it as a task/todo-log for our small 
workgroup. What I saw so far looks very nice and I like it very much. 
Thanks for the good work.

Playing with all the configuration possibilities I have one issue:
I like to use the "Extendable options" but I can't combine them with 
the "Conditional attributes".

-- snip

Options Area = Area_1{1}, Area_2{2}, Area_51{3}
{1} Options Ressort = Res01, Res whatever, end so on
{2} Options Ressort = somthing else, fill in
{3} Options Ressort = Alien observation, Budget planning
Extendable options = Ressort

-- snip

The "Conditinal Attributes" do have the "Add Ressort" button and the elog-
entry is written with this new attribute. But the new attribute is not 
inserted into the config file.

Long time ago I last read C syntax but mabye the function 
add_attribute_option should take care of the prefix {n} in extendable 
options?

Or do I miss something in the configuration syntax? 

  Regards,

  David

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.

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

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