| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
67884
|
Wed May 6 15:13:11 2015 |
 | Christof Hanke | hanke@rzg.mpg.de | Bug fix | All | 3.1.0 | parse a correctly the username in save_user_config when using Webserver authentication |
Hi Stefan,
When we use Webserver authentication, we have the correct username already in the variable http_user.
The old way of copying this http_user to "user" is wrong since we don't use the size of http_user.
Instead, just encode the http_user variable directly.
See attached patch against git HEAD.
Christof
|
| Attachment 1: parse_http_user_correctly.patch
|
diff --git a/src/elogd.c b/src/elogd.c
index 601639c..de4734b 100755
--- a/src/elogd.c
+++ b/src/elogd.c
@@ -13142,12 +13142,13 @@ int save_user_config(LOGBOOK * lbs, char *user, BOOL new_user)
/* if we outsourced the authentication, use external username */
getcfg(lbs->name, "Authentication", str, sizeof(str));
- if ( stristr(str, "Webserver")) {
- strlcpy(user, http_user, sizeof(user));
- }
/* do not allow HTML in user name */
- strencode2(user_enc, user, sizeof(user_enc));
+ if ( stristr(str, "Webserver")) {
+ strencode2(user_enc, http_user, sizeof(user_enc));
+ } else {
+ strencode2(user_enc, user, sizeof(user_enc));
+ }
/* check for user name */
if (!isparam("new_user_name") || *getparam("new_user_name") == 0) {
|
|
67906
|
Thu May 14 02:35:15 2015 |
 | Francois Cloutier | Francois@fcmail.ca | Question | Windows | 3.1.0 | Elogd synchronisation with remote server |
I came accross the admin guide and I was reading / searching for a way to sync logbooks across sites...
elogd mention "-m" and "-M" ... not elog but elogd... with that description :
synchronize logbook(s) with remote server
Does it sync all logbooks ? is there any examples somewhere or advice ?
Thanks :) |
|
67909
|
Thu May 14 05:13:34 2015 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Question | Windows | 3.1.0 | Re: Elogd synchronisation with remote server |
> I came accross the admin guide and I was reading / searching for a way to sync logbooks across sites...
> elogd mention "-m" and "-M" ... not elog but elogd... with that description :
> synchronize logbook(s) with remote server
If you would have followed the shown link to the "elogd.cfg syntax page", you would have found the chapter Mirroring:
https://midas.psi.ch/elog/config.html#mirroring
> Does it sync all logbooks ?
Not necessarily, but that is the default.
> is there any examples somewhere or advice ?
See above: you'll find examples under #mirroring
> Thanks :)
You're welcome. |
|
67915
|
Wed May 20 01:45:09 2015 |
 | Konstantin Olchanski | olchansk@triumf.ca | Bug report | Linux | 3.1.0 | elogd complains about unknown cookies |
elogd is spewing these messages about unknown cookies:
Received unknown cookie "is_returning"
Received unknown cookie "__utma"
Received unknown cookie "__utmz"
Received unknown cookie "SSESSee3cc9c70bedf9a840203765bf409d7b"
Received unknown cookie "SESSee3cc9c70bedf9a840203765bf409d7b"
Received unknown cookie "MidasWikiUserID"
Received unknown cookie "MidasWikiUserName"
Received unknown cookie "MidasWiki_session"
K.O. |
|
67916
|
Wed May 20 01:49:37 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Linux | 3.1.0 | elconv deletes everything |
Converting from elog 2.9.something to new elog 3.1.0 elogd refuses to start, instructs running elconv in one logbook.
When I do so, elconv converts a existing mhttpd-style elog entries to the new format (the corresponding new-format entries already exist)
and deletes everything else - this is very bad.
So there are 2 bugs:
- elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist
- elconv should not delete all existing new-style elog entries.
I confirm that elconv *does* delete all new-style elog entries - with strace, I see it issue "unlink" on every elog entry.
What a disaster!
K.O. |
|
67919
|
Wed May 20 01:59:17 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Linux | 3.1.0 | elogd moves elog entries |
elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
in the release announcement and in the release and migration notes. K.O. |
|
67920
|
Wed May 20 11:59:59 2015 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 3.1.0 | Re: elogd moves elog entries |
> elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> in the release announcement and in the release and migration notes. K.O.
That feature is one of the main reasons why the version jumped from 2.x to 3.x.
A free tip: changes in major revisions do indicate some kind of incompatibility.
But yes, the release documentation by bitbucket is not really that useful:
it is difficult for me too, to find out what changed with new releases.
I have to admit here, that I haven't read any GIT tutorial yet.
By the way: you are welcome to contribute to the release documentation!
On your actual problem: to go back to a former version of ELOG you can simply
- stop elogd 3.X,
- move all entries from the sub-directories one level up, and
- start the 2.X version of elogd.
I wouldn't really call this an "incompatibility", would you?
At least you can easily go back without much trouble.
Cheers
Andreas |
|
67921
|
Wed May 20 12:52:31 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 3.1.0 | Re: elogd moves elog entries |
> > elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> > in the release announcement and in the release and migration notes. K.O.
>
> That feature is one of the main reasons why the version jumped from 2.x to 3.x.
> A free tip: changes in major revisions do indicate some kind of incompatibility.
> But yes, the release documentation by bitbucket is not really that useful:
> it is difficult for me too, to find out what changed with new releases.
> I have to admit here, that I haven't read any GIT tutorial yet.
> By the way: you are welcome to contribute to the release documentation!
>
> On your actual problem: to go back to a former version of ELOG you can simply
> - stop elogd 3.X,
> - move all entries from the sub-directories one level up, and
> - start the 2.X version of elogd.
>
> I wouldn't really call this an "incompatibility", would you?
> At least you can easily go back without much trouble.
>
> Cheers
> Andreas
Stefan told me that the change was because some users were having thousands of yymmdda.log files
in the logbook directories, and that sorting them into subdirectories by year at least did something to bring some
order. Possibly to get around the lazy archivers, I suspect.
When I first tried v3.0, I wanted to go back due to some bug or feature, and had to do exactly what Andreas suggested above.
David. |