| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
249
|
Sun Mar 16 19:15:16 2003 |
 | Recai Oktas | roktas@omu.edu.tr | Info | | | Elog and SSL | > Basically im running elog on a redhat 8 box with stunnel already installed
> as part of OpenSSL, on the server i ran the command specified in the
> instructions
>
> stunnel -d 443 -r 172.16.24.108:81
I haven't tried `stunnel` with elog, but as far as I read from various
sources, stunnel requires you to create an SSL certificate. In attachment,
you'll find a sample case for stunnel and smtp (port 25) + pop3 (port 110).
Hope this helps.
Reference: http://www.tldp.org/linuxfocus/common/sart/index.html |
| Attachment 1: stunnel_with_smtp_pop3.txt
|
EZ Email Security With Stunnel
by Pat Parsons
This is a little crash course in how to setup email over SSL painlessly using
Stunnel. First you need to have installed a mail transfer agent to handle the
SMTP portion of the mail. Then you need to have installed either an IMAP server
or a POP3 server. Many distributions come with Stunnel, if yours does not you
can get it from http://www.stunnel.org. Stunnel requires that you have OpenSSL
or SSLeay installed first. This should come with your distribution. Generally
if you have SSH installed you also have a SSL library.
Get and install Stunnel. I am not going into detail on that because if you are
at this point you probably already know how to do so. Make a SSL certificate
for use with Stunnel. OpenSSL provides a makefile to do just that. In my
distribution it is located in /usr/share/ssl/certs . CD to that directory and
type make stunnel.pem to create the certificate that is named stunnel.pem. Now
you need to a few lines to your rc.local file to start Stunnel at bootup
(assuming you ever reboot that is) these lines are:
/usr/sbin/stunnel -d 995 -r 110
/usr/sbin/stunnel -d 465 -r 25
This will start stunnel listening on port 995 for POP3 and 465 for SMTP. Now
all you need to do is edit the options for your mail client and there you go.
No need to worry about cleartext email passwords. If you are too impatient to
wait for the next reboot you can type the commands given previously to start
Stunnel right away. There may be some problems with certificate validation for
some email clients. Make sure when asked by the makefile you get the server
name correct. If your email client will not let you add certificates you may
need to change or obtain a certificate from a certification authority. If you
cannot get the certificate vaidation worked out there is no way to ensure that
you are connecting to the correct machine. Have a nice day.
|
|
219
|
Wed Feb 12 08:54:05 2003 |
 | Stefan Ritt | stefan.ritt@psi.ch | Info | | | Re: Feature request | > > > Can you consider implementing the following additions to the
functionality
> > >
> > > 1) Subt on edit <attribute> = xyz
> > >
> > > This would be fantastic for implementing version control so you can see
> > who
> > > has edited a posted or a db entry.
> >
> > Can you give me an example of how you would use that?
>
> -----
>
> Lets say you are storing configuration information relating to a customers
> solution, you need the ability to track who has made what changes to the
> config information stored in the log book so you can backtrack who changed
> what and when, for example
>
> If you have a field name called Last Edited by this field is locked and not
> editable using the Lock attributes flag, but if you had Subt on edit
> everytime that entry is updated it places your login name into this field
and
> therefore stamps it to say you have edited it, as the field isnt free txt
it
> cant be spoofed as the $long_name comes from your login details.
Ok, I implemented "Subst on edit", it will be contained in Version 2.3.1
which is supposed to come out next week.
- Stefan |
|
218
|
Wed Feb 12 01:11:08 2003 |
| Nick | Nick@nick.com | Info | | | Re: Feature request | > > Can you consider implementing the following additions to the functionality
> >
> > 1) Subt on edit <attribute> = xyz
> >
> > This would be fantastic for implementing version control so you can see
> who
> > has edited a posted or a db entry.
>
> Can you give me an example of how you would use that?
-----
Lets say you are storing configuration information relating to a customers
solution, you need the ability to track who has made what changes to the
config information stored in the log book so you can backtrack who changed
what and when, for example
If you have a field name called Last Edited by this field is locked and not
editable using the Lock attributes flag, but if you had Subt on edit
everytime that entry is updated it places your login name into this field and
therefore stamps it to say you have edited it, as the field isnt free txt it
cant be spoofed as the $long_name comes from your login details.
-----
>
> > 2) Have a SORT fieldname flag so you can decide which column to sort
> things
> > by on a display listing in conjunction to the display flags, it current
> > defaults to the # column and I find i am directly linking to a sorted
> > display
>
> Sorting is not done by the "#" column but by the sequence when messages
have
> been entered. You can sort the table differently by clicking on the table
> titles (twice for reverse sort). To sort by default on a column, for
example
> sort by the author, you can add
>
> Start page = ?sort=author
>
> into elogd.cfg which does the job.
----
Excellent I didnt know what Ill try that tomorrow
----
|
|
217
|
Tue Feb 11 11:45:22 2003 |
 | Stefan Ritt | stefan.ritt@psi.ch | Info | | | Re: Feature request | > Can you consider implementing the following additions to the functionality
