ELOG Forum

Demo Discussion

Forum Config Examples Contributions Vulnerabilities

Discussion forum about ELOG, Page 168 of 238

Not logged in

Find | Login | Help

Full | Summary | Threaded | Collapse | Expand

1898 Entries

Goto page Previous 1, 2, 3 ... 167, 168, 169 ... 236, 237, 238 Next

suggestion for "new user registration" page, posted by Mark Bergman on Sat May 6 02:12:10 2006

I'm testing elog, and one user was having difficulty creating a new account for himself. This problem had three reasons:

1. the user expected a "submit" button or some other way to exit the account registration screen to appear near the password boxes, at the bottom of the page.

2. I'm using the "Bottom text" option, which has a URL to execute a "find" (search) within elog for all open tickets. The user simply entered the info for their new account, and then clicked on the button at the bottom of the page--which would be the expected behavior.

3. In our environment, there are many logbooks (~100), as each computing device has it's own logbook. This isn't a problem on the main page, since the logbooks are grouped into 7 categories. However, the account registration page combines two functions--setting up a new account, and selecting which logbooks to subscribe to for e-mail notification. The logbooks are presented in a list (rather than groups), which causes the "Save" button at the top left to scroll off the screen before the user enters their password.

Suggestions for improving the registration page:

Put a "submit" button after the password entry.

Possibly supress the local "bottom text", or allow the specification of a different file for the registration page.

After the user has registered, then show a page allowing them to subscribe for e-mail notifcation. That page should be organized the same way as the main page, with groups. Users should be allowed to subscribe to entire groups, or to expand each group to select or unsubscribe from individual logbooks.

Thanks,

Mark

Re: suggestion for "new user registration" page, posted by Stefan Ritt on Thu Nov 9 22:40:06 2006

Mark Bergman wrote:

Suggestions for improving the registration page:

Put a "submit" button after the password entry.

Possibly supress the local "bottom text", or allow the specification of a different file for the registration page.

After the user has registered, then show a page allowing them to subscribe for e-mail notifcation. That page should be organized the same way as the main page, with groups. Users should be allowed to subscribe to entire groups, or to expand each group to select or unsubscribe from individual logbooks.

Thanks,

Mark

I put the "save" button below the password entry and removed the "bottom text", I hope this helps a bit.

Problem with large entry size, posted by Dimitrios Tsirigkas on Mon Oct 16 16:20:06 2006

Hi Stefan,

I have posted an entry of approximately a thousand lines (ten thousand words). Posting it took some time, which is logical to a certain degree. However, whenever a user asks for "Full" view of the logbook, the page takes around two minutes to load and the CPU usage on the elog server goes to beyond 90% for all this time. Is this to be expected for an entry of that size or is there something going wrong here?

Thanks,
Dimitris

Re: Problem with large entry size, posted by Stefan Ritt on Mon Oct 16 16:53:43 2006

Dimitrios Tsirigkas wrote:

I have posted an entry of approximately a thousand lines (ten thousand words). Posting it took some time, which is logical to a certain degree. However, whenever a user asks for "Full" view of the logbook, the page takes around two minutes to load and the CPU usage on the elog server goes to beyond 90% for all this time. Is this to be expected for an entry of that size or is there something going wrong here?

The problem lies in the ELCode parsing. When you post an entry in ELCode form, the elogd server has to parse every word to see if it's any of the ELcode tags. This is right now implemented in a kind of poor way, such that it takes very long for long entries. I will work to optimize that. In the meantime, it will help if you post such long entries just in "plain" form.

- Stefan

Re: Problem with large entry size, posted by Stefan Ritt on Mon Oct 16 17:18:58 2006

I improved the performance by some factor in SVN revision 1733. Can you give it a try and report your speed improvement? Depending on the result, I can probably do even a bit better with some more effort.

- Stefan

Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Mon Oct 16 17:32:58 2006

Stefan Ritt wrote:

Dear Stefan,

Thank you for your quick reply. I will install the new version and I will let you know as soon soon as possible.

Best,
Dimitris

Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Tue Oct 17 14:39:29 2006

Stefan Ritt wrote:

Hi again,

I was wondering what is the cleanest way of changing old entries already submitted in ELCode into plain text. If I do not include ELCode in the allowed encodings does this apply to already submitted entries as well or will they still be treated as ELCode?

Thanks,
Dimitris

Re: Problem with large entry size, posted by Stefan Ritt on Tue Oct 17 14:42:58 2006

Dimitrios Tsirigkas wrote:

I was wondering what is the cleanest way of changing old entries already submitted in ELCode into plain text. If I do not include ELCode in the allowed encodings does this apply to already submitted entries as well or will they still be treated as ELCode?

The encoding is stored as an "invisible" attribute in each entry. You can change it in two ways:

