Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 169 of 238  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Collapse | Expand  Show only new entries    1901 Entries 
Goto page Previous  1, 2, 3 ... 168, 169, 170 ... 236, 237, 238   Next  
icon4.gif   SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Mon Sep 18 20:35:44 2006 truss-error.outtruss-good.out
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"
    icon2.gif   Re: SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Mon Sep 18 22:09:23 2006 

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"



Quote:

As a followon, when I do run SVN1714 as a detached process but started as ROOT I get the following console messages:

Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.

I do not get these when I run the app as me - which is a non-UID 0 account. Perhaps this is an artifact of the "-x" option?

    icon2.gif   Re: SVN1714 will not run in 'daemon" mode on Solaris8, posted by Stefan Ritt on Fri Sep 22 07:47:58 2006 

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"


The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be.
       icon2.gif   Re: SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Fri Sep 22 19:32:45 2006 

Stefan Ritt wrote:

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"


The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be.



Quote:


Ok, what this tells me is I need to get TRUSS to follow the fork - which I think I can do. The behavior, however, is that elog never goes into daemon mode after that fork.

More info to follow.
       icon2.gif   Re: SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Fri Sep 22 22:12:18 2006 truss-daemon-1714.txt

Stefan Ritt wrote:

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"


The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be.




Quote:
Ok, I got it. I've attached the TRUSS output where we follow the fork. It appears that elogd cannot open any of the specified files then gives up. What was throwing me is no error output, even to STDERR. When I run the same but without the -D flag the files are opened fine.

There are also strange system calls that differ, and I thought it might be due to the setuid(60001) -nobody- but the the non-daemn mode also sets to nobody and works fine.
          icon2.gif   Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Tue Oct 10 23:29:53 2006 

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"


The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be.




Quote:
Ok, I got it. I've attached the TRUSS output where we follow the fork. It appears that elogd cannot open any of the specified files then gives up. What was throwing me is no error output, even to STDERR. When I run the same but without the -D flag the files are opened fine.

There are also strange system calls that differ, and I thought it might be due to the setuid(60001) -nobody- but the the non-daemn mode also sets to nobody and works fine.



Quote:

I just compiled SVN1723 and tried the generic elogd.cfg -- of course *that works!*. Something in my complex config that causes elog to barf when it is attempting to fork the daemon process. To me the TRUSS output indicates that elog can't seem to find any logfile to work on -- very bizarre.
             icon2.gif   Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Wed Oct 11 00:19:05 2006 

Steve Jones wrote:

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"


The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be.




Quote:
Ok, I got it. I've attached the TRUSS output where we follow the fork. It appears that elogd cannot open any of the specified files then gives up. What was throwing me is no error output, even to STDERR. When I run the same but without the -D flag the files are opened fine.

There are also strange system calls that differ, and I thought it might be due to the setuid(60001) -nobody- but the the non-daemn mode also sets to nobody and works fine.



Quote:

I just compiled SVN1723 and tried the generic elogd.cfg -- of course *that works!*. Something in my complex config that causes elog to barf when it is attempting to fork the daemon process. To me the TRUSS output indicates that elog can't seem to find any logfile to work on -- very bizarre.

