Hello friends, 

Exist some form to increase limits of items (100) in the Options List



Thanks for any help

> Hello friends, 
> 
> Exist some form to increase limits of items (100) in the Options List
> 
> 
> 
> Thanks for any help

I believe only through an edit of the C code and a recompile, as the values
are set as constants.  I think this might be the line:

#define MAX_N_LIST      100

So, yes, there exists a way and the ease of this way is dependent upon your
comfort level with changing stefan's code.

> > Hello friends, 
> > 
> > Exist some form to increase limits of items (100) in the Options List
> > 
> > 
> > 
> > Thanks for any help
> 
> I believe only through an edit of the C code and a recompile, as the values
> are set as constants.  I think this might be the line:
> 
> #define MAX_N_LIST      100
> 
> So, yes, there exists a way and the ease of this way is dependent upon your
> comfort level with changing stefan's code.

Agree. The only potential problem is that if this value becomes too big, you
will get a stack overflow from time to time. So best is experiment yourself a
bit. A avlue of 150 or so should be no problem.

- Stefan

At some point, in the last week or so, I upgraded the debian-unstable
version (r1459-1) of elog.  Now, PostScript files (as attachments) are
displayed (shown in ascii text, instead of just showing the link).  

Is there an option in the elog.cfg to only display certain files (like .gif
or .jpg).

At some point, in the last week or so, I upgraded the debian-unstable
version (r1459-1) of elog.  Now, PostScript files (as attachments) are
displayed (shown in ascii text, instead of just showing the link).  

Is there an option in the elog.cfg to only display certain files (like .gif
or .jpg).

I'm not sure if this is a configuration problem or a bug, but running
v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
is in the elogd.cfd file:

Usr = nobody
Grp = essadm

All other directives added to the cfg file work, so I know eLog is reading
the cfg file.  

The elogd binary *is not* setuid 0.

Thanks

> I'm not sure if this is a configuration problem or a bug, but running
> v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
> is in the elogd.cfd file:
> 
> Usr = nobody
> Grp = essadm
> 
> All other directives added to the cfg file work, so I know eLog is reading
> the cfg file.  
> 
> The elogd binary *is not* setuid 0.

I could not reproduce your problem with the current version (Revision 1.460)
under Linux. I guess you made sure that user "nobody" and group "essadm" exist.
Try to run elogd interactively, if you see any error message (without "-D"
flag). In the most recent version (1.460), I added some more debugging code
which tells you if elogd successfully fell back to another user, if you use the
"-v" (verbose) flag.

If all that does not help, I guess it's some peculiarity of Solaris. Maybe
someone else using Solaris has some idea. All elogd does is a call to 

setuser("<user>");

I see no reason why this should not work on Solaris.

> > I'm not sure if this is a configuration problem or a bug, but running
> > v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
> > is in the elogd.cfd file:
> > 
> > Usr = nobody
> > Grp = essadm
> > 
> > All other directives added to the cfg file work, so I know eLog is reading
> > the cfg file.  
> > 
> > The elogd binary *is not* setuid 0.
> 
> I could not reproduce your problem with the current version (Revision 1.460)
> under Linux. I guess you made sure that user "nobody" and group "essadm" exist.
> Try to run elogd interactively, if you see any error message (without "-D"
> flag). In the most recent version (1.460), I added some more debugging code
> which tells you if elogd successfully fell back to another user, if you use the
> "-v" (verbose) flag.
> 
> If all that does not help, I guess it's some peculiarity of Solaris. Maybe
> someone else using Solaris has some idea. All elogd does is a call to 
> 
> setuser("<user>");
> 
> I see no reason why this should not work on Solaris.

Ok, just checking.  I will fiddle around with running it interactively and see what
I get, plus I'll have a look at the setuser function under Solaris.

Just for grins, what version of compiler are you using under Linux?

Thanks again!

> Just for grins, what version of compiler are you using under Linux?

gcc 3.2.2 (from RedHat Linux 9.0)

> > Just for grins, what version of compiler are you using under Linux?
> 
> gcc 3.2.2 (from RedHat Linux 9.0)

Well, I am running 2.95.3 - hmmm.  We have 3.3.2 - perhaps I'll try that and
see if there is a difference.

I am working on a logbook for a lab.  I have two questions...
First - Some of the logbook entries should not be viewed by certain users.  
What would be the easiest way to restrict viewing some entries?  

Second - I have a welcome page for the ELOG that lists some info about the 
ELOG.  When I start the ELOG, the user sees the login page.  After the user 
logs in, the welcome page appears listing the restrictions.  Right now, I 
have a hyperlink that takes the user to new, find, etc.  But I would like 
to take the user right to the logbook and not have to come back to the 
welcome page everytime.  How can I do this?