1) Select each entry, click "edit", change the encoding with the radio buttons at the bottom and submit it again

2) Go and edit directly the xxxxxxa.log files in your logbook directory. You will see in those files something like

Encoding: ELCode

and you can change it with an editor to

Encoding: plain

Afterwards you have to restart the elogd daemon.

Did you try the new version, would be interesting to see if it's any better...

Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Tue Oct 17 14:47:53 2006

Thanks Stefan,

Stefan Ritt wrote:

Did you try the new version, would be interesting to see if it's any better...

I didn't find the time to try it yet but I will do that later today. I will keep you posted - more soon.

Cheers,
Dimitris

Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Mon Oct 23 12:53:08 2006

Hi Stefan,

A lot of performance-related trouble for us comes from the ability of users to click on "All" and display thousands of entries on the same page. Is there a way to disable that? Even if the ELCode parsing performance of Elog increases greatly, the combination of "Full" mode and "All" will still cause trouble, will it not?

Thanks,
Dimitris

Re: Problem with large entry size, posted by Stefan Ritt on Tue Oct 24 21:58:54 2006

Dimitrios Tsirigkas wrote:

What about a threshold for the "All" display? If a logbook contains less than, let's say, 500 entries, the "All" link is displayed, and above 500 entries it's hidden. Would that make sense?

Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Thu Nov 2 10:14:11 2006

Stefan Ritt wrote:

What about a threshold for the "All" display? If a logbook contains less than, let's say, 500 entries, the "All" link is displayed, and above 500 entries it's hidden. Would that make sense?

Hi Stefan,
Sorry for the late response, I was away for a few days. Yes, I think that this would make perfect sense, especially if the maximum number of entries was configurable.
Cheers,
Dimitris

Re: Problem with large entry size, posted by Stefan Ritt on Thu Nov 9 21:22:27 2006

Dimitrios Tsirigkas wrote:

Stefan Ritt wrote:

What about a threshold for the "All" display? If a logbook contains less than, let's say, 500 entries, the "All" link is displayed, and above 500 entries it's hidden. Would that make sense?

Hi Stefan,
Sorry for the late response, I was away for a few days. Yes, I think that this would make perfect sense, especially if the maximum number of entries was configurable.
Cheers,
Dimitris

Agree. So I implemented the new config option All display limit. The default is 500. So you can see that at this forum, the All link is not shown any more, since the logbook contains more than 500 entries. The promised performance improvement of the page display will take me some more time, but I will not forget it.

ELCode, posted by Alexandre Lindote on Wed Oct 25 18:00:24 2006

Hi,

can you think of any obvious reason why the ELCode would not work in the logbooks I set up?
I can use it here, on the forum, and on the DEMO logbook, but not on the ones I created...
Oh, and me inserting "Allowed encoding = " whatever in the config file doesn't seem to mater as well... I always get the 3 options!
Am I missing a flag somewhere?
The config file for this logbook is below...

Thanks a lot

Alex

Theme = default
Page Title = ZEPLIN-III Idiot's Guide
Comment = ZEPLIN-III Idiot's Guide - test phase
Subdir = idiots_guide
Time format = %A, %B %d, %Y, %H:%M
Date format = %A, %B %d, %Y
Menu commands = List, New, Edit, Delete, Download, Find, Last day, Config, Admin, Login, Logout, Help
Display mode = summary
Preset Author = $long_name
Attributes = Author, Type, Subject
Options Type = Software, Hardware
Required Attributes = Author, Type, Subject
Reverse sort = 1
Quick filter = Type, Subject
List Display = Edit, Type, Subject, Author, Date

;define zeplin3 as a user who can enter and read entries, but not modify
;or create new entries
;Deny New = zeplin3
;Deny Edit = zeplin3
;Deny Reply = zeplin3
;Deny Delete = zeplin3
Deny Config = zeplin3
;Deny CSV Import = zeplin3

;define that only the administrator will see the Admin link
Allow Admin = alex

;Remove email notification for now. There's no SMTP server working...
Suppress default = 3
Suppress Email on edit = 3

;show or hide the mode menu
Mode commands = 0

;With this option, an entry being edited by another user becomes red
;Use Lock = 1

;allow only html and text entries for now
Allowed encoding = 3
Default encoding = 1

Re: ELCode, posted by Stefan Ritt on Wed Oct 25 19:44:11 2006

Alexandre Lindote wrote:

can you think of any obvious reason why the ELCode would not work in the logbooks I set up?

There is a good reason why this forum contains a ELOG Version tag which you are supposed to fill out for new entries. Without knowing which version you are using I cannot help you. Probably you have an old version which does not support the Allowed encoding.

Re: ELCode, posted by Alexandre Lindote on Wed Oct 25 21:52:13 2006

Stefan Ritt wrote:

Alexandre Lindote wrote:

can you think of any obvious reason why the ELCode would not work in the logbooks I set up?

