Hello,

I am currently using ELOG as a daily logbook for work performed for customers.  This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.  

Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf.  This process all works fine, mostly, except I run into the following obstacles (that are all human related.)

1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer.

2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed.  For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.  

2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such.

2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log).  ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.

All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.

To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later.  This would serve as sort of a place holder.

However, I can't commit myself to always create a log entry for every day either.  Again, human error.

Is what I would like to be able to do is create a new log entry, every single day, automatically.  I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end-of-day or on a day I have downtime and can commit to administrative work.

My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc.  Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.

Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?

Thank you very much in advance!

Actually I would not worry with the 042313a.log files. In a future version of elog they might be replaced by a database or so. I see two options:

1. Add an attribute of date/time type. You do that with "Type <attribute> = datetime". Then you can assign a certain date or time to each entry you do. That means you can tag an entry with the date of yesterday or so. If you make that date then the main database key (via "List display") it basically replaces your "internal" date.
2. You can do automatic entries with the "elog" utility coming with the distribution and described here. This you can even run from a cron job. If you submit a new entry from elog, you get automatically the incremented IDs etc. You can use some default values for the attributes, which you can change later.

 Purists look away now.

I have the same issues regarding "catching up" of entries.  So what I do is use the date command to reset the computer's time back to the time that the entry [i]should[/i] have been made.  Say I need to put an entry for last Thursday (today is Saturday 27th),

Firstly I set the clock back by

date 04252200

(I use a time of 22:00 or later as code for a retro-made entry, the date being the important point for me).

Then any entry will have the correct time (sic) and date entry within the file, and the file the expected format of 130425a.log

After Thursday's batch of entries, I then simply reset the clock for the next entry/ies or indeed back to real time.

Mind you, my log files have the format yymmdda.log, whereas you state yours are mmddyya.log, which strikes me as a very high degree of flexibility!

---

Nice to meet someone else who gets down to the bare ascii and knows how to edit the xxxxxxa.log files!

Sure, its YYMMDDa.log, I was wrong. That format has been chosen so that the normal (ASCII-) sorting shows the files in proper order.

Andreas Luedeke wrote:

David Pilgram wrote: Stefan Ritt wrote: Ryan Blakeslee wrote: Hello, I am currently using ELOG as a daily logbook for work performed for customers.  This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.   Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf.  This process all works fine, mostly, except I run into the following obstacles (that are all human related.) 1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer. 2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed.  For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.   2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such. 2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log).  ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.   All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.   To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later.  This would serve as sort of a place holder. However, I can't commit myself to always create a log entry for every day either.  Again, human error.   Is what I would like to be able to do is create a new log entry, every single day, automatically.  I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end- of-day or on a day I have downtime and can commit to administrative work. My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc.  Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.   Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?   Thank you very much in advance! Actually I would not worry with the 042313a.log files. In a future version of elog they might be replaced by a database or so. I see two options: Add an attribute of date/time type. You do that with "Type <attribute> = datetime". Then you can assign a certain date or time to each entry you do. That means you can tag an entry with the date of yesterday or so. If you make that date then the main database key (via "List display") it basically replaces your "internal" date. You can do automatic entries with the "elog" utility coming with the distribution and described here. This you can even run from a cron job. If you submit a new entry from elog, you get automatically the incremented IDs etc. You can use some default values for the attributes, which you can change later.  Purists look away now. I have the same issues regarding "catching up" of entries.  So what I do is use the date command to reset the computer's time back to the time that the entry [i]should[/i] have been made.  Say I need to put an entry for last Thursday (today is Saturday 27th), Firstly I set the clock back by date 04252200 (I use a time of 22:00 or later as code for a retro-made entry, the date being the important point for me). Then any entry will have the correct time (sic) and date entry within the file, and the file the expected format of 130425a.log After Thursday's batch of entries, I then simply reset the clock for the next entry/ies or indeed back to real time. Mind you, my log files have the format yymmdda.log, whereas you state yours are mmddyya.log, which strikes me as a very high degree of flexibility!   --- Nice to meet someone else who gets down to the bare ascii and knows how to edit the xxxxxxa.log files! Just my two cent: I would strongly recomment NOT to go back and forth with the system time. In some cases this can cause you severe problems with your control system.   Stefans suggestion works fine for our operations logbook: I've just introduced an attribute "When" and sort my entries according to this attribute. The line in the config: Start page = ?rsort=When takes care that this sorting is the default.   The advantage of this approach is in addition, that you keep track of both dates: the date when the work had been performed and the date when you've actually entered the information. Sometimes that turns out to be useful to me to figure out what I did and when ;-)   As to editing the bare ascii: I do this a lot, even with sed scripts. But there is a disclaimer: you can crash elogd with corrupted entries and you may have a hard time figuring out why it crashes. For example accidentally deleting a digit in a cross reference can create a loop that causes elogd to get non-responsive without error: try to find that! I would strongly advise not to build any user application build on editing the ascii files. Just use it for system administration.   Andreas -- He who knows others is wise. He who knows himself is enlightened.                 -- Lao Tsu     Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English

