| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
67370
|
Wed Oct 31 17:20:14 2012 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Question | Linux | 2.9.2 | Re: Elogd hangs while uploading bmp attachment |
| 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
 ⇄
Detect language » English
|
|
67386
|
Mon Nov 26 15:57:49 2012 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 2.9.0-2427 | ELOG crash related to Kerberos, SSL and Login users | I'm using Kerberos and SSL and experience problems with individual setting of "Login user =" for different logbooks.
Sometimes (not every time, but most times) the server crashes under the following condition:
When I login at one logbook and then change to a logbook, that has a restricted "Login user" list with my login
name not in it. It created the following GDB output:
Program received signal SIGSEGV, Segmentation fault.
show_elog_list (lbs=0x916b768, past_n=0, last_n=0, page_n=0, default_page=1, info=0x0) at src/elogd.c:19793
19793 message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id;
Expected behaviour would be to show me the login page with the error message:
"you don't have access to this logbook".
This message is never shown for the attached configuration file.
If I remove the "Guest" commands for logbook "TestB" then elogd behaves properly.
For the moment I've just disabled "Login user" settings.
Regards
Andreas |
| Attachment 1: elogd.cfg
|
[global]
SSL = 1
Port = 443
Authentication = Kerberos, File
Password file = passwd.txt
Login expiration = 8
Admin user = luedeke
Allow password change = 0
Self register = 0
Logfile = elog.log
Group Operation = TestA, TestB
URL = https://localhost
[TestA]
Guest Menu commands = List, New, Find, Login, Help
Guest List Menu commands = New, Find, Login, Help
Comment = Test Log
Attributes = Autor
Preset Autor = $long_name
Locked Attributes = Author
[TestB]
Guest Menu commands = List, Find, Login, Help
Guest List Menu commands = Find, Login, Help
Comment = TestB
Attributes = Author
Admin user = flechsig
Login user = flechsig, spielmann
Preset Author = $long_name
Locked Attributes = Author
|
|
67387
|
Mon Nov 26 17:12:32 2012 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug fix | Linux | 2.9.2-2475 | Re: ELOG crash related to Kerberos, SSL and Login users | Forget the previous post:
I cannot reproduce the problem with the latest version of elogd (2.9.2-2475). |
|
67394
|
Tue Dec 11 09:00:36 2012 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Windows | 2.7.5-2130 | Re: Error 554 MailTransferAgentServer ESMTP not accepting messages | Just my 2 cent: did you try to reproduce the problem with the latest ELOG version 2.9.2?
Kind Regards
Andreas |
|
67405
|
Tue Dec 18 12:09:38 2012 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Windows | 2.9.2-2475 | Re: Reply HTML |
| Hal Proctor wrote: |
|
| Hal Proctor wrote: |
|
| Hal Proctor wrote: |
|
| Stefan Ritt wrote: |
|
| Hal Proctor wrote: |
|
Any reason why when I click "Reply" to a previous submission that the body is full of HTML code?
See below:
<p>
<table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;">
<tbody>
<tr>
<td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Hal Proctor wrote:</td></tr>
<tr>
<td cellpadding="10px" style="background-color:#FFFFB0;"><p>
<table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;">
<tbody>
<tr>
<td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Quote:</td></tr>
<tr>
<td cellpadding="10px" style="background-color:#FFFFB0;">removed the thing and the other thing....added this and that!</td>
</tr>
</tbody>
</table>
</p><p> </p>
testing reply</td>
</tr>
</tbody>
Here is my logbook config:
[Logbook]
Theme = default
Comment = Maintenance Logbook
Attributes = Author, Type, Category, Subject, Shift
Options Type = Repair, Routine, Preventative, Other
Options Category = Emergency, General, Change-Over, Other
Options Shift = 1, 2, 3
Extendable Options = Category
Required Attributes = Author, Type
Page Title = Maint Log - $subject
Reverse sort = 1
Preset Author = $long_name
Preset on reply Author = $long_name
Locked Attributes = Author
Quick filter = Date, Type, Category
|
I don't see any mistake in the configuration file. Did you switch the "Encoding" from HTML to plain? (Radio buttons at the bottom just below the text window). Is there a problem with your FCKEditor? Do you see the formatting menu bar?
|
I do not get the formatting menu with HTML. I switched to plain and code still exists. The only formatting menu I get is when I choose ELCode. I have no problem with this forum seeing the formatting menu with HTML (although it does take some time to load).
|
Tested it in Chrome and acts the same as IE8 (just much slower)
|
It's version issue!! 2.92 does not utilize FCKeditor correctly. Backed off one version and it works fine! 2.91 is GOOD!
|
Actually I can confirm a similar issue with 2.9.2:
when I create a new entry with the default "HTML" encoding and then swap to "plain", the text area is cluttered with HTML code (see attachment new_entry.txt)
I did notice it, but I did not pay much attention to it. But I agree is should be fixed. But in my case it could be related to a firefox add-on "It's all text" that uses java script to modify the HTML code.
⇄
Detect language » English
⇄
Detect language » English
Andreas |
| Attachment 1: new_entry.txt
|
<div style="position: fixed; display: none; z-index: 2147480000; background-color: rgb(255, 255, 204); padding: 6px; color: rgb(0, 0, 0); border-radius: 7px 7px 7px 7px; font-size: 12px; max-width: 400px; font-family: Arial,Helvetica,sans-serif; line-height: 100%; text-align: left; border-style: none; border-width: 1px; border-color: rgb(0, 0, 0); opacity: 1;"> </div>
<div style="display: none; position: fixed; max-height: 438px; width: 450px; padding: 3px; border-width: 0px 0px 2px 2px; border-style: dashed; border-color: grey; border-radius: 0px 0px 0px 5px; background-color: rgb(255, 255, 255); overflow: auto; min-height: 200px; z-index: 2147479999; text-align: center; color: rgb(0, 0, 0); right: 0px; top: 0px;"><textarea style="height: 80px; width: 444px; border: 1px solid grey; padding: 2px;" id="itsalltext_generated_id__1"></textarea><img src="chrome://itsalltext/locale/gumdrop.png" title="It's All Text!" style="cursor: pointer ! important; display: none ! important; position: absolute ! important; padding: 0pt ! important; margin: 0pt ! important; border: medium none ! important; width: 28px ! important; height: 14px ! important; opacity: 0.0152174 ! important;" alt="" /><select>
<option value="af">Afrikaans</option>
<option value="sq">Albanian</option>
<option value="ar">Arabic</option>
<option value="hy">Armenian</option>
<option value="az">Azerbaijani</option>
<option value="eu">Basque</option>
<option value="be">Belarusian</option>
<option value="bg">Bulgarian</option>
<option value="ca">Catalan</option>
<option value="zh-CN">Chinese (Simplified)</option>
<option value="zh-TW">Chinese (Traditional)</option>
<option value="hr">Croatian</option>
<option value="cs">Czech</option>
<option value="da">Danish</option>
<option selected="selected" value="auto">Detect language</option>
<option value="nl">Dutch</option>
<option value="en">English</option>
<option value="et">Estonian</option>
<option value="tl">Filipino</option>
<option value="fi">Finnish</option>
<option value="fr">French</option>
<option value="gl">Galician</option>
<option value="ka">Georgian</option>
<option value="de">German</option>
<option value="el">Greek</option>
<option value="ht">Haitian Creole</option>
<option value="iw">Hebrew</option>
<option value="hi">Hindi</option>
<option value="hu">Hungarian</option>
<option value="is">Icelandic</option>
<option value="id">Indonesian</option>
<option value="ga">Irish</option>
<option value="it">Italian</option>
<option value="ja">Japanese</option>
<option value="ko">Korean</option>
<option value="la">Latin</option>
<option value="lv">Latvian</option>
<option value="lt">Lithuanian</option>
<option value="mk">Macedonian</option>
<option value="ms">Malay</option>
<option value="mt">Maltese</option>
<option value="no">Norwegian</option>
<option value="fa">Persian</option>
<option value="pl">Polish</option>
<option value="pt">Portuguese</option>
<option value="ro">Romanian</option>
<option value="ru">Russian</option>
<option value="sr">Serbian</option>
<option value="sk">Slovak</option>
<option value="sl">Slovenian</option>
<option value="es">Spanish</option>
<option value="sw">Swahili</option>
<option value="sv">Swedish</option>
<option value="th">Thai</option>
<option value="tr">Turkish</option>
<option value="uk">Ukrainian</option>
<option value="ur">Urdu</option>
<option value="vi">Vietnamese</option>
<option value="cy">Welsh</option>
<option value="yi">Yiddish</option>
</select><span style="font-weight: bold; cursor: pointer; color: lightgrey;">⇄</span><select>
<option value="af">Afrikaans</option>
<option value="sq">Albanian</option>
<option value="ar">Arabic</option>
<option value="hy">Armenian</option>
<option value="az">Azerbaijani</option>
<option value="eu">Basque</option>
<option value="be">Belarusian</option>
<option value="bg">Bulgarian</option>
<option value="ca">Catalan</option>
<option value="zh-CN">Chinese (Simplified)</option>
<option value="zh-TW">Chinese (Traditional)</option>
<option value="hr">Croatian</option>
<option value="cs">Czech</option>
<option value="da">Danish</option>
<option value="nl">Dutch</option>
<option selected="selected" value="en">English</option>
<option value="et">Estonian</option>
<option value="tl">Filipino</option>
<option value="fi">Finnish</option>
<option value="fr">French</option>
<option value="gl">Galician</option>
<option value="ka">Georgian</option>
<option value="de">German</option>
<option value="el">Greek</option>
<option value="ht">Haitian Creole</option>
<option value="iw">Hebrew</option>
<option value="hi">Hindi</option>
<option value="hu">Hungarian</option>
<option value="is">Icelandic</option>
<option value="id">Indonesian</option>
<option value="ga">Irish</option>
<option value="it">Italian</option>
<option value="ja">Japanese</option>
<option value="ko">Korean</option>
<option value="la">Latin</option>
<option value="lv">Latvian</option>
<option value="lt">Lithuanian</option>
<option value="mk">Macedonian</option>
<option value="ms">Malay</option>
<option value="mt">Maltese</option>
<option value="no">Norwegian</option>
<option value="fa">Persian</option>
<option value="pl">Polish</option>
<option value="pt">Portuguese</option>
<option value="ro">Romanian</option>
<option value="ru">Russian</option>
<option value="sr">Serbian</option>
<option value="sk">Slovak</option>
<option value="sl">Slovenian</option>
<option value="es">Spanish</option>
<option value="sw">Swahili</option>
<option value="sv">Swedish</option>
<option value="th">Thai</option>
<option value="tr">Turkish</option>
<option value="uk">Ukrainian</option>
<option value="ur">Urdu</option>
<option value="vi">Vietnamese</option>
<option value="cy">Welsh</option>
<option value="yi">Yiddish</option>
</select>
<div style="text-align: left; background-color: rgb(235, 239, 249);">Detect language » English</div>
<div style="width: 444px; max-width: 444px; padding: 2px; min-height: 80px; border-width: 1px; border-style: solid; border-color: grey; background-color: rgb(255, 255, 255); text-align: justify;"> </div>
</div>
|
|
67448
|
Thu Feb 21 13:41:25 2013 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Linux | ELOG V2.9 | Re: Multiple versions of elog on one server |
| David Pilgram wrote: |
|
| Chris Smith wrote: |
|
Is there a way of having multiple copies of elog running on one windows 2003 server? different ports?
I need to access 2 different elogd.cfg files.
|
[...] However, I was soon asked questions by Andreas as to how I found this running, as he had encountered problems with an earlier version. To be honest, that stopped me experimenting too far with this at that point, as well as a coincidental upgrading of my hardware. [...]
|
Just for completeness: I was running two elogd servers (2.9.0) on one Linux host in order to provide an english and a german web interface to the same logbooks, synchronised by the mirror server mechanism.
That didn't work out well, the elogd crashed infrequently. But of course mirror servers are not intended to run on the same host. Eventually I've just dropped the english server.
⇄
Detect language » English
|
|
67454
|
Fri Feb 22 10:58:18 2013 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Linux | 2.92 | Re: any way to undelete entries? |
| Mark Bergman wrote: |
|
Is there any way within eLog to undelete entries?
|
I wrote to scripts to backup the logbook files:
- elog_backup_daily creates a tar file of all new entries of the last 25 hours and keeps these backups for 90 days
- elog_backup_hourly creates a tar file of the entries of the last 65 minutes and keeks these backups for one week
- exclude-logbooks specifies which files not to backup
This allows you at least to recover deleted entries by hand as an administrator.
⇄
Detect language » English
⇄
Detect language » English
⇄
Detect language » English
|
| Attachment 1: elog_backup_daily
|
#!/bin/sh
# source file directory
srcd=/usr/local/elog/
# backup all files newer than 25 hours
date=$(date -d "-25hours" "+%Y%m%d %H:%M")
# backup file directory
tard=/logbooks_backup
# backup tar file name
tarf=$tard/$(date +%Y%m%d_%a.tar)
# do not backup files that match patterns in this file
excf=/usr/local/elog/utilities/exclude-logbooks
# create backup
cd $srcd
tar --ignore-case -X $excf --newer "$date" -cf $tarf . logbooks/*
# copy passwd.txt
if [ "$(date +%u)" -eq 1 ]
then
passwd=$tard/passwd_$(date +%Y%m%d_%a.txt)
cp $srcd/passwd.txt $passwd
gzip -9 $passwd
fi
# delete all backups older than 90 days
find $tard -mtime +90 -name "*_???.tar" -exec rm -f {} +
find $tard -mtime +90 -name "passwd_*_???.txt.gz" -exec rm -f {} +
|
| Attachment 2: elog_backup_hourly
|
#!/bin/sh
# source file directory
srcd=/usr/local/elog/
# backup all files newer than 25 hours
date=$(date -d "-65minutes" "+%Y%m%d %H:%M")
# backup file directory
tard=/logbooks_backup
# backup tar file name
tarf=$tard/$(date +%a%H%M.tar)
rm -f $tarf
# do not backup files that match patterns in this file
excf=/usr/local/elog/utilities/exclude-logbooks
# create backup
cd $srcd
tar --ignore-case -X $excf --newer "$date" -cf $tarf . logbooks/*
|
| Attachment 3: exclude-logbooks
|
*.png.png
*.gif.png
*.jpg.png
*.pdf.png
oldLogbooks/*
logbooks/elog.log
passwd.txt
ssl/*
logbooks/Backup/*
logbooks/old/*
|
|
67488
|
Mon Apr 29 10:17:54 2013 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Linux | 2.5.2 | Re: Auto-Generate new logbook daily |
| David Pilgram wrote: |
|
| Stefan Ritt wrote: |
|
| Ryan Blakeslee wrote: |
|
Hello,
I am currently using ELOG as a daily logbook for work performed for customers. This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.
Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf. This process all works fine, mostly, except I run into the following obstacles (that are all human related.)
1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer.
2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed. For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.
2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such.
2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log). ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.
All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.
To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later. This would serve as sort of a place holder.
However, I can't commit myself to always create a log entry for every day either. Again, human error.
Is what I would like to be able to do is create a new log entry, every single day, automatically. I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end-of-day or on a day I have downtime and can commit to administrative work.
My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc. Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.
Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?
Thank you very much in advance!
|
Actually I would not worry with the 042313a.log files. In a future version of elog they might be replaced by a database or so. I see two options:
- Add an attribute of date/time type. You do that with "Type <attribute> = datetime". Then you can assign a certain date or time to each entry you do. That means you can tag an entry with the date of yesterday or so. If you make that date then the main database key (via "List display") it basically replaces your "internal" date.
- You can do automatic entries with the "elog" utility coming with the distribution and described here. This you can even run from a cron job. If you submit a new entry from elog, you get automatically the incremented IDs etc. You can use some default values for the attributes, which you can change later.
|
Purists look away now.
I have the same issues regarding "catching up" of entries. So what I do is use the date command to reset the computer's time back to the time that the entry [i]should[/i] have been made. Say I need to put an entry for last Thursday (today is Saturday 27th),
Firstly I set the clock back by
date 04252200
(I use a time of 22:00 or later as code for a retro-made entry, the date being the important point for me).
Then any entry will have the correct time (sic) and date entry within the file, and the file the expected format of 130425a.log
After Thursday's batch of entries, I then simply reset the clock for the next entry/ies or indeed back to real time.
Mind you, my log files have the format yymmdda.log, whereas you state yours are mmddyya.log, which strikes me as a very high degree of flexibility!
---
Nice to meet someone else who gets down to the bare ascii and knows how to edit the xxxxxxa.log files!
|
Just my two cent:
I would strongly recomment NOT to go back and forth with the system time.
In some cases this can cause you severe problems with your control system.
Stefans suggestion works fine for our operations logbook: I've just introduced an attribute "When" and sort my entries according to this attribute.
The line in the config:
Start page = ?rsort=When
takes care that this sorting is the default.
The advantage of this approach is in addition, that you keep track of both dates:
the date when the work had been performed and
the date when you've actually entered the information.
Sometimes that turns out to be useful to me to figure out what I did and when ;-)
As to editing the bare ascii: I do this a lot, even with sed scripts.
But there is a disclaimer: you can crash elogd with corrupted entries and you may have a hard time figuring out why it crashes.
For example accidentally deleting a digit in a cross reference can create a loop that causes elogd to get non-responsive without error: try to find that!
I would strongly advise not to build any user application build on editing the ascii files. Just use it for system administration.
Andreas
--
He who knows others is wise.
He who knows himself is enlightened.
-- Lao Tsu
⇄
Detect language » English
|
|