Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 781 of 806  Not logged in ELOG logo
ID Date Icon Author Author Email Categorydown OS ELOG Version Subject
  68427   Wed Sep 21 17:23:15 2016 Reply Stefan Rittstefan.ritt@psi.chBug fixLinux3.0.0Re: notification error services in CentOS 6.5

Ok, I will include this patch in the distribution.

Stefan

Darren Hollinrake wrote:

The quick fix I found was to uncomment line 10 in the init.d file. (This was tested on a CentOS 6.8 AWS instance.)

. /etc/rc.d/init.d/functions

This will allow the status command to function properly.

Clean install:

[centos@ip-172-31-51-59 ~]$ service elogd status
status: invalid option: -p
 

After uncommenting line 10:

[centos@ip-172-31-51-59 ~]$ service elogd status
elogd (pid  11438) is running...

When you start elog it still won't show that the service started successfully (No 'OK'). If you go to stop the service, it will give you the proper 'OK' indicating it stopped successfully.

So to fix the missing 'OK' (or 'FAILED') we need to update the start section around line 51 as follows:

          touch /var/lock/subsys/elogd
        echo_success
        else
        echo_failure
        fi
        echo
        ;;
 

I've attached my modified init file which I believe corrects the above issues. I will say though that I'm not a programmer so I won't guarantee it's perfect. I haven't checked to see if CentOS 7 works with this modified version. Just checked it on a CentOS 7.2 AWS instance and it also appears to function correctly.

[root@oceana ~]# systemctl status elogd
● elogd.service - SYSV: ELOG is a weblog with integrated database
   Loaded: loaded (/etc/rc.d/init.d/elogd)
   Active: active (running) since Sun 2016-09-18 22:35:44 UTC; 7s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2263 ExecStop=/etc/rc.d/init.d/elogd stop (code=exited, status=0/SUCCESS)
  Process: 2275 ExecStart=/etc/rc.d/init.d/elogd start (code=exited, status=0/SUCCESS)
 Main PID: 2277 (elogd)
   CGroup: /system.slice/elogd.service
           └─2277 /usr/local/sbin/elogd -D -c /usr/local/elog/elogd.cfg

Sep 18 22:35:44 oceana elogd[2277]: elogd 3.1.1 built Aug  4 20...0
Sep 18 22:35:44 oceana elogd[2277]: revision
Sep 18 22:35:44 oceana elogd[2277]: Falling back to default gro..."
Sep 18 22:35:44 oceana elogd[2277]: Falling back to default use..."
Sep 18 22:35:44 oceana elogd[2277]: CKeditor detected
Sep 18 22:35:44 oceana systemd[1]: Started SYSV: ELOG is a webl....
Sep 18 22:35:44 oceana elogd[2279]: Falling back to default gro..."
Sep 18 22:35:44 oceana elogd[2279]: Falling back to default use..."
Sep 18 22:35:44 oceana elogd[2277]: ImageMagick detected
Sep 18 22:35:44 oceana elogd[2277]: SSLServer listening on port....
Hint: Some lines were ellipsized, use -l to show in full.

The old SysV style commands ('service elogd start|stop|status') also function correctly.

[root@oceana ~]# service elogd stop
Stopping elogd (via systemctl):                            [  OK  ]
[root@oceana ~]# service elogd start
Starting elogd (via systemctl):                            [  OK  ]

 

Stefan Ritt wrote:

The init script supplied with elog was originally written for Redhat. It seems like CentOS has slightly changed the init daemon management, but I'm not an expert on that, nor do I have CentOS installed. If somebody comes with a fixed elogd.init for CentOS, I'm happy to include that in the distribution.

/Stefan

Banata wrote:

hello, I just upgrade from 2.9 into 3.0.0 in CentOS 6.5

but after upgrade, I can't check elogd services via command line

service elogd status,

always result in missing argument, while it works with httpd or mysqld services and old elogd version.

I try to uninstall and install rom scratch and same result,

Okay I give you screenshoot of that,

you may notice, on check service status and stopping services, error resulted

 

 

 

  68512   Fri Dec 16 14:44:19 2016 Agree Stefano Bonaldostefano.bonaldo.13@gmail.comBug fixMac OSX3.1.2Re: elogd crash on sorting the entries by an datetime attribute

Bug FIXED! Many thanks Stefan and my warmest congratulations for the elog project.

Stefano

 

Stefan Ritt wrote:

Ok I found it!

Was tricky. In my development environment (XCode) it worked fine. Only when I compiled elogd under Sierra on the command line, the probelm occured. That's why I did not see it earlier. It has to do with some functions Apple apparently changed ("strlcpy"). These function now have a new "functionality": When two parameters overlap, the function just aborts the process. This is specific to Sierre, so on any other Linux this does not happen. I changed now the soruce code to take care of the modified functions, and now it works fine. Please update to the newest GIT revision of elogd and recompile.