Hello Andreas, Stephan and David,

Thank you so much for the very insightful feedback -- it's very much appreciated!

I took all of the tips and created a solution that encompasses most of the feedback, and I think it solves my problem nicely while adhering  to my desire to keep log filenames in order as well as limiting the risk with moving/renaming, etc.

1. First, I have created a cron job that runs daily at 12:01AM, which runs the following command (This will create a new entry as a place-holder at 12:01AM every day) 

CODE:

elog -h localhost -p 8080 -l Daily -a Customer=CRON -a Subject="Daily Log - System Generated" -a Hours=New -a TravelHrs="0" -a Author=CRON -a Type="System Generated" -a Status="New" -a "Locale=localhost" -v "Auto-generated log entry."  

2. Second, I added the "When" attribute, per Andreas' suggestion.

3. Last, I added the recommended sort command to my .cfg which will exclude the auto-generated logs from showing up and cluttering my view; essentially making them invisible.  I sort by type to exclude the system generated types.

Now, -- to go back in time and enter my "catch-up" data, I'll use the 'Find' in my menu, and find by type = system generated.  That will pull up all the auto-generated entries.  I'll then open whatever day(s) log(s) and edit them, chose the "when" to be the actual day the log entry is for, and enter the data.

I think this is a perfect solution - thanks so much!  PS - Nice to meet you too David -glad to know someone else out there thinks like I do!  :-)

Ryan Blakeslee wrote:

Andreas Luedeke wrote: David Pilgram wrote: Stefan Ritt wrote: Ryan Blakeslee wrote: Hello, I am currently using ELOG as a daily logbook for work performed for customers.  This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.   Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf.  This process all works fine, mostly, except I run into the following obstacles (that are all human related.) 1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer. 2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed.  For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.   2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such. 2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log).  ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.   All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.   To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later.  This would serve as sort of a place holder. However, I can't commit myself to always create a log entry for every day either.  Again, human error.   Is what I would like to be able to do is create a new log entry, every single day, automatically.  I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end- of-day or on a day I have downtime and can commit to administrative work. My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc.  Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.   Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?   Thank you very much in advance! Actually I would not worry with the 042313a.log files. In a future version of elog they might be replaced by a database or so. I see two options: Add an attribute of date/time type. You do that with "Type <attribute> = datetime". Then you can assign a certain date or time to each entry you do. That means you can tag an entry with the date of yesterday or so. If you make that date then the main database key (via "List display") it basically replaces your "internal" date. You can do automatic entries with the "elog" utility coming with the distribution and described here. This you can even run from a cron job. If you submit a new entry from elog, you get automatically the incremented IDs etc. You can use some default values for the attributes, which you can change later.  Purists look away now. I have the same issues regarding "catching up" of entries.  So what I do is use the date command to reset the computer's time back to the time that the entry [i]should[/i] have been made.  Say I need to put an entry for last Thursday (today is Saturday 27th), Firstly I set the clock back by date 04252200 (I use a time of 22:00 or later as code for a retro-made entry, the date being the important point for me). Then any entry will have the correct time (sic) and date entry within the file, and the file the expected format of 130425a.log After Thursday's batch of entries, I then simply reset the clock for the next entry/ies or indeed back to real time. Mind you, my log files have the format yymmdda.log, whereas you state yours are mmddyya.log, which strikes me as a very high degree of flexibility!   --- Nice to meet someone else who gets down to the bare ascii and knows how to edit the xxxxxxa.log files! Just my two cent: I would strongly recomment NOT to go back and forth with the system time. In some cases this can cause you severe problems with your control system.   Stefans suggestion works fine for our operations logbook: I've just introduced an attribute "When" and sort my entries according to this attribute. The line in the config: Start page = ?rsort=When takes care that this sorting is the default.   The advantage of this approach is in addition, that you keep track of both dates: the date when the work had been performed and the date when you've actually entered the information. Sometimes that turns out to be useful to me to figure out what I did and when ;-)   As to editing the bare ascii: I do this a lot, even with sed scripts. But there is a disclaimer: you can crash elogd with corrupted entries and you may have a hard time figuring out why it crashes. For example accidentally deleting a digit in a cross reference can create a loop that causes elogd to get non-responsive without error: try to find that! I would strongly advise not to build any user application build on editing the ascii files. Just use it for system administration.   Andreas -- He who knows others is wise. He who knows himself is enlightened.                 -- Lao Tsu     Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English     Hello Andreas, Stephan and David,   Thank you so much for the very insightful feedback -- it's very much appreciated!   I took all of the tips and created a solution that encompasses most of the feedback, and I think it solves my problem nicely while adhering  to my desire to keep log filenames in order as well as limiting the risk with moving/renaming, etc.   1. First, I have created a cron job that runs daily at 12:01AM, which runs the following command (This will create a new entry as a place-holder at 12:01AM every day)    CODE: elog -h localhost -p 8080 -l Daily -a Customer=CRON -a Subject="Daily Log - System Generated" -a Hours=New -a TravelHrs="0" -a Author=CRON -a Type="System Generated" -a Status="New" -a "Locale=localhost" -v "Auto-generated log entry."     2. Second, I added the "When" attribute, per Andreas' suggestion.   3. Last, I added the recommended sort command to my .cfg which will exclude the auto-generated logs from showing up and cluttering my view; essentially making them invisible.  I sort by type to exclude the system generated types.   Now, -- to go back in time and enter my "catch-up" data, I'll use the 'Find' in my menu, and find by type = system generated.  That will pull up all the auto-generated entries.  I'll then open whatever day(s) log(s) and edit them, chose the "when" to be the actual day the log entry is for, and enter the data.   I think this is a perfect solution - thanks so much!  PS - Nice to meet you too David -glad to know someone else out there thinks like I do!  :-)