>
> 1) Subt on edit <attribute> = xyz
>
> This would be fantastic for implementing version control so you can see
who
> has edited a posted or a db entry.
Can you give me an example of how you would use that?
> 2) Have a SORT fieldname flag so you can decide which column to sort
things
> by on a display listing in conjunction to the display flags, it current
> defaults to the # column and I find i am directly linking to a sorted
> display
Sorting is not done by the "#" column but by the sequence when messages have
been entered. You can sort the table differently by clicking on the table
titles (twice for reverse sort). To sort by default on a column, for example
sort by the author, you can add
Start page = ?sort=author
into elogd.cfg which does the job.
> 3) Have the elogd.conf track actual log entries people have changed
> detailing date and time etc.
Revision management is not forseen by the structure of the ELOG database.
What you can do is if you edit a message you check "Resubmit as new entry",
then you keep a copy of the old version.
> 4) Ability to export contents of the log books to files on disk for backup
> purposes as all data is contained within a single log file which causes
> problem for command line searches.
Well, you have already all log book files on disk in a simple format:
YYMMDDa.log
(Year/Month/Day) which you can easily backup. By a mask like 02*a.log you
can backup all data from 2002 and so on. The idea of having separate log
files for each day is to have this possibility to simply backup various date
intervals.
What kind of command line searches are you interested in?
- Stefan |
|
216
|
Tue Feb 11 11:26:03 2003 |
| Nick | nikc@cnic.com | Info | | | Feature request | Can you consider implementing the following additions to the functionality
1) Subt on edit <attribute> = xyz
This would be fantastic for implementing version control so you can see who
has edited a posted or a db entry.
2) Have a SORT fieldname flag so you can decide which column to sort things
by on a display listing in conjunction to the display flags, it current
defaults to the # column and I find i am directly linking to a sorted
display
3) Have the elogd.conf track actual log entries people have changed
detailing date and time etc.
4) Ability to export contents of the log books to files on disk for backup
purposes as all data is contained within a single log file which causes
problem for command line searches.
Many thanks |
|
203
|
Fri Jan 31 21:09:47 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | | | Re: Write only | > Does this truly disable the edit command or just hide it?
You're right! In some earlier versions, it did disable it, but in 2.2.5 it
just hides it. I fixed that bug and from 2.3.0 on it will really disable
that command again, such that if someone enters manually
http://midas.psi.ch/elogdemo/Forum/202?cmd=Edit
will produce and error if the command is not in the menu list. |
|
202
|
Fri Jan 31 20:47:51 2003 |
| Matthew | greggmc@yahoo.com | Info | | | Re: Write only | Does this truly disable the edit command or just hide it?
> > I'm interested using elog for a lab notebook. Once entries have been
> > entered they cannot be changed/edited.
> > Is it possible for elog to be setup to support something like this? A write
> > only mode?
>
> What you need is an entry in the elogd.cfg file:
>
> Manu commands = Back, New, Reply, Find, Config, Logout, Help
>
> As you see, the "Edit" and "Delete" commands are missing here and therefore
> do not get displayed. So you can enter a message with "New", but you cannot
> change it afterwards. |
|
201
|
Fri Jan 31 09:49:43 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | | | Re: Write only | > I'm interested using elog for a lab notebook. Once entries have been
> entered they cannot be changed/edited.
> Is it possible for elog to be setup to support something like this? A write
> only mode?
What you need is an entry in the elogd.cfg file:
Manu commands = Back, New, Reply, Find, Config, Logout, Help
As you see, the "Edit" and "Delete" commands are missing here and therefore
do not get displayed. So you can enter a message with "New", but you cannot
change it afterwards. |
|