First, I really appreciate this software. Thank you.

Next, I have question - am wanting to have a 'dashboard' of sorts that shows all entries that are 'open'. That part is easy enough. But, then I want to color the time (or some other field) if the ELOG has not been updated/created for more than X hours. This will help us keep track of events that need status updates.

Doable?

Thanks!

Unfortunately not. What I would do is to define a quick filter, so with one click all 'open' entries are shown. Then you can look at the date column and see how long they have been open (actually when they have been submitted, so the difference you must calculate in your head!). 

Hi!

After submitting a new record with preset "Locked attributes" not even admin user is able to edit these entries.

What seems to be the problem?

Note my config

Logbook Tabs = 0
Theme = default
Date Format = %Y, %B
Title Image= <img border=0 src="konturlogo_dynamate.png" alt="DynaMate logo">
Logout to main = 1
Mode commands = 0
List after submit = 1
Use Email From = weblog@dynamate.se
Use Lock = 1
Password file=improvements_qpp.pwd
Admin User = sssuxo, sssuga
Self register = 3
Restrict edit = 1
Login expiration = 0
Display Email recipients = 0
Preset text = qpp_improvements.txt
Comment = Improvements Uppdragsprocessen
Attributes = Namn, Avdelning, Telefonnummer, Rubrik, Ansvarig, Beräknad klar, Verkligt klar, Status, Status2
Required Attributes = Namn, Avdelning, Telefonnummer, Rubrik
Locked attributes = Ansvarig, Beräknad klar, Verkligt klar, Status, Status2
Options Rubrik = Förfrågan - Mottagning, Förfrågan - Bearbetning, Förfrågan - Anbud, Genomförande - Beställning, Genomförande - Uppdragsplanering, Genomförande - Projektering/Konstruktion, Genomförande - Tillverkning/Utförande, Genomförande - Överlämning till kund, Genomförande - Avslut av uppdrag, Annat
Type Beräknad klar = date
Type Verkligt klar = date
Subst Beräknad klar = $Date
Subst Verkligt klar = $Date
Options Status = Ny, 0%, 25%, 50%, 75%, 100%
Options Status2 = Pågående, Avklarad
Preset Status = Ny
Preset Status2 = Pågående
Cell Style Status 25% = background-color:yellow
Cell Style Status 50% = background-color:orange
Cell Style Status 75% = background-color:33CCFF
Cell Style Status 100% = background-color:green
List Menu Commands = New, Find, Select, Logout, Config, Last day, Help          
Menu commands = List, New, Edit, Delete, Find, Help
List Display = Datum, Namn, Avdelning, Beräknad klar, Verkligt klar, Ansvarig, Status, Status2, Rubrik
Guest menu commands = List, Find, Login, Help
Guest List Menu commands = List, Find, Login, Help
Guest list Display = Datum, Namn, Avdelning, Beräknad klar, Verkligt klar, Ansvarig, Status, Status2, Rubrik
Allow Config = sssuxo
Page Title = Improvements Uppdragsprocessen QPP - $Subject
Suppress default = 3
Reverse sort = 1
Quick filter = Date, Ansvarig, Status, Status2

Regards
/UlfO

There is no problem. "Locked" means "Locked", and not "Locked but admin can change it". As admin you can only change the config file, remove the "Locked" option, change the attribute, and put back the "Locked" option.

- Stefan 

 But it says locked on "websubmission" in the instructions for the command "Locked attributes".

Doesnt it  mean that for instance a logged in admin should be able to change a value of a submitted locked attribute.

I am looking for a possibility to have have certain attributes locked on submission but for instance admin should be able to change the data in them after they has been submitted.

No it does not mean that the admin should be able to change it afterwards. The only way is like I described it (change the config file temporarily). 

 OK!

Thank you for a fast response!

Do you plan to implement this feature in later releases?

No. 

 Is it possible in some other way to make certain attributes preset but readonly for normal user at submission but afterwards changed by admin user?

No. 