Hi Ryan,

Glad you've got your solution.   Sadly, won't work for me, as my 'catching up' is often as replies to some existing threads, rather than just the need to have the day's work under the day's date.  But useful to know for the future.

As for the computer time switching, I am aware of the issues, it's a stand-alone linux box, I've found elog to be surprisingly tolerant, everything's backed up.  The introduction of a 'When' attribute had better be on new logbooks or introduced at end of year (esp during quiet time) so that existing books don't fail to find what I'm looking for in searches.

As for ascii coding the yymmdda.log file, and the infinate loops, been there, got the tee-shirt.  In all bar one case I've found and corrected the problem, although in one case I became convinced it had to be a 'hidden' character because deleteing and retyping the entry letter by letter cured the issue.

Yes, adding a new attribute in a logbook is not straight forward.

But it is doable: that is one of the things that I write SED scripts for. You just need to add the attribute in all old entries, and in this specific case you can use the entry time to initialise the "when" attribute.

Of course I would only do that on a copy of my data and run a separate elogd server on that data to see if anything is screwed up :-)

Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish

Detect language » English

 

 

 We have multiple logbooks. Each user is admin user for his/her own logbook. 

I want user be able to modify config file, but no access to user setting, such as see user list, change password, new user, remove user. 

[logbook1]
Admin user = user1
Login user = user1, user2
Allow Config = user1
List Menu commands = Admin, Config

user1 click on Admin, it opens config file, when user1 click on save, user1 is brought to Config page, which has select user list on top, Change password, Remove user, New user buttons on bottom. Is there a way that admin user has access to config file, but no access to user info at all (not even presented to them).  Is there a way after user1 click save, page doesn't go to that config page?

I could put 
Deny Change password =
Deny Remove user
Deny New user

so when user1 click on those buttons, user1 will get command not allowed. However I would rather have user1 not even see that page. 

 If they have admin rights, the add user button cannot be removed as far as I know.

But even if they can add a user, they only have ability to add a user to the single logbook they are an admin on so they wouldn't be able to add users to other peoples logbooks.

Not sure it helps but that's about all I can really speak to.

 How can I block access to some tools (like edit, erase, config...) for each user? I want only admin users can edit, erase , etc. 

I want know too, how can I erase configuration of SMTP?  I make a test with the "elogd -t" command and now every time I create a new entry in my log book I receve the mensage of error to send email, cause I don't configure a SMTP host. 

 Hello, you can use the "Deny" flag in the config file for each logbook.

Deny <function> = <user>

Example: Deny Edit = Gian

simply add as many deny functions as you would like. Its a bit of work if you have a lot of logbooks but its the easiest solution.

Hope that helps.

Elog Syntax guide is helpful for this stuff too.

 Thanks for help. It work's. 

 But I want to know if I can block a logbook from a user. For example I have a logbook named "Store". I want only users of the vendors have access to this log. How can I do it? 

