|
Demo
Discussion
|
Forum
Config Examples
Contributions
Vulnerabilities
|
Contributions to ELOG, Page 2 of 6 |
Not logged in |
 |
|
ID |
Date |
Author |
Author Email |
Category |
Subject |
Status |
Last Revision |
11
|
Wed Nov 24 23:45:19 2004 |
damon nettles | nettles@phgrav.phys.lsu.edu | Other | Steps for securing Elog using SSL and Apache | Stable | | Everything in this guide was done on a full install of Fedora Core 3 running
Apache 2.0. If you are using an older version of Apache some of this may not
work, so I recommend upgrading. Also, on different Linux distributions, some
of the paths may be different.
The goal here is to get Elog set up under Secure Socket Layers, so that
communication both ways is encrypted. This will cover any password
transactions so nothing gets sent over the web in the clear.
The previous method of securing the Elog, which involved using stunnel, is
out of date. A better way to go is to use the Elog in conjunction with
Apache. The Apache method leverages all the research and development that's
gone into providing secure sockets for Apache, and removes the need for any
serious reinventing of the wheel.
We begin with a web server running on port 80 and an Elog server running on
port 8080.
Making Certificates:
It's necessary to generate some secure certificates to be issued to anyone
who attempts to access the securesite.
A guide to making the certificates can be found at:
http://slacksite.com/apache/certificate.html
So, following the steps in the article:
openssl genrsa -des3 -rand file1:file2:file3:file4:file5 -out\
server.key 1024
where the \ is merely an indicator that the command wouldn't fit on a line
here. The fileN references are sources of random information to help the
random number seed be more random. I merely used some personal text files
that were zipped up, as suggested in the page.
openssl rsa -in server.key -out server.pem
Removes the RSA encryption from the key, to make it easier for the Apache
server to deal with it.
openssl req -new -key server.key -out server.csr
Starts a line of questioning about us as a certificate issuing entity.
Answer with reasonable values.
openssl x509 -req -days 60 -in server.csr -signkey server.key -
out\
server.crt
After this move the server.pem, server.crt, and server.csr to the
appropriate directories under /etc/httpd/conf/ . The extensions explain
which directory to put them in, with the exception that server.pem ended up
in etc/httpd/conf/ssl.key/ .
In the elogd.cfg file, change the port to 8079, and set the URL to
"https://your.host.name/" . Restarting the Elog daemon now leaves us with
Elog listening to port 8079 instead of port 8080.
The rest of the story is in the "elogredirect.conf" file attached to this
post, but here are the highlights.
Create a virtual host dealing with SSL that listens to port 443 (the ssl
port), and acts as a proxy for port 8079 (where Elog is listening). This
allows Apache to act as an SSL handler for Elog by handing off any access at
https://your.host.name/ to the Elog server. The firewall then can keep out
any direct attempts to access port 8079, so that the only thing that can
reach the Elog server is stuff talking to 8079 on the local side of the
firewall (which pretty much means just the Apache proxy). I recommend
Firestarter for the firewall config by the way, it's a real lifesaver.
http://firestarter.sourceforge.net/
This covers the SSL portion of the story, and by doing the redirection
inside the port 443 virtual host, instead of from the port 80 webpage as
before, you can avoid any path overlap.
As was the case for us, you may have links in older Elog posts, e-mails, or
web pages that point to specific Elog posts. If you have been using Elog for
some time and never bothered with the SSL stuff, the links most likely look
something like
http://your.host.name:8080/yourlogbook/postnumber.
To cover legacy support for calls on port 8080, you can create another
virtual host listening to port 8080. This host's job is to take any
incoming URL calls on "http://your.host.name:8080/a_directory" and
translate them into calls on "https://your.host.name/the_same_directory" .
This means that any attempt to contact the Elog on port 8080 will get
answered by an Apache virtual host that redirects the client through the
Apache SSL virtual host described above. See the conf file for the details.
So in the end, the firewall is set to only allow through ports 80, 443, and
8080. Port 80 handles the normal webpage access stuff. Port 443
exclusively handles the SSL port for the Elog daemon, and port 8080
exclusively handles the redirect for the legacy Elog calls.
Implementation of this setup on another system should be pretty
straightforward. Apache's config file is at /etc/httpd/conf/httpd.conf ,
and it also loads any *.conf files in /etc/httpd/conf.d/ . So its a pretty
simple case of just dropping elogredirect.conf into /etc/httpd/conf.d/ and
restarting the Apache server. Of course the necessary changes to elogd.cfg
have to be made and that server restarted as well. The firewall, too, needs
to be setup to secure the whole deal. Note that the elogredirect.conf file
needs to be edited for your specific setup (changing the instances of
"your.host.name" to whatever your server is, and also putting in the
administrator e-mail address where it is noted).
This work was done by Jonathan Hanson and Damon Nettles in the Gravity Lab
at Louisiana State University. You can see our Elog at
https://sam.phys.lsu.edu/elog .
If you have any questions or comments send them to
nettles@phgrav.phys.lsu.edu . |
Attachment 1: elogredirect.conf
|
### Here be things to make the elogd daemon invisibly secure under an
### Apache SSL proxy virtual host. Arrrrrr!
### ----This config file be mostly written by Jonathan Hanson, 11/23/04
### ----With some help from a few old salts on the net.
### This be the first instance of SSL in our setup, so the SSL module
### Must be called. This can be commented out if it don't put wind in
### your sails.
LoadModule ssl_module modules/mod_ssl.so
### Ahoy, ye scurvy land dogs! Listen to the SSL port (443) or may the
### sea beasts take ye!
Listen 443
### Make a virtual host at the default server name, and assign it port 443.
<VirtualHost _default_:443>
### Here be standard configuration for the Virtual Host
ServerAdmin your_e-mail_address
ServerName _default_:443
RequestHeader set Front-End-Https "On"
### This be the path to the elog directory
### (This didn't seem to make any difference, but it be a good
### idea nonetheless)
DocumentRoot /usr/local/elog
### Here be the setup for the SSL component of the Virtual Host
SSLEngine On
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.pem
### Here be the setup options for the Proxy module
ProxyRequests Off
ProxyPreserveHost On
### This be the root of the new Virtual Host, and it should be
### redirected to the port the elogd server is listening to
### (8079 on our poop deck).
<Location />
ProxyPass http://your.host.name:8079/
ProxyPassReverse http://your.host.name:8079/
SSLRequireSSL
</Location>
### Shiver me timbers! A firewall can be laid across the elog
### port to hinder direct access from the outside world to the elog
### daemon. This'll make the scurvy wretches come in through the apache
### proxy virtual host, and batten down the hatches on the elog in general.
</VirtualHost>
### Our previous elog configuration was at http://your.host.name:8080 and some of our
### users made static HTML links to other posts in their posts and email. They be sleeping
### in Davy Jones's locker in the briney deep now, but we be needing to make these posts
### backward-compatible. We be changing the port Elogd listens to (as above) to 8079, and
### then we be using another new virtual host at port 8080 to redirect to the new SSL URL.
### So it appears to the landlubbers outside as if a normal elog server is listening to port
### 8080, but in reality it be a Virtual Host redirecting through the other SSL virtual host
### which then be passing it on to the port the elog server really be listening to.
### If ye not be needing this backwards compatability, the following section can be made
### to walk the plank.
### I won't be telling ye twice, ye slimy bilge rat! Pay attention to what
### used to be the old elog port(8080).
Listen 8080
<VirtualHost _default_:8080>
### Here be standard configuration for the Virtual Host
ServerAdmin your_e-mail_address
ServerName _default_:8080
### This be the path to the html directory
### (This didn't seem to make any difference, but it be a good
### idea nonetheless)
DocumentRoot /httpd/html
### Here be the dark magic of mod_rewrite. Quake in your boots ye dogs!
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/(.*) https://your.host.name/$1 [NC,R=301,L]
</IfModule>
</VirtualHost>
### In the end, elog be reachable through either https://your.host.name/
### or http://your.host.name:8080/ , though the latter will be rewritten
### to the former as soon as the request be made. This be satisfying our
### needs for backwards compatbility with old URLs, while ensuring modern
### secure SSL support. Beware matey, recognize that we also had to change
### the port that elog listens to, and then add a URL line in the elogd.cfg
### file:
### port = 8079
### URL = https://your.host.name/
### Also a firewall was brought up and told to allow through only ports
### 80(html), 443(SSL), and 8080(the elog stand-in) and of course any other
### ports ye may need for other applications.
|
31
|
Tue Dec 15 20:11:27 2009 |
Michel Bovey | bovey (a) slf ch | Documentation | Sorting dates before and after "Sun Sep 9 > 03:46:39 CEST 2001" | Alpha | | BACKGROUNG
ELOG is storage date and time in unix time: seconds after epoch (Thu Jan 1 00:00:00 UTC 1970).
date -u -d @0
On "Sun Sep 9 03:46:39 CEST 2001" the unix time counter is passing from a presentation of 9 digits to 10 digits.
date -d @999999999
ISSUE
For sorting dates ELOG is using the character representation of the unix time. When ELOG contains dates on both
side of this 9 - 10 digits border sorting get confused.
WORKAROUND
in adding a leading 0 (zero) to the internal storage of dates in ELOG files we get over this problem.
On unix based system in can be easily achived with a sed command against the .log files:
sed -i 's/modification: 9/modification: 09/g' *.log |
16
|
Wed Sep 7 16:52:30 2005 |
Peter Eriksson | peter@ifm.liu.se | Other | Solaris 10 SMF/Greenline management manifest for ELog | Stable | | Please find enclosed as an attachment a Solaris 10 SMF/Greenline manifest that can be used to manage ELog.
(If you don't know what it is - it replaces init.d/cron/inittab and more stuff) |
Attachment 1: elog.xml
|
<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<!--
Copyright (c) 2005-06-17 Peter Eriksson (peter@ifm.liu.se)
This manifest can be used to manage an elog daemon using the
Solaris SMF subsystem.
Import this manifest using:
svccfg -v import elog.xml
Then activate the daemon with:
svcadm enable site/elog
-->
<service_bundle type='manifest' name='IFM:elog'>
<service
name='site/elog'
type='service'
version='1'>
<single_instance />
<!-- Need / & /usr filesystems mounted, /var mounted read/write -->
<dependency
name='fs-local'
type='service'
grouping='require_all'
restart_on='none'>
<service_fmri value='svc:/system/filesystem/local' />
</dependency>
<dependency
name='network-service'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/service' />
</dependency>
<dependency
name='name-services'
grouping='require_all'
restart_on='refresh'
type='service'>
<service_fmri value='svc:/milestone/name-services' />
</dependency>
<exec_method
type='method'
name='start'
exec='/ifm/sbin/elogd -D -c /ifm/etc/elogd.cfg'
timeout_seconds='60'>
</exec_method>
<exec_method
type='method'
name='stop'
exec=':kill'
timeout_seconds='30'>
</exec_method>
<instance name='default' enabled='false' />
<stability value='Evolving' />
<template>
<common_name>
<loctext xml:lang='C'>
Electronic Logbook server
</loctext>
</common_name>
<documentation>
<manpage title='elogd' section='1' manpath='/usr/local/man' />
</documentation>
</template>
</service>
</service_bundle>
|
47
|
Sun Aug 23 21:27:00 2015 |
Daniel Sajdyk | daniel.sajdyk@gmail.com | Theme/Skin | Simple theme | Beta | Tue Sep 1 07:39:45 2015 by Daniel Sajdyk | Hello.
I did simple theme for ELOG called "dansaj".
This is verision which I did for my ELOG, and if you have troubles in other configurations, please let me know, and we will correct it.
Vectors versions of icons you can find in oryginals folder (if you want to transform it).
The most current version you can download from my blog - Elog theme, czyli skórka, albo temat.
Regards
Daniel. |
Attachment 1: choose_elog.png
|
|
Attachment 2: entry.png
|
|
Attachment 3: Full.png
|
|
Attachment 4: login.png
|
|
Attachment 5: Summary.png
|
|
Attachment 6: Threaded_demo_logbook.png
|
|
Attachment 7: dansaj.7z
|
Attachment 8: Threaded.png
|
|
40
|
Mon Jan 7 08:45:10 2013 |
Bruce Weber | bruce.weber@inmarsat.com | Script | Server time offset | Stable | | Our server runs on local time, however, we require log entries to be in UTC (-0800hrs) - is there a command to achieve this?
Your assistance will be much appreciated
Thanks |
21
|
Tue Feb 20 18:20:40 2007 |
Val Schmidt | vschmidt@ldeo.columbia.edu | Documentation | Secure elog with SSL under Apache2 on Ubuntu | Stable | | The steps for configuration under Apache2 are a bit different. Below I've included a quick list of instructions for Ubuntu. One nice thing about this method, is that only https requests to https://your.url/elog are redirected (not all https connections to your url) so you can have other services running under ssl:
My Setup:
Ubuntu 6.10 (Edgy):
Linux tide1 2.6.17-11-generic #2 SMP Thu Feb 1 19:52:28 UTC 2007 i686 GNU/Linux
Packages:ii apache2 2.0.55-4ubuntu4 next generation, scalable, extendable web se
ii apache2-common 2.0.55-4ubuntu4 next generation, scalable, extendable web se
ii apache2-mpm-worker 2.0.55-4ubuntu4 high speed threaded model for Apache2
ii apache2-utils 2.0.55-4ubuntu4 utility programs for webservers
ii elog 2.6.1+r1642-1 Logbook system to manage notes through a Web ---
To setup ssl in apache2 for elog I started here:
This min-howto was kindly provided in a forum. I reproduced it here without permission.
A Mini-Howto for apache2:
apt-get install apache2
apache2-ssl-certificate
(and answer the questions)
Now, enable ssl:
a2enmod ssl
configure ssl:
cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl
ln -s /etc/apache2/sites-available/ssl /etc/apache2/sites-enabled/ssl
"/etc/apache2/sites-enabled/ssl" should look like this:
NameVirtualHost *:443
<VirtualHost *:443>
(... configure the directories too...)
and "/etc/apache2/sites-enabled/default" should look like this:
NameVirtualHost *:80
<VirtualHost *:80>
(... configure the directories too...)
In /etc/apache2/ports.conf, add Listen 443
In the middle of /etc/apache2/sites-available/ssl file, insert this two lines:
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem
Hope it helps :)
This method, without configuraiton of any of the <Directory> directives in /etc/apache2/sites-available/ssl, makes everything in /var/www https accessible. This may not be desirable. Configure the directives as you see fit.
To get SSL forwarding going for elog, in /etc/apache2/sites-available/ssl, I added the following:
ServerName tide1.unh.edu
ProxyRequests Off
ProxyPreserveHost On
<Location /elog/>
Order allow,deny
allow from all
ProxyPass http://tide1.unh.edu:8080/
ProxyPassReverse http://tide1.unh.edu:8080/
SSLRequireSSL
</Location>
Once this is in place one must restart apache with
sudo /etc/init.d/apache2 force-reload
In /etc/elog.conf I added:
URL=https://tide1.unh.edu/elog
and restarted elog as above.
Finally, I removed the firewall entry that allowed connections to port 8080 for non-secure elog.
Items of note:
The "apache2-ssl-certificate" created a certificate that seems to expire in 30 days. This obviously not ideal. More details about how to create certificates can be found at HERE. At some point in the future, we'll have to figure this out and create a more appropriate certificate. |
|
20
|
Wed Jan 10 23:08:27 2007 |
Exaos Lee | Exaos.Lee@gmail.com | Script | Script for running ELOGD on Ubuntu Linux | Stable | |
I prepared one init script for ELOGD running on Ubuntu Linux.
Please see the attachment. |
Attachment 1: elogd_ubuntu.tgz
|
41
|
Mon Jan 7 16:37:21 2013 |
Stefan Ritt | stefan.ritt@psi.ch | Script | Re: Server time offset | Stable | |
Bruce Weber wrote: |
Our server runs on local time, however, we require log entries to be in UTC (-0800hrs) - is there a command to achieve this?
Your assistance will be much appreciated
Thanks
|
Have you tried
Subst <attribute> = $utcdate
Probably you need a dedicated attribute of type "datetime" and have to play with the "Date format" options. |
152
|
Wed Mar 4 18:40:57 2020 |
Laurent Jean-Rigaud | lollspam@free.fr | Other | Re: Re: RPM build process enhancements | Stable | Wed Mar 4 18:45:05 2020 by Laurent Jean-Rigaud |
Sorry, the patch is malformed for the template file. Check PJ.
Bye,
Laurent
Laurent Jean-Rigaud wrote: |
Hi Stefan,
2nd patch for RPM build which adds :
- dynamic build options for krb5/ldap/pam/ssl support :
- for git / non rpm users :
- buildrpm version release [-krb5] [-ldap] [-pam] [-ssl]
- for rpm users using SRPMS (dependances are managed) :
- rpm -i elog-ver-rel.src.rpm && rpmbuld -bb [--use krb5] [--use ldap] [--use pam] [--use ssl] ~/rpmbuild/SPECS/elog.spec
- dynamic 2 last changelog entries :
- last with build information with
- dynamic user 's info (use your info if builded from PSI, or use %packager from ~/.rpmmacros if exists, or set to username username@ostname)
- build options list (KBR5, LDAP, PAM, SSL)
- before last for product changelog of current ELOG version-release
- customrel flag for local rebuild :
- release = %elogrel%{?customrel}%{?dist)
- so custom builder can add --define 'customrel NSA' at rpmbuild command or in .rpmmacros file -> elog-3.1.4-2.NSA.el7.x86_64.rpm by example.
- elog version and release are delivered in specfile as default for rebuild (tarball name uses it so it can not be changed for local rebuild from SRPMS).
- buildrpm uses ~/rpmbuild/SPECS/elog.spec generated from elog.spec.template (elog.spec is deleted in repo, replaced by elog.spec.template).
Tested on EL6 and EL7 x86_64 :-)
Bye
Laurent Jean-Rigaud wrote: |
Hi Stefan,
I enclosed a patch for RPM build process available on GIT.
changes :
- rpmbuild :
- checks if provider or custom build (the rm/mv are done on your computers only :-))
- call rpmbuild with version / release given as parameters
- elog.spec :
- last changelog entry date is set to build date
- build with debug for debuginfo rpms (product rpms are normally automatically strimmed)
- elog.init call /etc/ini.d/functions for RHEL/Centos/Fedora/? dists
Todo:
- add RPMbuild options for ldap/pam/...
- enclosed git log in changelog automatically (the dream :-))
|
|
|
Attachment 1: elog.spec.template
|
# ELOG weblog application
# rpmbuild -ba --define 'elogver 3.1.4' --define 'elogrel 2' --with ssl --with pam --with ldap --with krb5 --define 'factorydate date'
# define date of build for changelog and default release
%define build_timestamp %(LC_TIME=C date '+%a %b %d %Y')
%{!?factorydate: %define factorydate %build_timestamp}
# default version and release
%{!?elogver: %define elogver __ELOGVER__ }
%{!?elogrel: %define elogrel __ELOGREL__ }
# default release is build date
%{!?elogrel: %define elogrel %{build_timestamp} }
# Build options :
# Read: If neither macro exists, then add the default definition.
%{?_with_krb5: %define _with_krb5 USEKRB5=1}
%{?_with_ldap: %define _with_ldap USELDAP=1}
%{?_with_pam: %define _with_pam USEPAM=1}
%{?_with_ssl: %define _with_ssl USESSL=1}
# Default build options are with SSL
%{!?_with_ssl: %{!?_without_ssl: %define _with_ssl USESSL=1}}
# builder info
%define whoami %(eval who am i | awk '{print $1}')
%define HOSTNAME %(hostname)
%{!?packager: %define packager %{whoami} %{whoami}@%{HOSTNAME}}
Name: elog
Summary: elog is a standalone electronic web logbook
Version: %elogver
Release: %elogrel%{?customrel}%{?dist}
License: GPL
Group: Applications/Networking
Source: http://elog.psi.ch/elog/download/elog-%{elogver}-%{elogrel}.tar.gz
Vendor: Stefan Ritt <stefan.ritt@psi.ch>
URL: http://elog.psi.ch/elog
BuildRoot: /tmp/%{name}-root
Prefix: /usr/local
# Add build dependencies for pam, ssl and ldap features if enabled.
# Note: Tag tokens must start at beginning-of-line.
#
# Read: If feature is enabled, then add the build dependency.
%{?_with_krb5:BuildRequires: krb5-devel}
%{?_with_krb5:Requires: krb5-libs}
%{?_with_ldap:BuildRequires: openldap-devel >= 2.4.1}
%{?_with_ldap:Requires: openldap >= 2.4.1}
%{?_with_pam:BuildRequires: pam-devel >= 1.1.1}
%{?_with_ssl:BuildRequires: openssl-devel >= 0.9.8e}
%description
ELOG is part of a family of applications known as weblogs.
Their general purpose is :
1. To make it easy for people to put information online in a chronological
fashion, in the form of short, time-stamped text messages ("entries")
with optional HTML markup for presentation, and optional file attachments
(images, archives, etc.)
2. To make it easy for other people to access this information through a
Web interface, browse entries, search, download files, and optionally add,
update, delete or comment on entries.
ELOG is a remarkable implementation of a weblog in at least two respects :
- Its simplicity of use: you don't need to be a seasoned server operator
and/or an experimented database administrator to run ELOG ; one executable
file (under Unix or Windows), a simple configuration text file, and it works.
No Web server or relational database required. It is also easy to translate
the interface to the appropriate language for your users.
- Its versatility: through its single configuration file, ELOG can be made
to display an infinity of variants of the weblog concept. There are options
for what to display, how to display it, what commands are available and to whom,
access control, etc. Moreover, a single server can host several weblogs, and
each weblog can be totally different from the rest.
%changelog
* %{build_timestamp} %{packager} %{version}-%{release}
- rebuild with option(s): %{?_with_krb5:KRB5 }%{?_with_ldap:LDAP }%{?_with_pam:PAM }%{?_with_ssl:SSL}
* %{factorydate} Stefan Ritt <stefan.ritt@psi.ch> %{version}-%{release}
- Updated from git
* Wed Sep 26 2018 Stefan Ritt <stefan.ritt@psi.ch>
- Made adjustments for new elog server and RH7
* Fri Aug 29 2014 Stefan Ritt <stefan.ritt@psi.ch>
- Added BuildRequires, thanks to Stefan Roiser from CERN
* Fri Oct 21 2005 Stefan Ritt <stefan.ritt@psi.ch>
- Added resources/ directory
* Fri Mar 14 2003 Stefan Ritt <stefan.ritt@psi.ch>
- Added %post to change ownership of elog files
* Thu Jan 30 2003 Stefan Ritt <stefan.ritt@psi.ch>
- Added installation of man pages, thanks to Serge Droz <serge.droz@psi.ch>
* Tue Aug 13 2002 Stefan Ritt <stefan.ritt@psi.ch>
- Added elog group and user, thanks to Nicolas Chuche [nchuche@teaser.fr]
* Tue Jun 18 2002 Stefan Ritt <stefan.ritt@psi.ch>
- Put elogd.init into TAR file, add logbooks directory, put elogd in sbin/
* Tue Jun 18 2002 Serge Droz <serge.droz@psi.ch>
- Update to 2.0.0
* Mon Jun 3 2002 Serge Droz <serge.droz@psi.ch>
- Update to 1.3.6
* Fri May 31 2002 Serge Droz <serge.droz@psi.ch>
- Initial RPM
%prep
%setup -q
%pre
%{_sbindir}/groupadd -r elog 2>/dev/null || :
%{_sbindir}/useradd -d / -s /bin/false \
-g elog -M -r elog 2>/dev/null || :
%build
make %{?_with_ssl} %{?_with_pam} %{?_with_ldap} %{?_with_krb5} CFLAGS='-O3 -funroll-loops -fomit-frame-pointer -W -Wall -Wno-deprecated-declarations -Imxml -g'
sed "s#\@PREFIX\@#%{prefix}#g" elogd.init_template > elogd.init
%install
make install ROOT=$RPM_BUILD_ROOT MANDIR=$RPM_BUILD_ROOT%{_mandir}
%post
chown -R elog:elog $RPM_BUILD_ROOT%{prefix}/elog
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
/etc/rc.d/init.d/elogd
%{_mandir}/man1/*
%{_mandir}/man8/*
%doc README COPYING doc
%defattr(-,elog,elog)
%prefix/bin/*
%prefix/sbin/elogd
%prefix/elog/resources
%prefix/elog/ssl
%prefix/elog/themes
%prefix/elog/scripts
%prefix/elog/logbooks
%config(noreplace) %prefix/elog/elogd.cfg
|
49
|
Wed May 11 09:35:23 2016 |
Hanno Perrey | hanno.perrey@nuclear.lu.se | Script | Re: Re: Custom input forms implementation | Stable | Wed May 11 09:43:34 2016 by Hanno Perrey |
Stefan Ritt wrote: |
Dear ELOG users,
starting with SVN revision 2328, custom input forms are implemented. This allows application specific formats for check lists etc. In our specific case we had to implement a shift check list, which was quite long. Furthermore the check list should be optimized for an iPad, which we take in the field and record various checks and readings (in our case some gas pressure gauges at the PSI particle accelerator). Since the standard ELOG interface was too inflexible, a completely hand-written form was needed. The form can be activated by the new configuration options Custom New Form, Custom Edit Form and Custom Display Form, one for a new entry, an entry to edit and and entry to display. In our case we used the same form for all three cases. This is how the shift check list looks under the Safari Browser on a PC:

And here is how it looks on the iPad:

Each section can be collapsed and expanded (blue arrows at the left), and various internal checks are made before the check list can be submitted.
Implementing such forms is however more something for the advanced user, since you have to hand-write HTML with CSS and JavaScript code. It can then however be a powerful method for check lists. Please find in the attachments the elogd.cfg configuration for that logbook and the shiftcheck.html source code file. It is a bit complicated since the page is a static page, elogd just serves it from the file. This requires all the dynamic functions to be implemented inside the HTML file with JavaScript. To display an entry for example, the JavaScript loads the raw data with the "?cmd=Download" command and the populates the form fields. The collapsing and expanding is done by using CSS properties. The integrated style sheet was optimized for the rendering on an iPad. Rather large fonts were chosen so that the items can be checked easily with your finger tips. Various parameters are sent between the browser and the elogd program via hidden fields and cookies. So only something for experts! But if you go through the effort and hand-write the form, it can be very handy. Note that you have to upgrade to SVN revision 2328 for the three new options.
|
Thank you very much for this nice example!
I found a little issue with newer ELOG versions: if the authentication is done via session cookies, the submission of the checklist will fail with the error "Cannot open file passwd". This is actually misleading as the cause of the error is the empty user name submitted (since the cookie storing user name and pwd hash is never created) and not the password file itself. This can be worked around by removing the user name and pwd fields in the html form before submitting in case there is a SID cookie around.
The attached shiftcheck.html contains this workaround and seems to be functioning fine on my installation (ELOG 3.1.0).
Cheers,
Hanno |
Attachment 1: shiftcheck.html
|