Re: "Logkook dir" in top group [global] section ineffective, posted by Stefan Ritt on Mon Jan 9 20:09:16 2006
|
| Yoshio Imai wrote: | One strange thing (maybe it isn't strange at all) is the following behaviour: when the list view is set to "summary", then the line containing the entry where we clicked "list" is highlighted, however when the list view is set to "full", it isn't. Is this "a bug, or a feature"?  |
Was a bug. I have fixed that in revision 1591. |
|
Re: HelpELCode needs to be present in "Menu commands"?, posted by Stefan Ritt on Mon Jan 9 20:19:32 2006
|
| T. Ribbrock wrote: | | Another little issue I came across was this: I'm using "Menu commands" and "Guest Menu commands" in my configuration. When I logged in and started to create a new entry, clicking on the URL that is behind "ELCode" at the bottom of the screen (and accesses the help for the ELCodes) resulted in a "command denied". The only way to get around this was to add "HelpELCode" to "Menu commands" - but now it also shows up in the menus, which is not what I want. Is there any way around this? |
Thanks for reporting that problem. I fixed that in revision 1592. |
|
Re: MS Fonts only in ELCode options?, posted by Stefan Ritt on Mon Jan 9 20:53:28 2006
|
| T. Ribbrock wrote: | I'm just after installing 2.6.0 and marvelling at all the changes, especially ELCode (I was using 2.5.8 previously). However, I noticed that the "FONT" menu for ELCodes only offers Microsoft fonts  - something I usually avoid like hell when publishing web content, as I cannot rely on those being installed on the clients. As far as I can see there is no easy way to change this, short of patching the source - or is there?
I'd want to add at least options like "serif" and "sans-serif" and maybe some standard (Unix\?) fonts like "Helvetica". |
In revision 1593 I implemented a "Fonts = ..." option where you can specify a list of fonts to be shown on the list. I tried however the MS set of fonts on a Linux system, and found that the MS fonts got mapped to Unix fonts in a reasonable way. Even the Comic Sans MS font was avalilable. |
|
Re: MS Fonts only in ELCode options?, posted by T. Ribbrock on Tue Jan 10 10:42:18 2006
|
| Stefan Ritt wrote: |
In revision 1593 I implemented a "Fonts = ..." option where you can specify a list of fonts to be shown on the list. I tried however the MS set of fonts on a Linux system, and found that the MS fonts got mapped to Unix fonts in a reasonable way. Even the Comic Sans MS font was avalilable. |
Very nice, thanks! Yes, vou're right, MS fonts have a chance of working on newer Linux distributions, but not on all and there are still older ones out there - never mind all those folks sitting behind some kind of Solaris/Sparc box or similar...  |
Re: Problems with ELOG and Internet Explorer, posted by Elaine Cristina Franchini dos Anjos on Fri Jan 13 18:43:08 2006 
|
Hi Stefan,
I couldn't solve this problem yet...
I have been tried a lot of configurations, but our Elog doens't work well in IE with https 
It works very well to read, list, find the messages, delete, and so on...
But all users have problems with edit and preview commands when they are using IE + https.
When we use Elog in IE without https, everything works fine. ?)
We are using :
httpd-2.0.54
Fedora Core release 1 (Yarrow)
elog-2.6.0
The redirect directive in httpd.conf:
<VirtualHost xxx.xxx.xx.xx>
ServerAdmin our.email.address
DocumentRoot /www/apache/htdocs
ServerName our.server.name
# Rules to new elog 2.6.0
Redirect / https://our.server.name:9898
ErrorLog logs/error_log
CustomLog logs/access_log common
</VirtualHost>
The proxy directives in ssl.conf:
(We used the http://midas.psi.ch/elogs/contributions/11 message like reference.
Thanks a lot for the contribution!!!  )
<VirtualHost xxx.xxx.xx.xx:9898>
# Here be standard configuration for the Virtual Host
ServerName our.server.name:9898
ServerAdmin our.email.address
RequestHeader set Front-End-Https "On"
# This be the path to the elog directory
# (This didn't seem to make any difference, but it be a good
# idea nonetheless)
DocumentRoot "/www/src/elog-2.6.0"
# Here be the setup for the SSL component of the Virtual Host
SSLEngine On
SSLCertificateFile /www/apache/conf/ssl.crt/server.crt
#SSLCertificateKeyFile /www/apache/conf/ssl.key/server.pem
SSLCertificateKeyFile /www/apache/conf/ssl.key/server.key
# Here be the setup options for the Proxy module
ProxyRequests Off
ProxyPreserveHost On
# This be the root of the new Virtual Host, and it should be
# redirected to the port the elogd server is listening to
# (8082 on our poop deck).
<Location />
ProxyPass http://our.server.name:8082/
ProxyPassReverse http://our.server.name:8082/
SSLRequireSSL
</Location>
ErrorLog /www/apache/logs/error_log
TransferLog /www/apache/logs/access_log
</VirtualHost>
And the URL is configured in elogd.cfg like your suggestion (Thanks ! )
URL = https://our.server.name:9898
The elgod.cfg is attached to this message to add more details about our configuration.
Thanks in advance.
Regards,
Elaine
| Stefan Ritt wrote: |
| Elaine Cristina Franchini dos Anjos wrote: | | I edited and used preview many times and the ELOG worked fine without errors in IE. So, I think my problem is something configured in the proxy or https that Internet Explorer doesn't work very well in this circumstance. |
Have a look at your URL = ... statement in elogd.cfg
It should probably read
URL = https://antares.ccuec.unicamp.br:9696
ELOG uses redirection internally. To determine it's own address, it uses the URL statement. If you use Apache as an proxy together with https, you have to specify the URL under which you usually access ELOG from outside. If this is wrong, ELOG might try to redirect to http:// or something which might not be possible.
A good way to debug this is to run ELOG with the -v flag and carefully watch the HTTP traffic. You will see Location: ... statements which redirect the browser, then the browser will access the redirected URL (if it's correct), or you will see nothing (in case the browser tries to access a non-existing URL). |
|
Attribute substitution in email configuration, posted by Adam Blandford on Wed Jan 18 02:22:44 2006
|
In the logbook config file I am not able to use attribute substitution in the <string> tag forUse Email Heading = <string> Attribute substitution does work however forUse Email Subject = <string> e.g.Use Email Subject = ELOG $logbook entry; $Category: $Subject will result in an email subject of: "ELOG Forum entry; Bug Report; Attribute substitution in email configuration"
Use Email Heading = A new entry has been submitted by $long_name on $remote_host on $date will result in an email heading of: "A new entry has been submitted by $long_name on $remote_host on $date"
Not sure if this functionality is intended or is a bug. An comment/feedback/suggestion would be appreciated. |
|
Re: Attribute substitution in email configuration, posted by Stefan Ritt on Wed Jan 18 13:06:50 2006
|
| Adam Blandford wrote: | | Not sure if this functionality is intended or is a bug. |
It was not implemented, however you call this
I added that in the current SVN version, so it will be contained in the next release. |
|
Re: Problems with ELOG and Internet Explorer, posted by Stefan Ritt on Wed Jan 18 13:31:32 2006
|
Have you tried another browser, like Firefox? Do you have the same problems with Firefox? Can you try the following:
Start elogd manually with the "-v" flag, like
elogd -c <your config path> -v -p 8080 and watch the output carefully. When you submit an entry, elogd does redirection. You will see that in the HTTP header you have an entry like
...
Location: https://...
... This location is taken from the URL statement of your config file. If it's wrong (like if you mixed http:// and https://), your browser will try to load the page from a non-existion location. |