Stefan and friends,

without breaching your own security, could it be possible to see what the 
elogd.cfg file looks like, also if others would like to post theirs, this 
would be great in building exmaples etc, obviosly an security related or 
mail server entries hashed out.

I am a tad new at this stuff, but eventually would try my hand at getting 
hold of the source code and compiling on AIX and then intergrating into 
shell and error reporting. - OK .. a bit in the furture anyway, if someone 
has already done this please post.

kind regards Aamir

> Stefan and friends,
> 
> without breaching your own security, could it be possible to see what the 
> elogd.cfg file looks like, also if others would like to post theirs, this 
> would be great in building exmaples etc, obviosly an security related or 
> mail server entries hashed out.

Ok, good idea. I made a new logbook "Config Examples" on this server, where 
everybody can add new configuration examples. I added a few covering the 
logbooks on this server as a starting point. Just click on "Config Examples" 
at the top of this page!

> Stefan and friends,
> 
> without breaching your own security, could it be possible to see what the 
> elogd.cfg file looks like, also if others would like to post theirs, this 
> would be great in building exmaples etc, obviosly an security related or 
> mail server entries hashed out.
> 
> I am a tad new at this stuff, but eventually would try my hand at getting 
> hold of the source code and compiling on AIX and then intergrating into 
> shell and error reporting. - OK .. a bit in the furture anyway, if someone 
> has already done this please post.
> 
> kind regards Aamir

we do recompile a version with ShellOnsubmit and ShellParam
and it works ! actually only on windows
when all test will be finish we'll send the version to Stefan Ritt


Attributes = By, Type, Categorie, Subject, Dossier, Remarks, email1
....
ShellOnSubmit = c:\test\shellTest\Debug\shellTest.exe
ShellParam = /Params %By %Type %Subject %Dossier %Remarks % 
email1 /quietMode "test test"


 

Stefan - Just to say that this is an excellent piece of work well done.

I have just started an internal company Elog server, couple of 
clarifications :

1) is there a way around seeing the password in text when self regestering, 
if I turn this option off when the user changes his password will this 
password still be seen?

2) I have changed all the files to be owned on my RedHat Server by the 
user:group as elog:elog and set and moved the logbooks to another directory 
other than in /usr/local/elog namely /home/elog/logbooks, my concern is is 
I was to upgrade to a newer version would it be a simple install over the 
top? any caveats?

thanks again an absolute dream program.

kind regards Aamir

> Stefan - Just to say that this is an excellent piece of work well done.

Thanks.
 
> 1) is there a way around seeing the password in text when self 
regestering, 
> if I turn this option off when the user changes his password will this 
> password still be seen?

Where did you see the password? Was it on this logbook or on your own? Did 
you use "self register" equal 3 or 2? The password should never be visible 
in plain text, so after you submit it (during registration or login), the 
page gets immediately redirected since the password is contained in the 
URL. After the redirection, it is not visible any more. Now it might happen 
that the redirection takes a few seconds, depending on the network speed, 
then you see it for this few seconds. But in an intranet installation, this 
should not happen.

> 2) I have changed all the files to be owned on my RedHat Server by the 
> user:group as elog:elog and set and moved the logbooks to another 
directory 
> other than in /usr/local/elog namely /home/elog/logbooks, my concern is 
is 
> I was to upgrade to a newer version would it be a simple install over the 
> top? any caveats?

Yes, if you upgrade, the new version will again to into /usr/local/elog 
unless you tell "rpm" to relocate the package. Unfortunately I'm not a 
specialist with "rpm", but you might figure it out yourself (just try to 
reinstall the same version and look where the files go wiht "rpm -ql elog").

Hi Stefan,

I have a question concerning the Email notification in ELOG.

I have been testing various combinations of the parameters you describe in 
your documentation :

Email <attribute> <value> = <list> 
Use Email Subject = <string> 
Use Email From = <string> 
Omit Email To = 0|1 
Suppress Email to users = 0|1 

And I have encountered a problem using the Email <attribute> <value> = 
<list>. While this works fine for me when the <attribute> is of a type 
textfield, Options or ROptions, I don't seem to be able to have it working 
for the MOptions <attribute> = <list>.

The aim is to have an email notification sent only to selected people 
instead of everybody. I was hoping that this would work :

[MyLogBook]
MOptions Message_To = NB,LW,EC,MD,CD,TV,AH,TR,JS
...
...
Suppress Email to users = 1
Email Message_To TR = tomas@mba.be
Email Message_To EC = etienne@mba.be
...
...

Of course, the tricky part is that it is "multiple choice" so any 
combination of recipients is possible.

Am I missing something? 
Thanx for any ideas how to solve this,

Tomas

This problem has been fixed as well (elog:233).

Hi,
We prepared a customized theme to use with ELOG. It's called for example 
my_theme and is situated in the THEMES directory (together with the DEFAULT 
theme).

I defined the my_theme the global theme for ELOG:

[global]
Theme = my_theme

And it works fine for all the logbook in ELOG. However. The login screen 
and the main menu screen (the one with list of logbooks and # of entries) 
still takes the DEFAULT theme. 

If I change the my_theme name to default then everything works correctly 
(logon + main menu + all logbooks have the desired look).

Is the DEFAULT theme somehow hardcoded for the login screen and the main 
menu ?

Thanx for your answer

Tomas Rudolf

> Is the DEFAULT theme somehow hardcoded for the login screen and the main 
> menu ?

Yes, this was in and certainly is not correct. So I fixed it, the new code 
can be obtained vom CVS (see elog:233).

To obtain the newest source code of ELOG, go to the CVS repository at

http://midas.psi.ch/cgi-bin/cvsweb/elog/src

It contains usually the newest bug fixes, which will show up in the next 
realease. On the other hand it can also contain some new features, which 
are not yet fully tested, so care should be taken when using it. The 
revision comments usually explain what is new in that revision.

Stefan, 
We are interested in using your ELOG (which we consider to be a wonderful 
application) even more. We would like to make a few adaptations in your 
source code, above all to add some functionality that we are missing.

I was wondering if there is a way we could coordinate the development 
together. For instance, would it be of your interest to receive the code 
adaptations we do and implement it in your future releases? 

To be more specific, for the moment we are really interested in 
implementing the SHELL script execution on the server (I noticed it is in 
your wishlist).

Best regards,

Tomas Rudolf
Micro Belgium Application

> We are interested in using your ELOG (which we consider to be a wonderful 
> application) even more. We would like to make a few adaptations in your 
> source code, above all to add some functionality that we are missing.
> 
> I was wondering if there is a way we could coordinate the development 
> together. For instance, would it be of your interest to receive the code 
> adaptations we do and implement it in your future releases? 

Sure, I'm very interested in those and ready to merge it into the main 
development tree.

- Stefan

> > We are interested in using your ELOG (which we consider to be a wonderful 
> > application) even more. We would like to make a few adaptations in your 
> > source code, above all to add some functionality that we are missing.
> > 
> > I was wondering if there is a way we could coordinate the development 
> > together. For instance, would it be of your interest to receive the code 
> > adaptations we do and implement it in your future releases? 
> 
> Sure, I'm very interested in those and ready to merge it into the main 
> development tree.
> 
> - Stefan

Thanx for your quick answer.
I'll keep you updated as we move ahead with the development.
Tomas

> > We are interested in using your ELOG (which we consider to be a wonderful 
> > application) even more. We would like to make a few adaptations in your 
> > source code, above all to add some functionality that we are missing.
> > 
> > I was wondering if there is a way we could coordinate the development 
> > together. For instance, would it be of your interest to receive the code 
> > adaptations we do and implement it in your future releases? 
> 
> Sure, I'm very interested in those and ready to merge it into the main 
> development tree.
> 
> - Stefan

I think it is very good to include this in elog, but, 
since this is also a big security risk (especially if people are
running elogd as root) I would suggest a compile time option to 
enable this, like: gcc... -DALLOW_SCRIPT ...  
The default should be that it is disabled.
Maybe one should only allow it if the user running elogd is NOT root.

Heiko

Is is possible to postdate the Entry Date for an entry?

The documentation lists the ability to forward date an entry, but I don't 
see any ability to backdate an entry (edit the date to a date in the past).

Given that the entry date is part of the logbook entry file structure, it 
wasn't obvious how to make this change.

thanks

fred

> Is is possible to postdate the Entry Date for an entry?
> 
> The documentation lists the ability to forward date an entry, but I don't 
> see any ability to backdate an entry (edit the date to a date in the past).
> 
> Given that the entry date is part of the logbook entry file structure, it 
> wasn't obvious how to make this change.

The date is part of the logbook entry file structure because it's considered 
as a "stamp" which cannot be changed, so to document the real date when the 
message was written. In some installations this is very important.

If you need to change the date more freely, I would recommend to add another 
attribute which can be changed at will. Up to now this has to be a string 
variable so users have to make sure to enter the date in proper format, but 
you can prepopulate that with the current date like:

Attributes = Author, ..., Real date
Preset Real date = $date

This way the current date occurs in that field, but can be changed 
(backdated).

Note that the entry date can be changed directly in the YYMMDDa.log files in 
the data directory, if one has write access there and the elogd daemon is not 
running.

I noticed the site has been updated as far as the documentation for 2.3.1, 
however the latest version in the downloads section is 2.3.0, any other 
places where I can get 2.3.1

Cheers

> I noticed the site has been updated as far as the documentation for 2.3.1, 
> however the latest version in the downloads section is 2.3.0, any other 
> places where I can get 2.3.1
> 
> Cheers

Patience, patience! 2.3.1 is currently kind of in "beta" version, but will be 
released this week. Not that you can always get the latest snapshot from the 
CVS tree at

http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c

- Stefan