Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 211 of 727  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subject
  67492   Fri May 3 19:27:53 2013 Reply Hal Proctorhproctor2@gmail.comInfoWindows2.9.2Re: Kerberos on VM server 64bit

Hal Proctor wrote:

Stefan Ritt wrote:

Hal Proctor wrote:

 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.

  67491   Fri May 3 19:09:45 2013 Reply Hal Proctorhproctor2@gmail.comInfoWindows2.9.2Re: Kerberos on VM server 64bit

Stefan Ritt wrote:

Hal Proctor wrote:

 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?

 

  67490   Fri May 3 14:41:01 2013 Reply Stefan Rittstefan.ritt@psi.chInfoWindows2.9.2Re: Kerberos on VM server 64bit

Hal Proctor wrote:

 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 

  67489   Thu May 2 21:10:23 2013 Question Hal Proctorhproctor2@gmail.comInfoWindows2.9.2Kerberos on VM server 64bit

 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?

  67488   Mon Apr 29 10:17:54 2013 Reply Andreas Luedekeandreas.luedeke@psi.chQuestionLinux2.5.2Re: Auto-Generate new logbook daily

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:

  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!

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
 
 
Detect language » English
 
  67487   Sat Apr 27 15:30:28 2013 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.5.2Re: Auto-Generate new logbook daily

David Pilgram wrote:

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!

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

  67486   Sat Apr 27 14:09:13 2013 Reply Achim Dreyerml10352@adreyer.comRequestLinux2.9.2Re: Support for modern Linux

Vinícius Ferrão wrote:

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.

 

 

 

 

/etc/rc.d/init.d/functions is part of the initscripts.rpm - so only usable on RedHat/CentOS..

Can someone also update https://midas.psi.ch/elog/download.html ? It was last updated in 2001 and the download directory contains a debian package that was last updated 2004. If debian is not supported in a current version that bit should be removed from the page.

Kind regards,
Achim
  67485   Sat Apr 27 13:21:38 2013 Reply David PilgramDavid.Pilgram@epost.org.ukQuestionLinux2.5.2Re: Auto-Generate new logbook daily

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:

  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!

ELOG V3.1.4-80633ba