Stefan

 

  69589   Fri Dec 2 14:12:35 2022 Warning Laurent Jean-Rigaudlollspam@free.frBug fixLinux3.14 gitBuildrpm / copy .cxx in place of .c

Hi Stefan,

It seems buildrpm should be updated to take care of cpp files. Plz replace "cp <blahblah>.c ..." by "cp <blahblah>.cxx ..." .

Also, uncomment the hostname test witch activates all authentification options by default. It should be done by adding options as follow : buildrpm ver rel -ldap -ker ...

By default, i can not build elog with LDAP.

 

After that mods, rpms are builded under EL7 (w/o LDAP support which is not useful for me).

 

Bye

Laurent

  69596   Thu Dec 29 20:26:11 2022 Reply Andreykowaraj4stuff@gmail.comBug fixAllELOG V3.1.4-493a hack around

FYI.

Removing "wrap=hard" on the line #11461 in the elogd.cxx file resolves my problem.

 

- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);*/
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);

  69597   Fri Dec 30 00:46:03 2022 Reply Konstantin Olchanskiolchansk@triumf.caBug fixAllELOG V3.1.4-493a hack around
- rsprintf(&quot;&lt;textarea rows=%d cols=%d wrap=hard name=\&quot;Text\&quot;&gt;\n&quot;, height, width);
+ rsprintf(&quot;&lt;textarea rows=%d cols=%d name=\&quot;Text\&quot;&gt;\n&quot;, height, width);

my vote is to remove "wrap=hard":

1) I try to read the specs and my head explodes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
2) textarea should just accept input typed by user, should not try to "neatify" it. if user wants long lines, we should let them.
3) this bug (introduced in recent safari, the best I can tell)

K.O.
  69599   Wed Jan 4 09:33:25 2023 Reply Stefan Rittstefan.ritt@psi.chBug fixAllELOG V3.1.4-493a hack around
> - rsprintf(&quot;&lt;textarea rows=%d cols=%d wrap=hard name=\&quot;Text\&quot;&gt;\n&quot;, height, width);
> + rsprintf(&quot;&lt;textarea rows=%d cols=%d name=\&quot;Text\&quot;&gt;\n&quot;, height, width);
> 
> my vote is to remove "wrap=hard":
> 
> 1) I try to read the specs and my head explodes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
> 2) textarea should just accept input typed by user, should not try to "neatify" it. if user wants long lines, we should let them.
> 3) this bug (introduced in recent safari, the best I can tell)
> 
> K.O.

I agree with K.O. Does anybody see a problem in removing "wrap=hard"? 

It was there more for historical reasons. In the old days screens were not so wide and wrapping was more of an issue.
People tended to write longer lines and complained that the long lines got reformatted differently for different screen
sizes. So by adding hard CRLF the formatting looked the same on different screens. These days this is not such an issue
any more and I agree with 2) above. If the user wants a long line, the user should get it.

Stefan
  69600   Wed Jan 4 09:39:38 2023 Reply Stefan Rittstefan.ritt@psi.chBug fixAllELOG V3.1.4-493a hack around
Ahh, now I remember. Well, the I put that in like 25 years ago ;-)

Let's assume the user write a very long line and relies on the wrapping of the text box. So the input might look like the 
first attachment. Then the user hits submit and gets just one long line (second attachment) and has to scroll one kilometre
to the right to see the full line. So there is an inconsistency between the entry form and what the user sees after the
submission. Having "wrap=hard" tells the browser to put CRLF where the wrapping in the textarea happens, so the text looks
the same during entry and after submission. If we remove the "wrap=hard", we would be back to the situation below in the two
attachments.

Opinions?

Stefan
Attachment 1: Screenshot_2023-01-04_at_9.38.51_.png
Screenshot_2023-01-04_at_9.38.51_.png
Attachment 2: Screenshot_2023-01-04_at_9.39.09_.png
Screenshot_2023-01-04_at_9.39.09_.png
  69601   Wed Jan 4 10:05:38 2023 Reply Andrey Pashninkowaraj4stuff@gmail.comBug fixAllELOG V3.1.4-493editing on a smartphone
oh! so, that's the cause of another problem I faced a while ago. 
When people edited an ELOG page on a narrow screen device (a.k.a smartphone) it put the extra CRLF and made the page look like the attachment below 
(it broke the original formatting).

I had to "fix" this by setting the width of the textarea to a huge number... 

However, removing "wrap=hard" solves both these problems! ;)
Attachment 1: Screenshot_2023-01-04_at_10.06.02.png
Screenshot_2023-01-04_at_10.06.02.png
ELOG V3.1.5-3fb85fa6