| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1747
|
Sat Mar 4 06:04:53 2006 |
 | Steve Jones | steve.jones@freescale.com | Request | All | 2.6.1 | Re: Top Groups and logbook directorys |
| Steve Jones wrote: | I am re-working our elog setup and am seriously looking at using the "Top Group" feature. What I like best is the ability to create [global] configurations for a group (or type) of logbook when I host multiple types on the same server. I also like being able to specify a different password file, etc.
A limitation that I run into is I would really like the actual directory names used for storing the logbooks for the different types to be identical - which isn't possible when all logbooks (regardless of context) exist at the same directory level. For example, I might have:
3 physical locations: ABC, DEF, GHI
For each location I want to maintain two *groups* of logbooks - CircuitTests and BoardTests. What I would like to end up with is:
- CircuitTests
----ABC
----DEF
----GHI
- BoardTests
----ABC
----DEF
----GHI
Under current elog this is not possble as far as I know. Since each logbook is a physical directory, each logbook requires a unique name. The concept of a named [global] area fills the bill for all things but it would be nifty if one could do:
[global circuittests]
Logbook dir = circuittestlogbooks
[global boardtests]
Logbook dir = boardtestlogbooks
I suppose the poorman's way of doing this is for each logbook to do the following:
[ABC]
Subdir = boardtestlogbooks/ABC
[DEF]
Subdir = boardtestlogbooks/DEF
[GHI]
Subdir = boardtestlogbooks/GHI
or something like that, but I was hopic for something a little more integrated - like creating the hierarchical stuff via the GUI. Anyway, this probably sounds like a major overhaul, which definitely wouldn't be worth it unless I have completely missed something glaringly obvious.
Thanks! |
| Steve Jones wrote: | | Perhaps it is best to ignore this -- I went for a workaround that I like. I am running into a few quirky things with Top Group but it is likely due to the fact that I have never used it. |
|
|
1748
|
Sat Mar 4 06:08:29 2006 |
 | Steve Jones | steve.jones@freescale.com | Bug report | All | 2.6.1-1660 | Crafted URL causes elog to coredump |
While playing with TOP GROUP I managed to get elog 2.6.1 1660 on Solaris 9 to coredump. Since I didn't really understand TOP GROUP I tried a URL where I had http://elog.server.com/topgroupname/logbookname. Putting that logbookname at the end caused elog to dump.
Can this be reproduced by others? |
|
1753
|
Mon Mar 6 17:35:52 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.6.1-1660 | Re: Crafted URL causes elog to coredump |
| Stefan Ritt wrote: |
| Steve Jones wrote: | While playing with TOP GROUP I managed to get elog 2.6.1 1660 on Solaris 9 to coredump. Since I didn't really understand TOP GROUP I tried a URL where I had http://elog.server.com/topgroupname/logbookname. Putting that logbookname at the end caused elog to dump.
Can this be reproduced by others? |
No. This forum has the "elog" as the top group, "Forum" as the logbook, so if I write
http://midas.psi.ch/elogs/elog/Forum
it does not crash. |
|
|
1754
|
Mon Mar 6 17:43:11 2006 |
| Steve Jones | steve.jones@freescale.com | Request | All | 2.6.1 | Re: Allow $attributes in "Comment = " option |
| Stefan Ritt wrote: |
| Steve Jones wrote: | | Is it possible to allow $attribute substitutions in the "Comment =" option for logbooks? |
The "Comment =" option for logbooks gives a general comment, like Discussion forum about ELOG for this forum. Since this comment is global, it does not make sense to have $attribute substitution. |
| Quote: | | Ok, just a thought. Thanks |
|
|
1756
|
Mon Mar 6 18:04:39 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.6.1-1660 | Re: Crafted URL causes elog to coredump |
| Stefan Ritt wrote: |
No, the above link just works fine, just click it. |
| Quote: | I was afraid to try  . Ok, then the issue *might* be rev 1660 or perhaps the fact that compiled under Solaris it does this. Any suggestions on how to find out? |
|
|
1757
|
Mon Mar 6 18:06:32 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.6.1-1660 | Re: Crafted URL causes elog to coredump |
| Stefan Ritt wrote: |
No, the above link just works fine, just click it. |
| Quote: | | I was afraid to try . Ok, then the issue *might* be rev 1660. On my production version running 2.5.3 I get the expected "Invalid URL: <name>" box. Any suggestions on how to find out? |
|
|
1758
|
Mon Mar 6 18:36:34 2006 |
 | Steve Jones | steve.jones@freescale.com | Question | All | 2.5.9 | [RESOLVED] eLog Version number as eLog attribute? |
| Steve Jones wrote: |
| Stefan Ritt wrote: |
| Steve Jones wrote: | When a footer is used (via Bottom text = <filename>) eLog no longer displays the eLog version number at the bottom. Is it possible to somehow expose the version/revision as an eLog attribute or have the version still display even when a replacement footer is specified?
Thanks! |
I added that feature, but will not be able to commit it before the next weekend. |
| Quote: | | Not a problem! Thanks |
|
| Steve Jones wrote: | | Works as requested!! |
|
|
1759
|
Mon Mar 6 18:54:32 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | All | 2.6.1-1660 | [UPDATE] Re: Crafted URL causes elog to coredump |
| Steve Jones wrote: |
| Stefan Ritt wrote: |
No, the above link just works fine, just click it. |
| Quote: | | I was afraid to try . Ok, then the issue *might* be rev 1660. On my production version running 2.5.3 I get the expected "Invalid URL: <name>" box. Any suggestions on how to find out? |
|
| Steve Jones wrote: | Ok, here is what I found:
- Now running rev 1671
- Specifying a non-existent logbook with plain URL of elog server: OK, error is caught and reported
- Specifying a non-existent logbook *under* a logbook name: Ok, error is caught.
- Specifying a non-existent logbook under a "Top Group" of the form "This+Is+Top+Group+One" results in no error, elogd crash. Example URLs:
- Results in a program crash under Solaris. Top Groups were not defined under elog 2.5.3.
|
|