How big is your image? I just tried a 5000 x 3600 pixel image (8 MB in size), and it worked fine on the demo logbook.

Stefan

I just test on your Demo logbook. I use a screen-capture tool to create an image which doesn't been saved as a file, the size is 1920*1080(1.8M), then copy it in clipboard, and then paste in text area. Then the web page become very slow, so that I can't submit it sometime. Sometime, I can submit it but it say "Entry text too big. Please increase TEXT_SIZE and recompile elogd". If I drop an image file into the text area, it works. I used IE11.

Ah, that's the difference! I always drop an image on the text area, never paste it. So please refrain from pasting.

Hi,

As mentionned before, we happen to fail to receive email messages related to updates on elog entries at our site. My understanding is that the SMTP header Message-Id MUST be unique for each email message. Whereas all elogd email messages get something like <logbook>-<entryId>@<domain>. See source code. For this header to become unique, there should be a random part in it.

Having the same Message-Id in multiple email messages results in only the first one being delivered on some email systems.

Moreover, elogd sets the In-Reply-To: header in the same manner (<logbook>-<entryId>@<domain>). Which is incorrect because this header relates to email messages, not elog entries, and should contain the email Message-Id of the email message to which it replies, itself handled by the email messaing system. But elogd hasn't received any email messsage in the first place. So I believe this header should simply be dropped.

I think I can provide a pull request on bitbucket for the Message-Id issue, and probably also for the In-Reply-To: if you decide it can be removed.

Cheers

A pull request would be highy appreciated, because you can then test it thoroughly on your side. Adding a random number to the message id is simple. "Reply-to" indeed does not make sense since elog cannot receive emails. Most sites use a generic "noreply@<domain>" to indicate to the user that a reply does not make sense. I guess the "Reply-to" does not have to be unique, right?

Pull-request posted. Cheers.

Pull-request merged.

Hi,
  we are running an elogd (with SSL) server on a machine and using apache as a proxy.

The authentication to the apache server is managed via LDAP module directly by apache, while, so far, we have no authentication enabled in the elogd server itself.
So, when a used want to access the elog server, he is required to provide user/pwd by apache, and then he can access the elogs.

We would like to use the elog command line to transit entries automatically from a terminal from a different host.

the command line we are trying is:

echo "Test" | elog -v -h elog.belle2.org -a Author="stefano" -a Type="Other" -l elog -s demo -u username password  -p 443

where username password are registered into LDAP.

In response we have a 401 Unauthorized. The full return message is at the end of this message.

I suspect that the "username password" we pass to elog are supposed to be that of elogd, not that of apache/ldap: I don't know if this is the case.

Does anyone have an idea how to make this work?

Thanks in advance,
  Stefano

Successfully connected to host elog.belle2.org, port 443
Request sent to host:
POST /elog/ HTTP/1.0
Content-Type: multipart/form-data; boundary=---------------------------44BDB584269C5EEC3F73204
Host: elog.belle2.org:443
User-Agent: ELOG
Content-Length: 946


Content sent to host:
---------------------------44BDB584269C5EEC3F73204
Content-Disposition: form-data; name="cmd"

Submit
---------------------------44BDB584269C5EEC3F73204
Content-Disposition: form-data; name="unm"

xxxxxxxx
---------------------------44BDB584269C5EEC3F73204
Content-Disposition: form-data; name="upwd"

xxxxxxxx
---------------------------44BDB584269C5EEC3F73204
Content-Disposition: form-data; name="exp"

elog
---------------------------44BDB584269C5EEC3F73204
Content-Disposition: form-data; name="encoding"

ELCode
---------------------------44BDB584269C5EEC3F73204
Content-Disposition: form-data; name="Author"

stefano
---------------------------44BDB584269C5EEC3F73204
Content-Disposition: form-data; name="Type"

Other
---------------------------44BDB584269C5EEC3F73204
Content-Disposition: form-data; name="Text"

demo
---------------------------44BDB584269C5EEC3F73204

Response received:
HTTP/1.1 401 Unauthorized
Date: Thu, 06 Apr 2017 15:32:37 GMT
Server: Apache/2.4.18 (Ubuntu)
WWW-Authenticate: Basic realm="Belle II internal"
Content-Length: 463
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Unauthorized</title>
</head><body>
<h1>Unauthorized</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.4.18 (Ubuntu) Server at elog.belle2.org Port 443</address>
</body></html>

Error transmitting message