<div dir="ltr"><div class="gmail_extra">On 1 June 2013 05:04, Siddesha Dodderi Hanumantharayappa <span dir="ltr"><<a href="mailto:Siddesha.Hanumantharayappa@ness.com" target="_blank">Siddesha.Hanumantharayappa@ness.com</a>></span> wrote:<br>

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p class="">2013-05-31 11:59:01 Loading tasklist configuration from /home/xymon/server/etc/tasks.cfg</p>


<p class="">2013-05-31 11:59:01 Cannot open directory /home/xymon/server/etc/tasks.d</p></blockquote></div><br>This might be important.  Make sure that the user ID under which xymond process is running has permission to access the tasks.d directory.  For example, login as or switch to the xymon user and run 'grep -c ^ /home/xymon/server/etc/tasks.d/*'.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra" style>Although I don't think it would cause the problems you're seeing.  It seems like xymond is not running, and is causing the statusboard request to time-out.  Perhaps you can check that the IP address of <span style="font-family:arial,sans-serif;font-size:13px">161.230.144.78 is your Xymon server.</span></div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>The fping error relates to the fact that accessing a socket to send a low-level packet type (ICMP=ping) requires root privileges, and the xymon user is not permitted to do so.  It's the same for regular ping and regular users.  But most UNIX systems work around this by giving the ping binary a special permission flag called "set-UID" or "set user-ID".  Sometimes "set-GID" (set-group-ID) is set instead or as well as.  This flag tells the kernel to switch to the user and/or group that owns the file being executed, and as it is owned by the root user, it switches to root's user ID for the life of the process, so that it can do low-level packet stuff.</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style>So if you run "ls -l /bin/ping" you should find that the set-UID bit is set, indicated by an "s" in place of the "x" in the "user" permissions.  Here's mine:</div>

<div class="gmail_extra" style><br></div><div class="gmail_extra" style><div class="gmail_extra">-rwsr-xr-x 1 root root 38112 2011-02-18 06:48 /bin/ping*</div><div><br></div><div style>So this "s" means it's executable AND set-UID for the "root" user.</div>

<div style><br></div><div style>If you do the same thing for fping, you'll find it has an "x" instead of an "s", meaning it's executable, but without any special switch-user magic capability.  You can add the setuid flag with this command (run as root or under sudo):</div>

<div style><br></div><div style>chmod u+s /usr/local/sbin/fping</div><div style><br></div><div style>Before you do this, you should make sure that the fping binary is not writeable by non-root users.  If it is, then a non-root user can replace the contents of the file with their own, and they get to run it as root and then take over your machine.  Perhaps you could do something like (as root/sudo): "chmod ugo-w /usr/local/sbin/fping".  This will ensure that nobody has "write" permissions on the file.  Then check with "ls -l" and then, set the setuid flag.</div>

<div style><br></div><div style>If you're not sure about these permissions, check with your local security-aware sysadmin.</div><div style><br></div><div style>J</div><div style><br></div></div></div>