I didn't find this in manual.

 The only way I find for this trouble is using the "Login user". But we have something best?

 I haven't found a specific way to block viewing a log book. 

I use the top groups settings to keep users in the logbooks they only need access to.

Example

Top Group = Logbook Group1, Logbook Group 2

Group Logbook Group 1 = Logbook1, Logbook2

Group Logbook Group 2 = Logbook3, Logbook4

Then only assign users for logbook1 and logbook2 that you wish to view those logbooks only. They would have to go to the specific top group url in order to view the logbooks.

Then you can go to http://elogurl/(top group)/

And essentially just have the users view the only logbooks they are assigned to.

 I have a logbook installed on a Windows 64 bit VM server 2008 R2 and can access it fine using the password file.  However when using Kerberos it does not authenticate correctly.  I installed Kerberos and pointed it to the realm an domain controller.  Using KINIT command line it appears to accept my password.  Any help is appriciated.  Perhaps some other diagnostics i could try against the kerberos install

Here is global settings:

port = 49212

ssl = 1 

url = https://my-elog.domain.com:49212/

Authentication = Kerberos, file

Kerberos Realm = DOMAIN.COM

Admin User = me

Max content length = 10485760

Password file = pw.txt

Allow password change = 1  (perhaps this is an issue???)

Also...when adding users to the logbook, do you leave the password blank if using Kerberos?

You can leave the password just blank.

The "Allow password change = 1" does not make any difference. It works here even with this option.

So I have no idea why you have that problem. Does it work on another computer, i.e. is it related to the 64 bit VM machine?

Best regards,
Stefan 

The kerberos install, installed the Network Identity Manager and placed krb5 config in my windows directory.  Can a server run lsass.exe only?   or does the krb5 config file and Network Identity Manager need to be on the server?

 Installed both on a Windows 2003 R2 server (32bit) and Kerberos not authenticating, yet gievs me a ticket thru kinit.

Hello folks,

Can we have a better support under modern Linux distributions?

I'm trying to install elog in our webserver and it's becoming a boring task. First of all theres only RPM packages. And we really don't like the Red Hat method, so we use Debian Servers. More package mainteners would be nice.

The software appears to be working correctly, but there are some bugs (or perhaps missing dependencies?); the init script put in /etc/rc.d/init.d is broken under Debian:

First of all because it's in /etc/rc.d.

The second problem is in this line:

# Source function library.

#. /etc/rc.d/init.d/functions

The file doesn't even exists.

The third problem is the echo_success; echo_failure commands that doesn't even exist. As I can see it's definitions are sourced in the functions file that doesn't exist.

After removing this missing commands or files from the init.d; I can call elogd script and start the daemon under root. Appears to be working...

And last but not least; there's a way to standardize the init script to run in other Linux distros, so we can put it to start automatically at boot time?

Many thanks in advance,

Vinícius Ferrão 

PS: I'm not asking to support any creepy distros, but to support the .deb package format and system style.

I'm not using Debian so I cannot give support there. There was some Debian support a few years ago, but the maintainer has gave this up. If you find someone who volunteers to do the job (yourself?) I'm happy to include the Debian specific files in the distribution. 

Stefan

I'm not of the skill level to help, but for what its worth, running Ubuntu 12.04, used alien to install the latest RPM with only two little snags. I had to create a link from libssl.so.1.0.0 to libssl.so.6, which is a trick I've pulled with other software, not sure what the proper fix is. I also had to make similar changes to the init script.

The Debian init script contributed here has been working quite well for me for the last few Ubuntu versions. Unless you edit it, it sets the elog base directory to /etc  so that's where you have to put your themes dir, resources, .conf file, scripts, logbooks, etc. I use symlinks to actually store my logbooks elsewhere.

I would also vote for a sane deb package. Right now, when I upgrade ELOG, I don't even run make install, I just copy the compiled binaries to their respective directories (/usr/bin or /usr/sbin). The rest stays the same.

Hi Louis,

I'm a little surprised by your comment that you use symlinks 'to store your logbooks elsewhere'.

I start the daemon with

 /usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd.cfg -d /home/logbooks

so that both my logbooks *and* the config file are both based on my preferred location, which is a subdirectory of /home.  No symlinks  OK, themes are elsewhere, but for backup purposes, that's a rather lesser issue. 

I have no idea why the default logbook location is /usr/local/elog/logbooks which does not strike me as a sensible location (at least on Slackware).  Maybe such an odd location was to force users to choose a better location...(the -d switch).

