Dear users,

we started an elog serveur (using ssl) and open to the world which is working fine.

However I am trying to access it via the command line client, from a computer that uses a proxy to connect to internet.

The environnment variable are set :

declare -x ftp_proxy="ftp://myproxy:3128/"
declare -x http_proxy="http://myproxy:3128/"
declare -x https_proxy="https://myproxy:3128/"
declare -x socks_proxy="socks://myproxy:3128/"
 

but when I try to connect

elog  -h myelog -p 443 -l lognote -s 1 -u username passwd  -w last

I have the following message :

Cannot connect to host myelog, port 44

How should I proceed ?

Best regards

JG

:

Hello,

Let's say I have a logboook where I define two attributes:

[TOTEM]
Comment = TOTEM Gas System Status
Attributes = Author, D, M, Y, h, min, ...

I would like to modify the "Last submission" so that I display something like %D/%M/%Y, %h:%min

so in my elogd.cfg I added this line:

Last submission = $D / $M / $Y , $h : $min by $Author

however, when display in the selection page instead of getting $min displayed i get the attribute $M+'in' displayed. How does attributes substitution work? is it case unsensitive? how does it behave when different attributes starts with the same name?

 How can I block access to some tools (like edit, erase, config...) for each user? I want only admin users can edit, erase , etc. 

I want know too, how can I erase configuration of SMTP?  I make a test with the "elogd -t" command and now every time I create a new entry in my log book I receve the mensage of error to send email, cause I don't configure a SMTP host. 

 Thanks for help. It work's. 

 But I want to know if I can block a logbook from a user. For example I have a logbook named "Store". I want only users of the vendors have access to this log. How can I do it? 

I didn't find this in manual.

 The only way I find for this trouble is using the "Login user". But we have something best?

I have been trying to build and run elog under Mac OS  X 10.2.6, without sucess.  I 
understand that this is not one of the 'supported' platforms, but I hope that there is someone   
here who might know the work-around to my problem.

I've tried building elog 2.2.5, 2.3.6, 2.3.7, and 2.3.8.  I've tried using the compiler that comes 
in the Mac OS X 10.2 box, as well as the gcc-based compiler supplied in Apple's Dec 2002 
developer update (gcc 3.1), and the June '03 update as well (gcc 3.3).

elog builds without error in all cases I tried.

When I run it, it will correctly serve the demo notebook.  However, when the user clicks on the 
test message to display it in full, there is a seg fault.

I suspect that the trouble might be with something defined in time.h.

I've run it in gdb, and the result is appended to this message.  This is for gcc 3.3 and elog 
2.3.8.


I would greatly appreciate any hints or suggestions.

Cheers, Joe

---

[satsuma:~/Documents/elog_build/elog-2.3.8] jgiaime% gdb ./elogd
GNU gdb 5.3-20030128 (Apple version gdb-282) (Fri Jun 13 03:33:07 GMT 2003)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin".
Reading symbols for shared libraries .. done
(gdb) run
Starting program: /Users/jgiaime/Documents/elog_build/elog-2.3.8/elogd 
Reading symbols for shared libraries . done
Indexing logbook "demo" ... ok
Server listening on port 8080...

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00005870 in el_retrieve (lbs=0x1, message_id=50, date=0xbfff2500 "demo", 
attr_list=0x0, attrib=0x365620, n_attr=1, text=0xbfff2280 "1", textsize=0x1, 
in_reply_to=0x0, reply_to=0x0, attachment=0x0, encoding=0x0, locked_by=0x0) at src/
elogd.c:2775
2775    {
(gdb) up
#1  0x0001d9b4 in interprete (lbook=0x1 <Address 0x1 out of bounds>, path=0xbfff2280 
"1") at src/elogd.c:12279
12279       show_elog_message(lbs, dec_path, command);
(gdb) up
#2  0x0001db10 in decode_get (logbook=0xbffff340 "demo", string=0x3a300a "1") at src/
elogd.c:12325
12325     interprete(logbook, path);
(gdb) up
#3  0x00020080 in server_loop (tcp_port=836736, daemon=-1073732640) at src/
elogd.c:13398
13398             decode_get(logbook, p);
(gdb) up
#4  0x00021134 in main (argc=1, argv=0xbffff850) at src/elogd.c:13832
13832     server_loop(tcp_port, daemon);
(gdb) up
Initial frame selected; you cannot go up.
(gdb) 

Sridhar & Recai,

Thanks to both of you for the rapid and effective advice.  Fixing the limit corrected my problem.  
I think I last got tripped up this way 10 years ago...

I suppose that the advice to increase Mac OS X's default stacksize limit might make a fine entry 
in the FAQ or README file.

Thanks again,
Joe 

> > elogd binary from EPEL
> 
> thank you for bringing this up to our attention. we recently went through this with debian and ubuntu. the elog package was severely out of date and 
> did not include the security patches that went it right before covid started in the Winter of 2020.
> 
> the elogd package in EPEL7 is insecure and should not be used. (I see it is removed from EPEL8, EPEL9 and current Fedora).
> 
> I will have to contact EPEL maintainers to have it removed from EPEL7 (or at least to have it marked as "insecure, do not use").
> 
> https://dl.fedoraproject.org/pub/epel/7/SRPMS/Packages/e/elog-3.1.4-1.20190113git283534d97d5a.el7.src.rpm
> 
> https://packages.fedoraproject.org/pkgs/elog/elog/
> https://packages.fedoraproject.org/pkgs/elog/elog/fedora-35.html
> https://packages.fedoraproject.org/pkgs/elog/elog/epel-7.html
> 
> note in the changelog "Update to post-release snapshot of 3.1.4. - Fix several security issues."
> 
> K.O.


Good day, elog has never been retired in EPEL 7. It is still there
https://src.fedoraproject.org/rpms/elog/tree/epel7

I am pretty sure because I am a Fedora/RHEL package maintainer and a retired package should contain in its Git branch only a file named "dead.package"