Our group is interested in installing elog on a small/low-cost processing platform so that we can provide ready-to-run systems for our collaborators to use.  We selected a candidate platform form Technologic Systems, their wifibox-2 (http://www.embeddedarm.com/products/board-detail.php?product=TS-WIFIBOX-2).  This product is based on the TS7553 CPU board (http://www.embeddedarm.com/products/board-detail.php?product=TS-7553#) which has a 250MHz Cavium ARM9 CPU.

We have had good success getting the elogd executable cross-compiled for use on this platform and have a working system.  However, we are having significant issues with performance.  When we click the "New" item to enter a new event there is a noticable delay.  When clicking "Submit" there is a delay of approximately 10 seconds before the browser window displays the new event.  With the elogd running on other platforms (Virtual Machine or netbook) the delays for these actions are very small - typically less than a second or imperceptible.

So here are some specific questions:

- Is it reasonable to expect a 250 MHz ARM processor to serve an elog logbook with user acceptable performance?

- Our cfg file is attached.  Is there anything in the cfg file creating this performance problem.

- I have spent some time looking at this, and suspect that the delay is due to the cpu load of all the string manipulation and comparison operations (1200 calls to getcfg() on a submit).  Are there other candidate sources of performance issues that should be considered?

- Does anyone have any suggestions on how to improve our performance?

- Does anyone have a suggestion for an alternative small and low-cost COTS platform to use to host the elogd application?  (We would prefer to attain satisfactory performance on the Wifibox-2.)

Thanks for any help that can be offered.

Tim

Hi!

Looking at your config file it seems that a lot of the attributes are not user-specified but rather auto-generated content. You may want to consider using the elog client to submit such entries; this might avoid performance issues related to communication of the server with the web browser used for entry generation. This way, event entries can even be automatically created by other software rather than having a user to submit them.

Yoshio

 Yoshio,

Thanks for the suggestion.

We have actually tried running the elog server with a very minimal set of attributes, all of which were human entries, and still had response times that were entirely unacceptable.  So, unfortunately this path won't solve all our issues.

tt

Yes there is lots of string handling in elogd, but compared with PHP this is still faster. The getcfg() call actually caches the contents of the config file to improve its performance. I stopped optimization when the response was quick on a 800 MHz Pentium originally, but your 250 MHz ARM might be slower. What you can try is to

1) Verify that the CPU is really the limit, just check that the CPU is at 100% with elogd during your 10 second response time. On some installations, the submit command triggers some email notification, and actually the email server was the bottleneck.

2) If it's indded the CPU for elogd, run it under the gcc profiler. Identify which routines take most CPU and let me know. Maybe I can do something about that.

- Stefan

 Stefan,

Thanks for your feedback. 

We had confirmed that the CPU load is running at at least 95% while these requests are being processed.  Additionally, we were attempting to use gprof to determine where the code was spending its time.  We have had several problems with trying to use gprof on that platform, both with using it for elog (we get seg faults) and then with using it on a small program created to test gprof on our particular setup (program runs; we get an output file; but all routines show that zero seconds were used).  So, unfortunately, I can not, at this point, provide a good idea of which routines are using the most CPU on this platform.  If we are able to get profiling results on this particular platform, I will certainly share them with you.

A possibly more relevant angle is that we have determined that executing floating-point operations seems to have a drastic impact on software execution times.  Can you point us to routines in the elogd code where floating point operations are taking place?

Thanks,

Tim

As far as I can remember there is no floating point in elog. 

Hi there,

I am new to ELOG, trying to add an image (logo) in my top text.

Theme = default
Comment = TRIPLE POINT Log
Top text = Logo.png

results in ‰PNG  .

When I just enter a string of text it seems to work fine... I would really appreciate any help!

thanks!

 Hi there,

I'm not sure where it appears in the documentation, but question 9 of the FAQs shows that 'Bottom text' has to be in html - and so does 'top text'

The get-it-done-now way to do it would be

Top Text = <img src=Logo.png>