To all:

I use Slackware (currently 13, I hear there are some issues with 14 for programs I wish use), and I compile from the sources.  Usually from random svn versions as a general pain-in-the-neck for Stefan.  I've never had to make a [Slackware] package for distribution - I have issued patches and/or source distribution, depending on your point of view.  If someone can provide the advice, I'd certainly try and do a Slackware distribution, but I do have Real Work to do as well, so it may not be done immediately.  I think Ubuntu is fairly close to Slackware, not sure about Debian, which I *thought* was close to Red Hat.

Now I *do* understand what some of the other contributors to this thread are doing, as I do something similar for other programs that are now unmaintained and no longer compile with GCC4 or earlier.  The email program I use is a ten-year-old binary & libraries I compiled under Slackware 7 (if not, 4), and I copy the relivent binaries, libraries and dependances across when I upgrade the o/s.  Yes, one day it will fall down.  Three other programs I regularly use are similarly now 'legacy'.  My 'C' coding isn't up to the major changes apparently needed to allow them to compile again with a modern compiler.
 

Hello,

I am currently using ELOG as a daily logbook for work performed for customers.  This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.  

Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf.  This process all works fine, mostly, except I run into the following obstacles (that are all human related.)

1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer.

2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed.  For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.  

2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such.

2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log).  ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.

All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.

To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later.  This would serve as sort of a place holder.

However, I can't commit myself to always create a log entry for every day either.  Again, human error.

Is what I would like to be able to do is create a new log entry, every single day, automatically.  I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end-of-day or on a day I have downtime and can commit to administrative work.

My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc.  Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.

Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?

Thank you very much in advance!

 Hi,

My email configuration is a little complicated as all emails must be relayed to a central server with TLS authentication. 

So far I've been unable to get the ELOG to work with email, after numerous attempts .  I have got exim4 working on this machine but I don't understand how the elog sends emails well enough, to configure it to recognise and use exim4.  Setting localhost/ my domain/ IP  (and variations) under 'smtp host' doesn't work. (cannot connect to server)

The most interesting error I have been able to get is:

"AUTH command used when not advertised"

or

"Unrecognized authentication type"

Any advice?

Not much. ELOG uses plain SMTP to port 25, but does not support TLS internally. From your error messages above it looks like exim4 (which I never used) uses a different authentication scheme than ELOG supports. ELOG dos a "AUTH LOGIN" which is described for example here:

http://www.fehcom.de/qmail/smtpauth.html

Maybe you can try authentication completely off (remove "SMTP username" from elogd.cfg) ?

/Stefan

Hi there,

Here's a bit of a special scenario. There's no server-side check the user is logged in upon posting, but it rather seems the server relies on the post data sent from the form.

An example of this can be triggered on a write restricted elog, by hitting on New and logging out in another tab. Then posting, from the first tab, will post as if the user was logged on. Hitting back and posting again also works.

Cheers

Yes the credentials are stored in the form where you enter your text. This has following reason: In a shared environment (several people sitting around a computer) we want to identify who submits an elog entry, but not bother the person to enter his/her password every few minutes. So in our experiment I set the time-out to 15 min, meaning after 15 minutes of inactivity a user gets logged out. If the user accesses ELOG every ten minutes or so, he/she stays logged in for a whole shift, which is what you want. Now the problem is that one starts an elog entry, waits twenty minutes, then wants to submit it, but you are bought back to the login screen and your entry is gone. Therefore I store the credentials (encrypted) in the form, so that the form can even be submitted after 20 minutes. Users at our lab are pretty happy with this solution.

In fact there is no way you can 100% ensure that the logged in user submits an entry without asking for his/her password during the submit. Even if the time span above is only very short, it still can happen that someone starts an entry, leaves the room, and someone else submits it. So people got used to the good practice not to leave any unfinished elog entry open when they go or leave the browser (to another tab for example). If I would implement to password request during the submit, there would be two problems: 1) Users will heavily complain and 2) I have to store the form data temporary (together with some optional attachments) on the server side, start a password query, and only if that succeeds submit the entry. This is somehow complicated to implement since I cannot use the normal elog database. Then I have to care about dangling entries (like if the password was wrong I should delete the temporary data???) and so on.

I plan for the future a kind of "draft" mode, where entries can be stored as "drafts" (like in most email systems). You get an auto-save every few minutes, and can work on the draft before actually submitting it. In that case your password query could be implemented more easily. But implementing the draft mode needs a change of the database system, so I have to find time to do that.

Best regards,

Stefan