Stefan, you might find this interesting. I went ahead and removed all references to pre-existing logbook directories and restarted with TRUSS tracing the program. Elogd managed to go into daemon mode but the minute it received a request it generated a segmentation fault. Notice that even though elog could not open the logging directory it went ahead and went into polling mode. I have no idea what "/var/run/syslog_door" is. Working on isolating.
4190:   seteuid(60001)                                  = 0
4190:   stat("/sysadm/www/elog/cr-elogd.cfg", 0xFFBC9558) = 0
4190:   stat("/usr/lib/locale/english/english.so.2", 0xFFBC85C0) Err#2 ENOENT
4190:   stat("/sysadm/www/elog/resources/eloglang.", 0xFFBC9348) Err#2 ENOENT
4190:   listen(3, 5, 1)                                 = 0
4190:   fstat(4, 0xFFBC9318)                            = 0
4190:   time()                                          = 1160518513
4190:   getpid()                                        = 4190 [1]
4190:   putmsg(4, 0xFFBC89D0, 0xFFBC89C4, 0)            = 0
4190:   open("/var/run/syslog_door", O_RDONLY)          = 7
4190:   door_info(7, 0xFFBC8908)                        = 0
4190:   getpid()                                        = 4190 [1]
4190:   door_call(7, 0xFFBC88F0)                        = 0
4190:   close(7)                                        = 0
4190:   open("crlogbooks/logs/elogaccess.log", O_RDWR|O_APPEND|O_CREAT, 0644) Err#2 ENOENT
4190:   poll(0xFFBC7640, 1, 1000)                       = 0
4190:   poll(0xFFBC7640, 1, 1000)       (sleeping...)
4190:   poll(0xFFBC7640, 1, 1000)                       = 0
4190:   poll(0xFFBC7640, 1, 1000)                       = 0
4190:   poll(0xFFBC7640, 1, 1000)                       = 1
4190:   accept(3, 0xFFBEF300, 0xFFBC9830, 1)            = 7
4190:   time()                                          = 1160518516
4190:   poll(0xFFBC7640, 1, 6000)                       = 1
4190:   recv(7, " G E T   /   H T T P / 1".., 100000, 0) = 610
4190:       Incurred fault #6, FLTBOUNDS  %pc = 0x0001EA1C
4190:         siginfo: SIGSEGV SEGV_MAPERR addr=0xFF3EFE30
4190:       Received signal #11, SIGSEGV [default]
4190:         siginfo: SIGSEGV SEGV_MAPERR addr=0xFF3EFE30
4190:           *** process killed ***
                icon2.gif   Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8, posted by Stefan Ritt on Wed Oct 11 08:18:14 2006 

Steve Jones wrote:
There are also strange system calls that differ, and I thought it might be due to the setuid(60001) -nobody- but the the non-daemn mode also sets to nobody and works fine.


The elogd program opens the port (which might be below 1024 and thus needs privileges), then either become daemon or not, then changes to the user and group specified in elogd.cfg. So this behaviour should be the same on both cases.



Steve Jones wrote:
I just compiled SVN1723 and tried the generic elogd.cfg -- of course *that works!*. Something in my complex config that causes elog to barf when it is attempting to fork the daemon process.


That's a good starting point. Take your config file, strip one option after the other, and see which is the offending one. This helps us tracking down the problem.



Steve Jones wrote:
I have no idea what "/var/run/syslog_door" is.


I have not either. But one thing which is different in the daemon mode that all output is redirected to the syslog facility via the function call redirect_to_syslog();. This routine was not written by myself so I don't know 100% what it's doing, just under Linux it works fine. Try to outcomment this function and try again.
                   icon2.gif   SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8), posted by Steve Jones on Thu Oct 26 21:54:40 2006 

Stefan Ritt wrote:

Steve Jones wrote:
There are also strange system calls that differ, and I thought it might be due to the setuid(60001) -nobody- but the the non-daemn mode also sets to nobody and works fine.


The elogd program opens the port (which might be below 1024 and thus needs privileges), then either become daemon or not, then changes to the user and group specified in elogd.cfg. So this behaviour should be the same on both cases.



Steve Jones wrote:
I just compiled SVN1723 and tried the generic elogd.cfg -- of course *that works!*. Something in my complex config that causes elog to barf when it is attempting to fork the daemon process.


That's a good starting point. Take your config file, strip one option after the other, and see which is the offending one. This helps us tracking down the problem.



Steve Jones wrote:
I have no idea what "/var/run/syslog_door" is.


I have not either. But one thing which is different in the daemon mode that all output is redirected to the syslog facility via the function call redirect_to_syslog();. This routine was not written by myself so I don't know 100% what it's doing, just under Linux it works fine. Try to outcomment this function and try again.



Steve Jones wrote:

Ok, I've narrowed down the problem to a single attribute. I edited elogd_fancy.cfg as it ships with SVN1723 and found a real bug and an issue:

