| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1978
|
Wed Oct 11 08:18:14 2006 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.2-1714 | Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8 |
| 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. |
|
2021
|
Thu Oct 26 21:54:40 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8) |
| 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.
|
|
|
2045
|
Mon Nov 6 19:03:11 2006 |
 | Steve Jones | steve.jones@freescale.com | Request | Other | 2.6.2-1739 | Option to require new user registration to subscribe to ALL logbooks |
Stefan, any chance of having an option that eliminates the ability of new users to pick the logbooks they can register with? I would like to limit this to the "admin" user to pick per individual.
Also, any thoughts to adding a management panel that will the admin user to make global changes to the password file? I do this by bringing it into a text editor and making changes, but it would be nice to do it from the application. |
|
2050
|
Wed Nov 8 08:20:34 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.2-1714 | SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8) |
| 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. |
|
2051
|
Wed Nov 8 12:55:58 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.2-1714 | SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode (was SVN1714 will not run in 'daemon" mode on Solaris8) |
| 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.
|
|
|
2052
|
Wed Nov 8 13:07:31 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.2-1714 | SVN1723-overiding logbook directory causes eLog to bomb when going into daemon mode |
| 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. |
|
2062
|
Thu Nov 9 22:57:38 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Other | 2.6.2-1739 | Re: Option to require new user registration to subscribe to ALL logbooks |
| Steve Jones wrote: | | Stefan, any chance of having an option that eliminates the ability of new users to pick the logbooks they can register with? I would like to limit this to the "admin" user to pick per individual. |
The logbook list new users can register with is exactly the list the users have access to. So if you omit a logbook there, they can later just go to that logbook, hit config, and add themselves. If you want to prevent a user from getting notifications from a logbook, prevent user access to that logbook, like a new top group.
| Steve Jones wrote: | | Also, any thoughts to adding a management panel that will the admin user to make global changes to the password file? I do this by bringing it into a text editor and making changes, but it would be nice to do it from the application. |
Not at the moment. It would take days of work which I don't have right now. Much more than what it takes you editing the password file in an editor  |
|
2066
|
Thu Nov 9 23:37:37 2006 |
| Steve Jones | steve.jones@freescale.com | Request | Other | 2.6.2-1739 | Re: Option to require new user registration to subscribe to ALL logbooks |
| Stefan Ritt wrote: |
| Steve Jones wrote: | | Stefan, any chance of having an option that eliminates the ability of new users to pick the logbooks they can register with? I would like to limit this to the "admin" user to pick per individual. |
The logbook list new users can register with is exactly the list the users have access to. So if you omit a logbook there, they can later just go to that logbook, hit config, and add themselves. If you want to prevent a user from getting notifications from a logbook, prevent user access to that logbook, like a new top group.
| Steve Jones wrote: | | Also, any thoughts to adding a management panel that will the admin user to make global changes to the password file? I do this by bringing it into a text editor and making changes, but it would be nice to do it from the application. |
Not at the moment. It would take days of work which I don't have right now. Much more than what it takes you editing the password file in an editor |
| Quote: |
Hmm, by default all users have access to all logs. What I have setup is an announcement logbook and I would simply like to send to all registered users the email when announcements happen. My thought was to simply not allow people to pick which logbooks to "register" with and default to the Announcements logbook. I went ahead and hacked the password file and simply set all accounts to subscribe to all logbooks 
|
|