Dear Friends,

Anyone managed to compile elog on AIX 5.2 or 5.1 ... is there a binary 
anywhere?

new to "C"

kind regards Aamir

I hope this is not something I did. 

I'm using elog 2.3.1 on redhat 7.1 and using stunnel to redirect from port
443 to 8080. When I try to add a new record (click submit) https:// in the
browser gets changed to http://. I ve tried three browsers all with the same
result. If I go into the address field and change it to https:// after
getting a 404 error it works. The record gets posted.

> I hope this is not something I did. 
> 
> I'm using elog 2.3.1 on redhat 7.1 and using stunnel to redirect from port
> 443 to 8080. When I try to add a new record (click submit) https:// in the
> browser gets changed to http://. I ve tried three browsers all with the same
> result. If I go into the address field and change it to https:// after
> getting a 404 error it works. The record gets posted.

Just an update: It does the same thing when I click the back button

> > I'm using elog 2.3.1 on redhat 7.1 and using stunnel to redirect from port
> > 443 to 8080. When I try to add a new record (click submit) https:// in the
> > browser gets changed to http://. I ve tried three browsers all with the 
same
> > result. If I go into the address field and change it to https:// after
> > getting a 404 error it works. The record gets posted.

This is due to a change we had to do in the redirection of the pages. If you 
submit a page, the result is a redirection using the HTTP 
statement "Location: ..." inside the header. While this was a relative link 
in the previous versions, we changed this into an absolute link, which then 
agrees with the standard. But since elgod does not know if it runs 
under "http:" or "https:", you have now to add the line

URL = https://your.server:port

into elogd.cfg. I will add this note into the documentation.

- Stefan

Operator error. Figures!

Elog has worked fine for a log time then I upgraded and added stunnel at the
same time. A case of not seeing the forest for the trees.

Thanks for the help.


> > > I'm using elog 2.3.1 on redhat 7.1 and using stunnel to redirect from port
> > > 443 to 8080. When I try to add a new record (click submit) https:// in the
> > > browser gets changed to http://. I ve tried three browsers all with the 
> same
> > > result. If I go into the address field and change it to https:// after
> > > getting a 404 error it works. The record gets posted.
> 
> This is due to a change we had to do in the redirection of the pages. If you 
> submit a page, the result is a redirection using the HTTP 
> statement "Location: ..." inside the header. While this was a relative link 
> in the previous versions, we changed this into an absolute link, which then 
> agrees with the standard. But since elgod does not know if it runs 
> under "http:" or "https:", you have now to add the line
> 
> URL = https://your.server:port
> 
> into elogd.cfg. I will add this note into the documentation.
> 
> - Stefan

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