BUG: In the initial comment section of elogd_fancy.cfg the line 
# This [global] section contains settings common to all logbooks
is not parsed correctly as a comment and the embedded [global] is picked up and confuses elogd, eg., elogd will not pickup the port=8080 option. Taking "[global]" out of the comment restores fucntionality. I recommend checking to make sure that the config file checking routine ignores *entire* lines starting with a comment char;

ISSUE: The option 
Logbook dir =
causes an enormous amount of problems, and this may be limited to elog installs that exist in NFS space (as opposed to local disk). If the default is left alone elogd appears to work fine; Try and override and the fun begins. The previous attached traces show that once going into daemon mode none of the logbook dirs can be found nor indexed. The workaround is to use the default "logbooks" dir. Perhaps the routine that creates the default (if not found) should be the same as the one that creates the override (?).

I reproduced this behavior using the elogd_fancy.cfg that ships.

                      icon2.gif   SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8), posted by Stefan Ritt on Wed Nov 8 08:20:34 2006 

Steve Jones wrote:
BUG: In the initial comment section of elogd_fancy.cfg the line 
# This [global] section contains settings common to all logbooks
is not parsed correctly as a comment and the embedded [global] is picked up and confuses elogd, eg., elogd will not pickup the port=8080 option. Taking "[global]" out of the comment restores fucntionality. I recommend checking to make sure that the config file checking routine ignores *entire* lines starting with a comment char;


Acknowledged. The problem was that the section between the line 
# This [global] section contains settings common to all logbooks
and the real 
 [global]
section was interpreted as the global section, and thus the "real" one was omitted. I changed the code now such that all lines starting with a '#' or ';' are completely skipped, that fixes the problem. The fix is contained in revision 1745.


Steve Jones wrote:
ISSUE: The option 
Logbook dir =
causes an enormous amount of problems, and this may be limited to elog installs that exist in NFS space (as opposed to local disk). If the default is left alone elogd appears to work fine; Try and override and the fun begins. The previous attached traces show that once going into daemon mode none of the logbook dirs can be found nor indexed. The workaround is to use the default "logbooks" dir. Perhaps the routine that creates the default (if not found) should be the same as the one that creates the override (?).


That's weird. Have you tried to specify a full path for the logbook, like /nfs/some/directory ? The only difference of the daemon mode compared to the normal mode is that elogd does a cd to the root ('/'). If you specify logbook dir relative to the starting directory, like 'some/subdir', elogd will the try to access it under '/some/subdir', where it might not have read/write privileges.
                         icon2.gif   SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8), posted by Steve Jones on Wed Nov 8 12:55:58 2006 

Stefan Ritt wrote:

Steve Jones wrote:
BUG: In the initial comment section of elogd_fancy.cfg the line 
# This [global] section contains settings common to all logbooks
is not parsed correctly as a comment and the embedded [global] is picked up and confuses elogd, eg., elogd will not pickup the port=8080 option. Taking "[global]" out of the comment restores fucntionality. I recommend checking to make sure that the config file checking routine ignores *entire* lines starting with a comment char;


Acknowledged. The problem was that the section between the line 
# This [global] section contains settings common to all logbooks
and the real 
 [global]
section was interpreted as the global section, and thus the "real" one was omitted. I changed the code now such that all lines starting with a '#' or ';' are completely skipped, that fixes the problem. The fix is contained in revision 1745.


Steve Jones wrote:
ISSUE: The option 
Logbook dir =
causes an enormous amount of problems, and this may be limited to elog installs that exist in NFS space (as opposed to local disk). If the default is left alone elogd appears to work fine; Try and override and the fun begins. The previous attached traces show that once going into daemon mode none of the logbook dirs can be found nor indexed. The workaround is to use the default "logbooks" dir. Perhaps the routine that creates the default (if not found) should be the same as the one that creates the override (?).


That's weird. Have you tried to specify a full path for the logbook, like /nfs/some/directory ? The only difference of the daemon mode compared to the normal mode is that elogd does a cd to the root ('/'). If you specify logbook dir relative to the starting directory, like 'some/subdir', elogd will the try to access it under '/some/subdir', where it might not have read/write privileges.