I have attached the code I have so far.  They are in .txt format for easier 
viewing.

Thanks!

> First - Some of the logbook entries should not be viewed by certain users.  
> What would be the easiest way to restrict viewing some entries?  

The easiest way is to define two logbooks, with two different password files.
The more restricted logbook contains only those users who are allowed to see the
restricted entries. Use the commands "Move to" to move entries between the two
logbooks (see documentation).

> Second - I have a welcome page for the ELOG that lists some info about the 
> ELOG.  When I start the ELOG, the user sees the login page.  After the user 
> logs in, the welcome page appears listing the restrictions.  Right now, I 
> have a hyperlink that takes the user to new, find, etc.  But I would like 
> to take the user right to the logbook and not have to come back to the 
> welcome page everytime.  How can I do this?

Right now you need an exteral page on a public webserver. This page contains
then links to your elog server. I the next version I will implement the
possibility to server *.html files directly through elog. You can then put your
welcome page under themes/default/Welcome.html, and access it through the
starting link:

http://your.elog.server/logbook/Welcome.html

You will only see the Welcome page once, since all links in elog will point back
to .../logbook/ and not to .../logbook/Welcome.html. The config option "Welcome
page = Welcome.html" you have to remove then of course. 

I was trying to do some hard coded spaces using:

Thread display = For: $Date for Shutdown.   $DataCenter:
$short summary. Coordinator: $Shutdown Coordinator.

The spacing actually works mthe first time, but upon going back into editing
the config file, the coded spaces are gone, replaced with real spaces, and
when saved all real multiple spaces are, as one would expect, ignored.  The
spacing reverts back to normal.

I tried other html tags but these show up as literals.

Thanks

> I was trying to do some hard coded spaces using:
> 
> Thread display = For: $Date for Shutdown.   $DataCenter:
> $short summary. Coordinator: $Shutdown Coordinator.
> 
> The spacing actually works mthe first time, but upon going back into editing
> the config file, the coded spaces are gone, replaced with real spaces, and
> when saved all real multiple spaces are, as one would expect, ignored.  The
> spacing reverts back to normal.
> 
> I tried other html tags but these show up as literals.

I fixed that in revision 1.448. The problem also showed up even in normal
logbook entry displays and in replies (before this fix, the   in this text
whould not have shown up). Get the new version from CVS.

> > I was trying to do some hard coded spaces using:
> > 
> > Thread display = For: $Date for Shutdown.   $DataCenter:
> > $short summary. Coordinator: $Shutdown Coordinator.
> > 
> > The spacing actually works mthe first time, but upon going back into editing
> > the config file, the coded spaces are gone, replaced with real spaces, and
> > when saved all real multiple spaces are, as one would expect, ignored.  The
> > spacing reverts back to normal.
> > 
> > I tried other html tags but these show up as literals.
> 
> I fixed that in revision 1.448. The problem also showed up even in normal
> logbook entry displays and in replies (before this fix, the   in this text
> whould not have shown up). Get the new version from CVS.

As always - fantastic!

Thanks

Hi everybody,

several people have reported of strange problems concering the login/logout
behaviour of elog. After editing elogd.cfg, they could not logout any more
from a logbook, or they were not able to log in. Here comes some
explanation. If you are not interested in the details, skip to the last section.

The login parameters (user name and password) are sored in cookies, which of
course have to be enabled for the elog site in your browser. Each cookie can
contain an optionsl "path=..." statement, which defines for which subtree in
the URL the cookie is valid. If you use a "global" password file (one where
the "password file = ..." statement is in the [global] section of
elogd.cfg), the elogd server stores a cookie with path "/", so it will apply
to the whole site and therefore to all underlying lobooks. If your password
file is defined in an individual logbook section, the elogd server stores a
cookie with path "/<logbook>", so that it applies only to the specific logbook.

The problem arises now if one moves the password file statement from the
global section to the logbook section or back. The browser might still have
old cookies, whic can override any newly set cookie.

Long story short conclusion: If you observe this behaviour, just delete all
cookies in your browser and you should be fine. I added some additional code
to version 2.5.4 which catches a few cases but unfortunately not all.

Hello,

For some reason if I define a "login user" that is allowed the configure
option he is also allowed to change the configuration file. According to the
documentation it seems like this should NOT be the case. Any ideas as to
what the problem might be? 

Thanks in advance for any help/advice.

Ralph 

> For some reason if I define a "login user" that is allowed the configure
> option he is also allowed to change the configuration file. According to the
> documentation it seems like this should NOT be the case. Any ideas as to
> what the problem might be? 

Unfortunately I cannot reproduce your problem. This leaves few possibilites:

- any login user CAN change his/her full name, email address etc. but only admin
users can change ALL OTHERS as well. Admin users should see a "change elogd.cfg"
button on the config page, whil normal users will not

