Looking at some of the questions here this seems too newbie to even ask.

I want to set up a log book for my mechanics. I want them to each have a password to log in and enter what they do each day.

When I try to set up a password file it takes all the info, then when I hit save it says "server has been reset" and it will not log in. I have to remove the password = and restart the server.

[global]
port = 8080


[TFB]
Password file = <tfbpass>


Theme = default
Comment = TFB ENGINEERING
Attributes = Mechanic, Type of entry, Status, Subject
Attributes = Author, Status
Options Status = Completed, Incomplete, Notification only
Cell Style Status Completed  = background-color:green
Cell Style Status Incomplete  = background-color:red
Cell Style Status Notification only  = background-color:yellow



Options Mechanic= Jeff K, Arnaldo M, Bob L, Nathan P
Options Type of entry = Break Down, PM Repair, Building, FYI, Other
Options Status = Completed, Incomplete, Notification only, Other
Extendable Options = Category, Status,
Required Attributes = Mechanic, Type of entry, Category, Status,
Page Title = TFB Engineering - $subject
Reverse sort = 1
Quick filter = Date, Mechanic

 

Hi Louis,

I'm a little surprised by your comment that you use symlinks 'to store your logbooks elsewhere'.

I start the daemon with

 /usr/local/sbin/elogd -p 8080 -c /home/logbooks/elogd.cfg -d /home/logbooks

so that both my logbooks *and* the config file are both based on my preferred location, which is a subdirectory of /home.  No symlinks  OK, themes are elsewhere, but for backup purposes, that's a rather lesser issue. 

I have no idea why the default logbook location is /usr/local/elog/logbooks which does not strike me as a sensible location (at least on Slackware).  Maybe such an odd location was to force users to choose a better location...(the -d switch).

To all:

I use Slackware (currently 13, I hear there are some issues with 14 for programs I wish use), and I compile from the sources.  Usually from random svn versions as a general pain-in-the-neck for Stefan.  I've never had to make a [Slackware] package for distribution - I have issued patches and/or source distribution, depending on your point of view.  If someone can provide the advice, I'd certainly try and do a Slackware distribution, but I do have Real Work to do as well, so it may not be done immediately.  I think Ubuntu is fairly close to Slackware, not sure about Debian, which I *thought* was close to Red Hat.

Now I *do* understand what some of the other contributors to this thread are doing, as I do something similar for other programs that are now unmaintained and no longer compile with GCC4 or earlier.  The email program I use is a ten-year-old binary & libraries I compiled under Slackware 7 (if not, 4), and I copy the relivent binaries, libraries and dependances across when I upgrade the o/s.  Yes, one day it will fall down.  Three other programs I regularly use are similarly now 'legacy'.  My 'C' coding isn't up to the major changes apparently needed to allow them to compile again with a modern compiler.
 

The Debian init script contributed here has been working quite well for me for the last few Ubuntu versions. Unless you edit it, it sets the elog base directory to /etc  so that's where you have to put your themes dir, resources, .conf file, scripts, logbooks, etc. I use symlinks to actually store my logbooks elsewhere.

I would also vote for a sane deb package. Right now, when I upgrade ELOG, I don't even run make install, I just copy the compiled binaries to their respective directories (/usr/bin or /usr/sbin). The rest stays the same.

I'm not of the skill level to help, but for what its worth, running Ubuntu 12.04, used alien to install the latest RPM with only two little snags. I had to create a link from libssl.so.1.0.0 to libssl.so.6, which is a trick I've pulled with other software, not sure what the proper fix is. I also had to make similar changes to the init script.

I'm not using Debian so I cannot give support there. There was some Debian support a few years ago, but the maintainer has gave this up. If you find someone who volunteers to do the job (yourself?) I'm happy to include the Debian specific files in the distribution. 

Stefan

Hello folks,

Can we have a better support under modern Linux distributions?

I'm trying to install elog in our webserver and it's becoming a boring task. First of all theres only RPM packages. And we really don't like the Red Hat method, so we use Debian Servers. More package mainteners would be nice.

The software appears to be working correctly, but there are some bugs (or perhaps missing dependencies?); the init script put in /etc/rc.d/init.d is broken under Debian:

First of all because it's in /etc/rc.d.

The second problem is in this line:

# Source function library.

#. /etc/rc.d/init.d/functions

The file doesn't even exists.

The third problem is the echo_success; echo_failure commands that doesn't even exist. As I can see it's definitions are sourced in the functions file that doesn't exist.

After removing this missing commands or files from the init.d; I can call elogd script and start the daemon under root. Appears to be working...

And last but not least; there's a way to standardize the init script to run in other Linux distros, so we can put it to start automatically at boot time?

Many thanks in advance,

Vinícius Ferrão 

PS: I'm not asking to support any creepy distros, but to support the .deb package format and system style.

Andreas Luedeke wrote:

David Wallis wrote: I'm running elog 2.9.2 on a Red Hat 6.3 server. This installation has been running for some time on a Solaris server, and was recently moved to the RHEL server. When a user tries to upload a .bmp attachment, the upload never completes, eventually timing out with a proxy error. At that point, the elogd process stops responding to requests and needs to be restarted. Nothing is in the log file other than a "Listening" message when elogd starts up. Png and pdf attachments seem to work fine. I was able to convert an image from .bmp to .png and upload, but that's not practical for my user. ImageMagick 6.5.4-7 is installed on the server. Everything else seems to be working normally. Is this a known problem, or have I missed something that needs to be installed on the RHEL server?  Hi David, I've just tested it on my server running ELOG V2.9.0-2414, Scientific Linux 5.7 (RHEL 5.?) with ImageMagick 6.2.8: the attachment is uploaded but no preview is generated. No problem with the server. What was the behaviour of your Solaris system? Did it upload? Did it create a preview? BMP files are - in my experience - often very large. Could it be a file size problem? Did you try with a small BMP image? Kind Regards Andreas   Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English

 Hi Andreas,

Bmp attachments worked fine on the Solaris server. Was running 2.9.2 with ImageMagick 5.5.7.

I don't think it's a file size issue, the image I'm testing with is only about 3 MB.

2455 is before the image handling issue came about, so it's nothing to do with those changes.

I see Andreas also finds that ImageMagick is apparently not invoked by elog to make a thumbnail of a .bmp file.  I tested it with a 5MB and a 0.5MB .bmp file this morning, so I don't really think it's the size of the file that is causing the problem - or that is my first guess, anyway.   But I suppose it is worth asking, what is the size of the .bmp file(s) you are trying to attach?  Just a thought, there is a parameter in the Global section of the elog.cfg - "Max Content Length".  I forget the default, I had to increase it when I wanted to attach a huge pdf file, wonder if that might be the issue (I had an error message come up with the pdf file, I wonder...)

The elog daemon can get stuck running like mad and not responding to anything.  One example I know is if you erase an elog entry (e.g. delete one file in the logbook directory, I'm not talking about using elog's own delete facility) the indexing of the entries is broken, and elog cannot handle that, it just gets stuck, consuming loads of CPU time doing I don't know what. 

I've got to go and do something in real life now, but I may get a chance to 'play' later, see if I hit any point that the experts can then work through