Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 97 of 808  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Show attachments  Show only new entries    6457 Entries 
Goto page Previous  1, 2, 3 ... 96, 97, 98 ... 806, 807, 808   Next  
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  87   Tue Jul 30 17:33:24 2002 Question momsheikh25@hotmail.comQuestion  Scroll box for attributes
Hello,
   If you have the text box turned off so you only enter attributes, is it 
possible to have a couple of attributes that have small scroll through text 
boxs of a couple of lines rather than just one line?   Like not as big as 
the regular text box but something small to be able to post a couple of 
lines in and if it gets bigger then you scroll down.  For instance if you 
are posting a problem and a solution just have one small text box for the 
problem and one for the solution.

Thanks,
Mo
  68210   Mon Dec 14 04:42:04 2015 Entry Dawangraymund.dawang@gmail.comRequestWindowsLatestSample of actual elog Config with URL in SSL

HI Guys,

Can you please give me an idea how will I write in the config. I want my elog will be accessed via internet. Though there's a tutorial / guideline, I need an actual config file for me to easily grasp how the URL = xxx should be write. Do my port should be Port = 433 and SSL=1?

Thanks,

 

Raymund

  2021   Thu Oct 26 21:54:40 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714SVN1723-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.

  2050   Wed Nov 8 08:20:34 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714SVN1723-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 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714SVN1723-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 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714SVN1723-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.
  1939   Mon Sep 18 20:35:44 2006 Warning Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714SVN1714 will not run in 'daemon" mode on Solaris8
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"
  69154   Fri Jun 5 03:49:20 2020 Entry Hisataka YOSHIDAhisataka@rcnp.osaka-u.ac.jpBug reportLinux3.1.4-2SSL does not work

Hello.

I installed the latest elog (3.1.4-2) in CentOS 7, and it is working well without SSL.
When I enalbled SSL option (SSL = 1) in the "elogd.cfg", and tried to start the elogd, the message below was shown and failed to run.

SSL support not compiled into elogd

If I switched the elog to older one (3.1.4-1), I could successeed to run the elogd with SSL option.
Is there any other option required in the latest elog to run with SSL? Or is this bug in the latest version?

Thank you,
Hisataka YOSHIDA

Goto page Previous  1, 2, 3 ... 96, 97, 98 ... 806, 807, 808   Next  
ELOG V3.1.5-3fb85fa6