Quote:
Very weird. No, I did not try an absolute path - but I did notice the attempt to "cd /" in the truss output. In fact, it was immediately after that "cd /" test that things appeared to start not working - basically, elogd could not find anything.

I'm putting this on hold for the time being as I now have test systems going into production. I'll be able to test next week.

                            icon2.gif   SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode, posted by Stefan Ritt on Wed Nov 8 13:07:31 2006 

Steve Jones wrote:
Very weird. No, I did not try an absolute path - but I did notice the attempt to "cd /" in the truss output. In fact, it was immediately after that "cd /" test that things appeared to start not working - basically, elogd could not find anything.


The "cd /" is mandatory for daemons according to Unix standards. If a daemon gets started on an NFS subtree, that subtree cannot be unmounted anymore. Therefor it's required that all daemons cd to root, such that the NFS subtree can freely be mounted and unmounted. I therefore use absolute paths in all my statements of elogd.cfg.
icon4.gif   Bug? Password file location changed, posted by David Spindler on Thu Nov 2 18:02:44 2006 
I just tried to upgrade from 2.6.1-1633 to 2.6.2-1734. Whenever I tried to access the elog, it showed my password to be invalid. I tried this on 2 machines and same results. I did notice on the second one when I started it from a command prompt that it was creating a new empty password file in a different location.

I have a password file called pwd.txt. It resides in the main elog directory, in my case, c:\elog, along with the elgod.exe and elogd.cfg. Apparently, the new version looks for it in the logbooks directory. I adjusted my path to the file and it works fine.

I am reporting this as a bug because it is my guess that this is not an expected result. I would expect the old elogd.cfg file to work without altering in the newer version.

Thanks, keep up the great work, Stefan. You have a great program.
David Spindler
    icon2.gif   Re: Bug? Password file location changed, posted by David Spindler on Thu Nov 2 18:10:07 2006 

David Spindler wrote:
I just tried to upgrade from 2.6.1-1633 to 2.6.2-1734. Whenever I tried to access the elog, it showed my password to be invalid. I tried this on 2 machines and same results. I did notice on the second one when I started it from a command prompt that it was creating a new empty password file in a different location.

I have a password file called pwd.txt. It resides in the main elog directory, in my case, c:\elog, along with the elgod.exe and elogd.cfg. Apparently, the new version looks for it in the logbooks directory. I adjusted my path to the file and it works fine.

I am reporting this as a bug because it is my guess that this is not an expected result. I would expect the old elogd.cfg file to work without altering in the newer version.

Thanks, keep up the great work, Stefan. You have a great program.
David Spindler

I also just noticed that the text files I use for presetting the text window also have to be in the logbooks directory.
       icon2.gif   Re: Bug? Password file location changed, posted by Steve Jones on Thu Nov 2 23:17:10 2006 

David Spindler wrote:

David Spindler wrote:
I just tried to upgrade from 2.6.1-1633 to 2.6.2-1734. Whenever I tried to access the elog, it showed my password to be invalid. I tried this on 2 machines and same results. I did notice on the second one when I started it from a command prompt that it was creating a new empty password file in a different location.

I have a password file called pwd.txt. It resides in the main elog directory, in my case, c:\elog, along with the elgod.exe and elogd.cfg. Apparently, the new version looks for it in the logbooks directory. I adjusted my path to the file and it works fine.

I am reporting this as a bug because it is my guess that this is not an expected result. I would expect the old elogd.cfg file to work without altering in the newer version.

Thanks, keep up the great work, Stefan. You have a great program.
David Spindler

I also just noticed that the text files I use for presetting the text window also have to be in the logbooks directory.



Quote:
The relocation was a documented change that Stefan made intentionally. Yes, it caught me too Smile
          icon2.gif   Re: Bug? Password file location changed, posted by David Spindler on Fri Nov 3 14:40:36 2006 

Steve Jones wrote:

David Spindler wrote:

David Spindler wrote:
I just tried to upgrade from 2.6.1-1633 to 2.6.2-1734. Whenever I tried to access the elog, it showed my password to be invalid. I tried this on 2 machines and same results. I did notice on the second one when I started it from a command prompt that it was creating a new empty password file in a different location.

