Hello,

I am using ELOG 2.5.2. I had a real need for a simplified almost text-only version of the application.  For me 
personally, I like simple, minimalist and text-only as much as possible for the tools I use.  I personally found 
the layout with all the colors to be distracting from the content of each log entry.  Again this is ONLY my 
personal preference, NO offense meant. :-)

I took the default.css and modified it to achieve what I needed.  I am uploading here, the .css file.  It uses 
"blue" for some of the things such as attribute fields on single page view, etc.  but overall it's all clean, 
plain-text.

I don't know if this css will work on newer versions of ELOG (since I know i'm using an old one.)  But it's my 
hope that others like me, will find this modification very useful.

Thank you Stefan, and community -- this is an awesome tool, that I use in my business.  It's amazing how simple 
tools are always the most powerful and scale-able!  Fantastic, excellent job on this app.

Fixing repeating first image in email (email notification) when the user submit a new log with in_line images.

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 .

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 :-))

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

Sorry, the patch is malformed for the template file. Check PJ.

Bye,

Laurent