(and ensure Logo.png is in the same directory as the config file - otherwise you'd best put the path of where it is in).

Of course you can do all sorts of things with this, such as centering, have it so that if you click on the logo you get taken to some other home page, but for

all that sort of thing check up with a guide to html.

Hi,

the manual says:

"
There are four ways through which access to a logbook may be controlled:

it may be open for all to read ;
it may require a common "read" password for all users ;
it may require each user to have an individual user account (login name) and password ;
finally, access may be granted or not depending on the address of the workstation you are using.
"

But it doesn't say how to do so or at least I didn't find it.

If I have each user have to log in with an individual accout, can I define which logbooks he can read and/or modify?
If yes, how to do that?

Also, please accept my vote for user groups. We can use that, too.

TIA,
Roland.

You haven't found it. Just look here:

http://midas.psi.ch/elog/config.html#access

You need Password file and Login user. 

Hi,

I'm trying to set up elogd, running on port 8080 behind an Apache server on port 80, using mod_proxy to redirect
to the elogd server, and the recommended

Redirect permanent /elogbook http://example.com/elogbook/
ProxyPass /elogbook/         http://example.com:8080/

This works well for non-password-protected logbooks, but for password protected (that I can access fine via port
8080), I keep getting shown the Login page, even with valid username / password.    

Poking around the code, it appears (probably not too surprisingly) that the issue lies in check_login().  
For example, 

   /* if invalid or no session ID, show login page */
  if (!skip_sid_check && !sid_check(sid, user_name)) {
      if (isparam("redir"))
         strlcpy(str, getparam("redir"), sizeof(str));
      else
         strlcpy(str, isparam("cmdline") ? getparam("cmdline") : _cmdline, sizeof(str));
      /* avoid recursive loops with ?cmd=Login */
      if (stristr(str, loc("Login")))
         str[0] = 0;
      /*  added write_logfile here...
          char mstr[250];
          sprintf(mstr, "show_login B %s isparam: %d, cmd: %d, skip_sid_check: %d, sid_check: %d",
                         user_name,  isparam("redir"), isparam("cmdline"), skip_sid_check, sid_check(sid,
user_name));
           write_logfile(lbs, mstr);

        */
      show_login_page(lbs, str, 0);
      return FALSE;
}

and the logfile shows that user_name is blank(!!) and redir, cmdline, skip_sid_check, and sid_check(sid,
user_name) all to be 0.   In fact, isparam("unm") and isparam("upwd") are also 0, which explains why user_name
is blank.   But the log file also shows

LOGIN user "username" (attempt)
LOGIN user "username" (success)

just prior to this!

I'd guess that the form POST methods aren't being forwarded correctly, but I haven't looked at it in any more
detail.   

Is there a way to make this (password protecting logbooks while also using a proxy to Apache) work?

Thanks!

> Is there a way to make this (password protecting logbooks while also using a proxy to Apache) work?

I use it with the current version and it works fine for me. What you might be missing is the

URL = http://example.com/elogbook/

statement in your elogd.cfg to make this work.

Best regards,
Stefan

I don't remember the details, but originally had the same trouble. I think a "/" at the end of a url got me somewhere. 
I have defined...

URL = http://somewhere.edu/elog

...in the config file, and my redirect looks like this:

Redirect /elog http://somewhere.edu/elog/
ProxyPass /elog/ http://somewhere.edu:8080/
ProxyPassReverse /elog/ http://somewhere.edu:8080/

> I don't remember the details, but originally had the same trouble. I think a "/" at the end of a url got me somewhere. 
> I have defined...
> 
> URL = http://somewhere.edu/elog
> 
> ...in the config file, and my redirect looks like this:
> 
> Redirect /elog http://somewhere.edu/elog/
> ProxyPass /elog/ http://somewhere.edu:8080/
> ProxyPassReverse /elog/ http://somewhere.edu:8080/


Yes, that did it:  Adding the URL to the config file was the key.

Thanks!

We seem to have a problem with retrieving user passwords using the forgot password system
This only happens when trying to use the password recovery from the first screen that forces people to log in with the following syntax:

Protect selection page = 1
Password file = XXXXX

On the first page of our elog which can be found at

http://physics.uj.ac.za/elog/

Now currently there is one page that is viewable by guests, so going to this direct link, bypasses the login at the main page
If you try login from this page, and then use the forgot password link, the email that gets sent through will then work.

The first email that gets sent through using the main login page has the following link:
https://physics.uj.ac.za/elog/?redir=%3Fcmd%3DChange+password%26oldpwd%3DYJAATGHSIRRSBLLP&uname=Tester&upassword=YJAATGHSIRRSBLLP

When clicking on the above link normally, it takes you to a NULL user

The email link that gets sent from the guest page, that works, looks like this:
https://physics.uj.ac.za/elog/General/?redir=%3Fcmd%3DChange+password%26oldpwd%3DSACWEHJWWHKEXLMO&uname=Tester&upassword=SACWEHJWWHKEXLMO

Attached is a copy of the cfg file. The last few logbooks are all actually just copies of TEMPLATE A, so I have removed all their details to make the file easier to read for now
 

Thanks for reporting that bug. With the help of your config file I finally could reproduce and fix it. The fix is contained in SVN revision 2462.

 Thanks mate.. Glad to know it wasn't just me going insane? I'll keep an eye out for the new file

For the new version have a look here: http://midas.psi.ch/elog/faq.html#21 

I'm trying to debug an issue with elogd (2.9.1) and was reminded that using the "-v" option exposes
user passwords. This wasn't a huge problem for us in the past, but we're now using kerberos authentication,
meaning that the exposed username/password applies to lots of sensitive systems within our university.


I'd suggest that the "-v" option hide passwords. If they need to be revealed for debugging
purposes, make that a separate (and very well documented) option. Maybe something like:
"--really-include-passwords-as-clear-text-in-log-output". :)

> I'd suggest that the "-v" option hide passwords. If they need to be revealed for debugging

As a work around, I've changed the elogd startup script to do:

        /usr/local/sbin/elogd -v -c /usr/local/elog/elogd.cfg 2>&1 | perl -ne '$|=1; if ( $_ =~ /name="upassword"/
) {<>; <>;} else { print "$_";}' > /var/log/elog 2>&1 &

That simply throws away lines that match the pattern:

    name="upassword"

and the following 2 lines (the last of which contains the password).