Noted. Thank you for your time

In a configuration with elog running (8080) under Apache (80) [as explained in admin guide], what is the syntax for tunnelling in with ssh, of both the ssh command and the browser locator?

Maybe some more information will help with the question.  Here's the results of my playing around with URL = /host.domain/subdir in elog.cfg.  Commented out, I can access locally with http://localhost:8080 and tunnelled (1234:host.domain:8080) with http://localhost:1234, with and without Apache (i.e., Apache is bypassed?).  URL = /host.domain/elog in elog.cfg works locally with browser locator localhost:8080 (of course), localhost/elog, and host.domain/elog, but the tunnel directly to 8080 no longer works, nor does http://localhost:4321/elog (even though this ends up showing the same URL on the remote browser as on the local browser) (4321:host.domain:80).  http://localhost:4321 brings up the Apache window.  Every other URL assignment I tried failed both locally and remotely, so, I assume the ssh tunnel directive is wrong, or the browser locator, or maybe still URL = .  Anyway, my question is, what am I doing wrong?

Is there a way to distribute e-mail based on the consideration of several attributes and values?  A simple example:  attributes type and category have several different values, say, routine and problem for type and hardware and software for category, but one would only like messages sent when there's a problem to different sets of hardware or software types.  Thus:

Email

type routine   category hardware = no message

                        category software = no message

type problem  category hardware =  a@bcd.efg, h@ijk.lmn

                         category software = 1@opq.rst, 2@uvw.xyz

Is there anything I can do about this?

kernel:  2.6.32-279.14.1.el6.x86_64

ldd (GNU libc) 2.12

/lib64/libc.so.6

/usr/lib64/libssl.so.10

rpm -i elog-latest.i386.rpm

error: Failed dependencies:

libc.so.6 is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.0) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.1) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.1.3) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.3) is needed by elog-3.1.1-1.i386

libssl.so.6 is needed by elog-3.1.1-1.i386

Is there anything I can do about this?

kernel:  2.6.32-279.14.1.el6.x86_64

ldd (GNU libc) 2.12

/lib64/libc.so.6

/usr/lib64/libssl.so.10

rpm -i elog-latest.i386.rpm

error: Failed dependencies:

libc.so.6 is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.0) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.1) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.1.3) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.3) is needed by elog-3.1.1-1.i386

libssl.so.6 is needed by elog-3.1.1-1.i386

I attempted instead to build from the tar ball, and, except for a "fatal" git error, make built elogd, elog, and elconv.  I put the first in /usr/local/sbin, and the latter two in /usr/local/bin, and then restarted elogd, but this didn't work:

Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

So, I backed these out and restored the previous executables, and access to the elog was restored, and the elogd.cfg accessed is the original one, but all logbooks are empty and requiring authentication.  The logbook directories still contain all the old entries, so I'm not sure what has happened.

Thanks for your advice.

Phil

OK.  I found the source of the logbook problem in an exchange from May 2015, so no need to answer this one.

But I would like to be able to upgrade to 3.x from 2.9, so any help with this will be much appreciated.

Phil