I have a password file called pwd.txt. It resides in the main elog directory, in my case, c:\elog, along with the elgod.exe and elogd.cfg. Apparently, the new version looks for it in the logbooks directory. I adjusted my path to the file and it works fine.

I am reporting this as a bug because it is my guess that this is not an expected result. I would expect the old elogd.cfg file to work without altering in the newer version.

Thanks, keep up the great work, Stefan. You have a great program.
David Spindler

I also just noticed that the text files I use for presetting the text window also have to be in the logbooks directory.



Quote:
The relocation was a documented change that Stefan made intentionally. Yes, it caught me too Smile

Thanks. I checked the changelog and the documentation for any such changes but did not see them. I just looked again, and still do not see them. Anyway, I know what to expect, now, and will adjust. Again, thanks!
             icon2.gif   Re: Bug? Password file location changed, posted by Stefan Ritt on Tue Nov 7 09:22:52 2006 

David Spindler wrote:
Thanks. I checked the changelog and the documentation for any such changes but did not see them. I just looked again, and still do not see them. Anyway, I know what to expect, now, and will adjust. Again, thanks!


That change was actually made in SVN revision 1708 on Aug. 1st, 2006, which was after the release of 2.6.2. So it will be made official in 2.6.3 and documented accordingly.
icon5.gif   Push button for Menue Command, posted by An Thai on Fri Nov 3 15:53:44 2006 
Dear Stefan,

in your documentation: ELOG - Syntax of elog.cfg I see two screenshots in the Themes section. The left one shows a layout with Push buttons on the Menue Command. I would like this layout and try to find information on W3C consortium how i can redesign the CSS file to realise the push button for hyperlink, but I cannot get an success there. Can you give more information how you made it?

Thank you in advance
    icon2.gif   Re: Push button for Menue Command, posted by Stefan Ritt on Tue Nov 7 08:38:57 2006 

An Thai wrote:
Dear Stefan,

in your documentation: ELOG - Syntax of elog.cfg I see two screenshots in the Themes section. The left one shows a layout with Push buttons on the Menue Command. I would like this layout and try to find information on W3C consortium how i can redesign the CSS file to realise the push button for hyperlink, but I cannot get an success there. Can you give more information how you made it?

Thank you in advance


The push buttons in the menu were very old and have been removed long time ago. It is not possible to change this back via CSS, sorry. I updated the screen shots to more recent pictures.
icon13.gif   XML, CSV and Raw export produces 'last' page only, posted by Brian Marshall on Mon Nov 6 17:41:13 2006 
The Find command page provides an option, 'Display n entries per page' which is useful when the result of the search is to be viewed on-screen.

However this value is also applied to CSV, XML and Raw export and only the 'last' page of data is exported.
For example, if there are 17 matching entries and n is set to 8, only one entry will appear in the exported file.

In my opinion, this option should be ignored for XML, CSV and Raw export and all matching entries should be exported.
    icon2.gif   Re: XML, CSV and Raw export produces 'last' page only, posted by Stefan Ritt on Tue Nov 7 08:17:40 2006 

Brian Marshall wrote:
The Find command page provides an option, 'Display n entries per page' which is useful when the result of the search is to be viewed on-screen.

However this value is also applied to CSV, XML and Raw export and only the 'last' page of data is exported.
For example, if there are 17 matching entries and n is set to 8, only one entry will appear in the exported file.

In my opinion, this option should be ignored for XML, CSV and Raw export and all matching entries should be exported.


This is indeed right. I fixed it in the current SVN revision #1741.
icon7.gif   Spell check, posted by David Egolf on Mon Nov 6 17:13:19 2006 
Sorry if this has been asked.

Is there a spell check that can be implemented in Elog or any recommended add on spell check?

Thanks,

David Egolf
    icon2.gif   Re: Spell check, posted by Stefan Ritt on Mon Nov 6 17:18:04 2006 

David Egolf wrote:
Is there a spell check that can be implemented in Elog or any recommended add on spell check?