Sorry about that... it's 2.6.2-1699, so a very recent one.

Re: ELCode, posted by Alexandre Lindote on Fri Oct 27 13:02:50 2006

Alexandre Lindote wrote:

Hi,

can you think of any obvious reason why the ELCode would not work in the logbooks I set up?

Ok, I think I found the problem... For some reason the elcode.js file was only in /usr/local/elog/scripts, but it was supposed to be in
/usr/local/elog/themes/default/ as well.
Creating a symlink between the two solved that problem. I can now do most things with the ELCode, but inserting images is still failing. I get this message from the firefox javascript console:

text.value has no properties (line 32 of elcode.js)

Any thoughts?

Alex

Re: ELCode, posted by Stefan Ritt on Thu Nov 9 21:03:03 2006

Alexandre Lindote wrote:

Hi,

can you think of any obvious reason why the ELCode would not work in the logbooks I set up?

That's really strange. In the forum (http://midas.psi.ch/elogs/Forum), I have the elcode.js only in /usr/local/elog/scripts, and it works as you can try out yourself. Getting your javascript error might indicate that you have an old version of elcode.js combined with a newer executable of elogd. Try to update it.

calling a shell in the Options tag, posted by Alexandre Lindote on Tue Oct 31 20:05:07 2006

Hi,

is it possible to run a shell script in an "Options" tag, as it is with the "Preset", "Subst", and so on?
I need to have something like this:

Options Update of = $shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)

the script returns a line with comma separated values...

Thanks

Alex

Re: calling a shell in the Options tag, posted by Steve Jones on Tue Oct 31 22:07:06 2006

Alexandre Lindote wrote:

Steve Jones wrote:

Alex, have you tried it? Novel idea!

Re: calling a shell in the Options tag, posted by Alexandre Lindote on Wed Nov 1 09:53:05 2006

Steve Jones wrote:

Alexandre Lindote wrote:

Steve Jones wrote:

Alex, have you tried it? Novel idea!

Yes, I have. It doesn't seem to... Frown

I just get one option, which is the shell line itself.
Something like:

--- Please select ---
$shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)

Cheers

Alex

Re: calling a shell in the Options tag, posted by Stefan Ritt on Thu Nov 9 20:59:01 2006

Alexandre Lindote wrote:

Interesting idea, but substitutions only work for config setting where the documentation explicitly states so. The complete list comes here:

Preset <attibute>
Preset on reply <attribute>
Preset on duplicate <attribute>
Subst <attribute>
Subst on reply <attribute>
Subst on edit <attribute>
Change <attribute>
Email <attribute> <value>
Use email from
Use Email heading
Use Email subject
Bottom text
Top text
Edit page title
Prepend on edit
Append on edit
Append on reply
Quote on reply
Preset text
Page title
RSS title
List page title

Doing shell execution for all configuration settings would slow down the server too much.

Denial of Service Vulnerability of elog 2.6.2-6, posted by Stefan Ritt on Wed Nov 8 13:59:52 2006

Dear ELOG users,

a denial of service vulnerability has been reported which affects all elog versions prior to 2.6.2-7. With a special request one can crash the elogd server, given that one has access either through a public read access or through an account. This vulnerability has been fixed in version 2.6.2-7. It is advised that all sensitive installations of ELOG are being updated.

Stefan Ritt

SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Mon Sep 18 20:35:44 2006

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"

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:

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?

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:

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.

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:

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.

Re: SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Fri Sep 22 22:12:18 2006

Stefan Ritt wrote:

Steve Jones wrote:

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.

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:

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:

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:

Stefan Ritt wrote:

Steve Jones wrote:

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:

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 ***

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.

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.

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.

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.

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

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 =

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.

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

Acknowledged. The problem was that the section between the line

# This [global] section contains settings common to all logbooks

and the real

 [global]

Steve Jones wrote:

ISSUE: The option

Logbook dir =

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.

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:

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.

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

Re: Bug? Password file location changed, posted by David Spindler on Thu Nov 2 18:10:07 2006

David Spindler wrote:

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

Re: Bug? Password file location changed, posted by Steve Jones on Thu Nov 2 23:17:10 2006

David Spindler wrote:

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

Re: Bug? Password file location changed, posted by David Spindler on Fri Nov 3 14:40:36 2006

Steve Jones wrote:

David Spindler wrote:

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!

Re: Bug? Password file location changed, posted by Stefan Ritt on Tue Nov 7 09:22:52 2006

David Spindler wrote:

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.

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

Re: Push button for Menue Command, posted by Stefan Ritt on Tue Nov 7 08:38:57 2006

An Thai wrote:

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.

Goto page Previous 1, 2, 3 ... 167, 168, 169 ... 236, 237, 238 Next

ELOG V3.1.5-3fb85fa6