Hi All,

Can I view who is connected to ELOG (I'm the Admin) ?

thank you.

I found the most limiting factor of ELOG to be the file access. ELOG stores all entries in files and therefore has a lot of disk access.

We found that an AFS directory for ELOG is unusable. We tried to store our logbooks on NFS, and it was barely usable but slow. Now we use a local disk on the server, that works fine.

If you want to speed up ELOG the best approach is a dedicated server with a local SSD storage.

Dear all,

First, many thanks for creating and sharing this great tool which is ELOG! Our users are very happy with it!

I have few questions about inserting images into the entries.

From time to time our users insert them directly in the editor what leads to encoding the whole image in the HTML log file and the images does not appear in the attachments list. Saving and further editing of such entries slows down the whole ELOG server which uses 100% of CPU.

I'm not sure how they do it Ctrl+C & Ctrl+V, drag & drop, etc.. What I know is that if they add it using the "Insert image" action in the editor there are no problems and the images are properly listed in the attachments.

I read in the docs:

uploading or downloading an attachement file is a single request, and causes the entire file to be loaded in server memory while the request is being processed.
This is not normally a problem for the sort of short, text-mode entries ELOG is designed to support. However, if a user starts to upload or download a large attachment file (or image) over a slow link, all other users on that ELOG server will have to wait for that transfert to finish before they can access any logbook on that server. This is why there is a low limit on the size of attachments, and why ELOG should not be used to distribute large files under intensive multi-user conditions.

but I think this is not our case. Here I talk about wrongly inserting a single image of 700KiB.

So, I'm asking:

1. Is the behavior that we observe something already detected? If yes, which are exactly the wrong ways of inserting the images?
2. Is it fixed in newer ELOG versions?
3. Is it possible to disable the wrong ways of inserting the images in order to avoid such problems?

Many thanks in advance for your help!

Here are the relevant excepts from the documentation:

Subst <attribute> = <string>
When submitting logbook entries, attribute values can be substituted by some text. This text can contain arbitrary fixed text and following values:

• $<attribute>: The entered value of the attribute itself
• $host: The host name where elogd is running
• $remote_host: The host name of the host from with the entry was submitted
• $short_name: The login name (if password file is present)
• $long_name: The full name from the password file for the current user
• $user_email: The email address from the password file for the current user
• $logbook: The name of the current logbook
• $date: The current date, formatted via "Date format"
• $utcdate: The current UTC date (GMT) and time, formatted via "Date format"
• $version: The version of the ELOG server in the form x.y.z
• $revision: The Subversion reversion of the ELOG server as an integer number
• $shell(<command>): <command> gets passed to the operating system shell and the result is taken for substitution.

Execute new | edit | delete = <command>
It is possible to execute a shell command on the server side after a new message has been submitted, edited or deleted. This feature has been used in the past for SMS notifications over a telephone system and for synchrnonization of the ELOG database with an external SQL database. The <command> can contain substitutions similar to the Subst command. In addition the list of all attachments can be referred to via $<attachments>. The text body of the entry can be referred to with $text. It should be noted that only the first 1500 characters of the text can be used, in order not to exceed the limits of the shell. Following (Unix) command writes a notification into some file:

Execute new = echo "New message wiht ID $message id of type $type from $long_name on $remote_host" >> /tmp/elog.log

It should be noted that this feature can impose a security problem. If someone can edit the elogd.cfg through the Config command of elogd, that person can put malicious code into elogd.cfg and execute it. This is even more severe if elogd runs with root privileges. To avoid such problems, the execute facility is disabled in elogd by default and has to be enabled explicitly with the "-x" command line flag. The administrator has to ensure then of course that only trusted people can edit elogd.cfg.

Have fun!

Andreas

As far as I know, it is not possible, if you make a "new" entry.
You could configure the elog, to always PRESET an atribute, but then it is always the same, not the last.

I think the "duplicate" entry function could provide you partly with the functionality you want, as it copies all old values into a new entry.

Regards,
Sebastian

All,

I am using elog as an observation log for amateur astronomy. I have a form configured, but I would like to know if it is possible to make certain fields persist across new entries.

What I mean is this:

When I make an new observation, I select a value for sky conditions (say.. "1"). When I make another observation, "1" is already selected.

Is this possible? If so, how?

Thanks

This is correct. The elogd daemon needs username and password in parameters "unm" and "upwd". The password must be SHA256 encoded, so best is to grab it from the password file. This way one does not have to send clear text passwords over the network.