monit-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: monit&dietlibc


From: Martin Pala
Subject: Re: monit&dietlibc
Date: Tue, 12 Aug 2003 22:22:58 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2

Hi,

i'm personally not interesting for these libraries yet (uClibc, dietlibc), so it is not my cup of tea and my +/-0 is here.

The results seems interesting, staticaly linked monit could be very useful for security reasons (however because i don't know much about these libraries => i don't know how much trustfull these libraries are - it is possible that it is not such security advantage). We are now able to test security conditions pretty well with permission, checksum, uid and gid tests - if monit will be more independent of other "normal" applications (and their libc), it could be possible to use it in emergency situations for quick security check.

Martin

Christian Hopp wrote:

Hi!

I am trying to make monit run with dietlibc right now.  So far it runs
well without ssl.  Some tweaking was necessary...

1) autoconf (and finally configure) generates a "#define malloc
  rpl_malloc", because it is not a libc malloc.  Dietlibc's malloc is
  call malloc, thus it is undefined in monitor.h for dietlibc.

2) A handmade getloadavg is used for dietlibc.

3) All sprintf are replaced by snprintf also in foo+=sprintf(foo,...)
  situations  (=> foo+=snprintf(foo,STRLEN-(foo-buf),...).

4) There is a problem with <stropts.h>... so far is simply not
  included in case dietlibc is used...  but there is still a warning by
  configure.

5) You still have to strip the binary, in order get a small result.

Results... (striped!)

(address@hidden) ~/compile/monit/monit> ldd monit
       not a dynamic executable
Exit 1
(address@hidden) ~/compile/monit/monit> ls -la monit
-rwx--x--x    1 chopp    chopp      207644 Aug 12 12:21 monit

(-: ... I would call it pretty small for a statically linked monit.
The binary dynamically linked to glibc is 180108 bytes large.

Still todo... (might be useful for other "normal" platforms)...

1) replacement of gethostbyname against gethostbyname_r because...
  "warning: gethostbyname() leaks memory.  Use gethostbyname_r instead!"

It is ready to be synced... if accepted!

CHopp










reply via email to

[Prev in Thread] Current Thread [Next in Thread]