I personally use Mozilla Firefox 2.0 which has already a built in spell checker. For MS IE, you can use IESpell (http://www.iespell.com).
    icon2.gif   Re: Spell check, posted by Fergus Lynch on Mon Nov 6 17:36:35 2006 

David Egolf wrote:
Sorry if this has been asked.

Is there a spell check that can be implemented in Elog or any recommended add on spell check?

Thanks,

David Egolf


I find that the Google spell checker works very well in IE6.
icon4.gif   Interesting behavior with $shell, posted by Steve Jones on Fri Oct 27 19:11:32 2006 
eLog does not do math so I am trying to leverage the $SHELL function to perform the math. I am using GAWK to perform the math -- I started trying to use CONDITIONAL ATTRIBUTES to assign numeric values to attributes but with loading up the ATTRIBUTES with all of the options brings elog to its knees in terms of performance -- the parsing of attributes is simply too string intensive.

So, I embedded the numeric score in the OPTIONS of the ATTRIBUTE and leveraged the text processing prowess of GAWK:
Options WhoIsEffected =   1:...Single User, 5:...Project, 10:...Department, 50:...Site
Options ServiceOutage =   1:...0-1 Minutes, 2:...10 Minutes, 10:...20 Minutes, 30:...30 Minutes, 100:...gt60

Then pass the following command to GAWK:
Preset TotalScore = $shell(gawk 'BEGIN{split(\"$WhoIsEffected:$ServiceOutage\",scores,\":\");print scores[1]+scores[3]}' )

The interesting result is this works - the proper summation is returned but apparently elog parsing also returns everything after the first ')' as something that also needs to be returned. So the resulting contents of TotalScore is 
2;print scores[1]+scores[3]}' )
assuming one chose the first option of both attributes (the output pasted here are real results).

Before getting to this point I tried using the GAWK internal variable of $0 - but this did not work because apparently $0 in elog is defined as the OS shell!

Stefan, is it possible for you to try creating a logbook on the elog demo site that shows people how to perform math and in the process discover what the $SHELL function is doing?
    icon2.gif   Re: Interesting behavior with $shell, posted by Steve Jones on Sun Oct 29 16:04:05 2006 

Steve Jones wrote:
eLog does not do math so I am trying to leverage the $SHELL function to perform the math. I am using GAWK to perform the math -- I started trying to use CONDITIONAL ATTRIBUTES to assign numeric values to attributes but with loading up the ATTRIBUTES with all of the options brings elog to its knees in terms of performance -- the parsing of attributes is simply too string intensive.

So, I embedded the numeric score in the OPTIONS of the ATTRIBUTE and leveraged the text processing prowess of GAWK:
Options WhoIsEffected =   1:...Single User, 5:...Project, 10:...Department, 50:...Site
Options ServiceOutage =   1:...0-1 Minutes, 2:...10 Minutes, 10:...20 Minutes, 30:...30 Minutes, 100:...gt60

Then pass the following command to GAWK:
Preset TotalScore = $shell(gawk 'BEGIN{split(\"$WhoIsEffected:$ServiceOutage\",scores,\":\");print scores[1]+scores[3]}' )

The interesting result is this works - the proper summation is returned but apparently elog parsing also returns everything after the first ')' as something that also needs to be returned. So the resulting contents of TotalScore is 
2;print scores[1]+scores[3]}' )
assuming one chose the first option of both attributes (the output pasted here are real results).

Before getting to this point I tried using the GAWK internal variable of $0 - but this did not work because apparently $0 in elog is defined as the OS shell!

Stefan, is it possible for you to try creating a logbook on the elog demo site that shows people how to perform math and in the process discover what the $SHELL function is doing?




Steve Jones wrote:

So, in order to quickly get around the problem I did the following:
Preset TotalScore = $shell(echo \"$WhoIsEffected:$ServiceOutage\" | gawk -f <gawkscript>' )

This works since all of the script logic is contained in an external script but removes the logic from the elog config, so if anything changes one has to remember to change the script (which is in a comment).
icon5.gif   Error Sending Email, posted by Ibrahim Genc on Thu Oct 12 16:22:40 2006 
I've set up all e-mail configuration but I get error message after submitting a message

verbose output is as follows: every parameter I used works in outlook express.

Another question is; Can I change the port number of the smtp server? Some servers use another port than 25.

Thanks so much.
--
ibrahim

------------------------------------------------
Email ALL to genc@xxx.com.tr

timezone: -7200, offset: 10800


Email from genc@xxx.com.tr to genc@xxx.com.tr,genc@xxx.com.tr,, SMTP host
mail.xxx.com.tr:
220 mx-d.xxx.com ESMTP Postfix
EHLO neuron
250-mail-003.xxx.com
250-PIPELINING
250-SIZE 41943040
250-VRFY
250-ETRN
250-AUTH LOGIN PLAIN CRAM-MD5
250-AUTH=LOGIN PLAIN CRAM-MD5
250 8BITMIME
==== Return ================================
HTTP/1.1 302 Found
Server: ELOG HTTP 2.6.2-1722
Connection: Keep-Alive
Keep-Alive: timeout=60, max=10
Location: http://127.0.0.1:8080/PhD/4?error=Error+sending+Email+via+<i>"mail.xxx.com.tr"</i>
    icon2.gif   Re: Error Sending Email, posted by Stefan Ritt on Thu Oct 12 16:34:07 2006 

Ibrahim Genc wrote:
I get error message after submitting a message


Your verbose output seems to be only partial. I have modified the verbose output recently, so please update to a more recent version of elog. With 2.6.2-3 I get for example
Email from stefan.ritt@psi.ch to stefan.ritt@psi.ch, SMTP host xxx.psi.ch:
220 xxx.psi.ch xxxvs01 Thu, 12 Oct 2006 16:25:17 +0200
HELO xxx.psi.ch
250 xxx.psi.ch Hello [129.129.xxx.xxx]
MAIL FROM: stefan.ritt@psi.ch
250 2.1.0 stefan.ritt@psi.ch....Sender OK
RCPT TO: <stefan.ritt@psi.ch>
250 2.1.5 stefan.ritt@psi.ch
RCPT TO: <stefan.ritt@psi.ch>
250 2.1.5 stefan.ritt@psi.ch
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Date: Thu, 12 Oct 2006 16:25:17 +0200
To: "Stefan Ritt" <stefan.ritt@psi.ch>
From: Stefan Ritt <stefan.ritt@psi.ch>
User-Agent: Elog Version 2.6.2
Subject: Updated ELOG entry
X-Elog-URL: http://localhost:8080/demo/1
X-Elog-submit-type: web|elog
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

... here comes the complete email body ....

.
250 2.6.0 <xxx.psi.ch> Queued mail for delivery
QUIT
221 2.0.0 xxx.psi.ch Service closing transmission channel
==== Return ================================
HTTP/1.1 302 Found
Server: ELOG HTTP 2.6.2-1724
Connection: Keep-Alive
Keep-Alive: timeout=60, max=10
Content-Length: 20

This is of course without SMTP username. Our mail server does not support SMTP username, so I programmed this kind of "blindly".



Ibrahim Genc wrote:
Another question is; Can I change the port number of the smtp server? Some servers use another port than 25.


All server I met so far were running on port 25, so I hardcoded this in elogd.c. You can change it in the source code at line 2119:
bind_addr.sin_port = htons((short) 25);

If more people ask for this, I can make it a parameter.
       icon2.gif   Re: Error Sending Email, posted by Ibrahim Genc on Thu Oct 12 17:42:37 2006 

Stefan Ritt wrote:

Ibrahim Genc wrote:
I get error message after submitting a message

Your verbose output seems to be only partial. I have modified the verbose output recently, so please update to a more recent version of elog. With 2.6.2-3 I get for example


I downloaded the latest version just yesterday. I checked again now; it is version 2.6.2-3. I'll wait some time for release of new build of windows binaries. Mine differs from yours as a one build number only.

Thanks for prompt answer.
       icon2.gif   Re: Error Sending Email, posted by Ibrahim Genc on Fri Oct 13 23:17:05 2006 

Stefan Ritt wrote:

Ibrahim Genc wrote:
I get error message after submitting a message


Your verbose output seems to be only partial. I have modified the verbose output recently, so please update to a more recent version of elog. With 2.6.2-3 I get for example
Email from stefan.ritt@psi.ch to stefan.ritt@psi.ch, SMTP host xxx.psi.ch:
...

Now I installed 262-4 but no change. communication seems to be stopped at the same point.


Stefan Ritt wrote:

This is of course without SMTP username. Our mail server does not support SMTP username, so I programmed this kind of "blindly".


There is a free e-mail service at mail.softhome.net. It provides smtp and pop3 services. You can use this for testing if you want.

Saluts.
--
ibrahim
          icon2.gif   Re: Error Sending Email, posted by Stefan Ritt on Mon Oct 16 08:57:07 2006 

Ibrahim Genc wrote:
There is a free e-mail service at mail.softhome.net. It provides smtp and pop3 services. You can use this for testing if you want.


I tried but I was unable to obtain a free account. Furthermore, the problem is probably related to your SMTP server's authentication method. There are many methods and ELOG only supports a subset. So I would have to try with your specific SMTP server. So the only recommendation I can give you is to find an SMTP server without authentication. That one will certainly work with elog.
             icon2.gif   Re: Error Sending Email, posted by An Thai on Wed Oct 25 17:20:27 2006 

Stefan Ritt wrote:

Ibrahim Genc wrote:
There is a free e-mail service at mail.softhome.net. It provides smtp and pop3 services. You can use this for testing if you want.


I tried but I was unable to obtain a free account. Furthermore, the problem is probably related to your SMTP server's authentication method. There are many methods and ELOG only supports a subset. So I would have to try with your specific SMTP server. So the only recommendation I can give you is to find an SMTP server without authentication. That one will certainly work with elog.




Dear all WINDOWS users,

Good news.
you can send email to any SMTP server with authentification !!! Just install component Windows IIS (Internet Information Services). You need the Windows Professional installation CD to install it.

How it works:
ELOG -> Default SMTP Virtual Server -> SMTP with authentification (your email provider/ company mail server)


How to configurate Default SMTP Virtual Server:

Right mouse click on icon My Computer -> Manage
Expand Services and Apllications -> IIS
Right mouse click on Default SMTP Virtual Server -> Properties
Select Delivery tab
Click the button Outbound Security ->Select Basic authentification and enter your user/password which you got from your Email-provider/Company -> OK
Click the button Advanced... -> type your SMTP host in the fields "smart host" and "Full-qualified... ", i.e. smtp.gmx.net

(Don't forget to check the tab Access -> Connection and Relay buttons -> Select "All accept the list")



How to configurate your Elog.cfg file:
SMTP host = xxxx

Normally xxxx is your personal computer name by right click on the icon "My Computer" -> Properties -> Tab "Computer Name"
OR
xxxx: the name what you see by expand Services and Apllications -> IIS -> Default SMTP Virtual Server -> Domains -> Domain Name


GOOD LUCK
icon5.gif   Text column in the main list, posted by Alexandre Lindote on Fri Oct 20 13:26:10 2006 
Hi,

is there a way of removing the "Text" column from the main listing of a logbook?
I have a logbook that works as a document database, and I don't even allow the entering of text... But the column insists on appearing! Smile

Thanks

Alex
    icon2.gif   Re: Text column in the main list, posted by Stefan Ritt on Fri Oct 20 13:28:38 2006 

Alexandre Lindote wrote:
Is there a way of removing the "Text" column from the main listing of a logbook?
I have a logbook that works as a document database, and I don't even allow the entering of text... But the column insists on appearing! Smile


Summary lines = 0
       icon2.gif   Re: Text column in the main list, posted by Alexandre Lindote on Fri Oct 20 13:36:29 2006 

Stefan Ritt wrote:

Alexandre Lindote wrote:
Is there a way of removing the "Text" column from the main listing of a logbook?
I have a logbook that works as a document database, and I don't even allow the entering of text... But the column insists on appearing! Smile


Summary lines = 0


Great! Thanks a lot

Alex
Goto page Previous  1, 2, 3 ... 168, 169, 170 ... 236, 237, 238   Next  
ELOG V3.1.5-3fb85fa6