- are you sure you logged out as admin user and loggin in again as non-admin
user? Under some circumstances, the browser keeps old cookies which can confuse
things. Best is if you delete all browser cookies and try again (Tools/Internet
Options/Delete Cookies in IE).

- Stefan

Hi, 
I also have this problem, when a non admin user logs in he does not have access to
the config file but if he logs out he can then access the config file as non logged
user.
I also tried to upgrade to version 2.5.3 but running under this version does not ask
for passwords so I reverted to 2.5.2.

Besides these few details, your software is great !

Thank you,

Alexandre

> > For some reason if I define a "login user" that is allowed the configure
> > option he is also allowed to change the configuration file. According to the
> > documentation it seems like this should NOT be the case. Any ideas as to
> > what the problem might be? 
> 
> Unfortunately I cannot reproduce your problem. This leaves few possibilites:
> 
> - any login user CAN change his/her full name, email address etc. but only admin
> users can change ALL OTHERS as well. Admin users should see a "change elogd.cfg"
> button on the config page, whil normal users will not
> 
> - are you sure you logged out as admin user and loggin in again as non-admin
> user? Under some circumstances, the browser keeps old cookies which can confuse
> things. Best is if you delete all browser cookies and try again (Tools/Internet
> Options/Delete Cookies in IE).
> 
> - Stefan

> I also have this problem, when a non admin user logs in he does not have access to
> the config file but if he logs out he can then access the config file as non logged
> user.

If he logs out, how can he access a logbook at all? He should be presented a login
screen, nothing else...

> I also tried to upgrade to version 2.5.3 but running under this version does not ask
> for passwords so I reverted to 2.5.2.

Better first let's fix this problem. Under what circumstances does 2.5.3 not ask for
passwords? Maybe you can get the newest version from CVS (see download page) and try
again, I had problems when using the -DHAVE_CRYPT functionality, but I guess you did not
have that, do you?

So once you tried the latest snapshot, and still have problems, describe them carefully,
send me your configuration file, and I will have a look.

- Stefan

Dear Stefan,
I eventually tried the latest version from the CVS. 
And it is odd because like when I tried version 2.5.3, it is like it ignores
the passwd file. I guess I must have a problem in my cfg file.
So I can't really test if 2.5.3 or 2.5.4 have the same problem.

Right now I'm still using 2.5.2 which works fine, if i log out and click on
the logbook tab. I get the page which ask for the username and password. The
thing is I don't get returned to the username/password when I hit log out. I
arrive in the state you can see in the unlogged.jpg.
From here if can go into all the logbooks as long as I don't hit the
logbooks tab and worse I can access to all the config files.

Is there something really badly configured in my config file ? I guess it is
not supposed to work that way.

Thank you,

Alexandre

I just see your [global] part of elogd.cfg, could you send me the complete file?

What you also could try is to delete all cookies stored in your browser. The way
cookies are formed changed between 2.5.2 and 2.5.3, so the system could be
confused by old cookies.

- Stefan

The elogd.cfg is attached in the previous message as attachement 3. Sorry it is a
little bit buried between pictures.
The reason I put the picture of the global elogd.cfg is to show that the not logged
user has access to elogd.cfg which is some kind of trouble...

> I just see your [global] part of elogd.cfg, could you send me the complete file?
> 

Hi I tried to remove the cookies and it still did not ask for password under 2.5.4.
Has the password file format changed between 2.5.2 and 2.5.3 ?

> What you also could try is to delete all cookies stored in your browser. The way
> cookies are formed changed between 2.5.2 and 2.5.3, so the system could be
> confused by old cookies.
> 
> - Stefan

Ok, now I see your problem. You defined a "Guest menu commands" which explicitly allows
not-authorized access (that's what it's for). If you only want to allow authorized
access, remove the "guest menu commands" from the logbook sections and also from the
[global] section.

Please note that if an option is not preent in a logbook section, it is looked for in
the [global] section. I see that most of your logbooks have similar settings. Just put
them into the [global] section, and override it in the logbook section if they are
different.

Thank you, I misunderstood how the "Guest menu commands" worked I thought I had to specify
a limited set of commands to actually limit guest users.

Thanks again for your wonderful work on this program too.

Regards,

Alexandre

> Ok, now I see your problem. You defined a "Guest menu commands" which explicitly allows
> not-authorized access (that's what it's for). If you only want to allow authorized
> access, remove the "guest menu commands" from the logbook sections and also from the
> [global] section.
> 
> Please note that if an option is not preent in a logbook section, it is looked for in
> the [global] section. I see that most of your logbooks have similar settings. Just put
> them into the [global] section, and override it in the logbook section if they are
> different.