C-cronjobs has apache error???

[dcrites]

I am using the offline install process. In the middle of the install, I get this error:

Running './C-cronjobs'...
You (apache) are not allowed to access to (crontab) because of pam configuration.
RESULT=1

It errors out, and that's that. I have no idea what command it is doing as user apache that is dealing withi crontab, or why pam isn't happy about it.

1a) I removed /etc/cron.allow, and /etc/cron.deny is empty, but that made no difference.
1b) I put a dummy value into /etc/cron.deny, but that made no difference.

2) I added the line: "+ : apache : ALL" to the /etc/security/access.conf file, but it made no difference.

3) I tried forcing a complete install of apache to be successful before starting the install, but that made no difference.

So...

What can I do to get past this?

DL

[lmiltchev]

What is the output of the following commands?

Code: Select all

getenforce
umask
grep apache /etc/shadow

[dcrites]

What is the output of the following commands?

Code: Select all

getenforce
umask
grep apache /etc/shadow

Here's the output:

[svcazenoss@monprodrkn02 ~]$ getenforce; umask ; sudo grep apache /etc/shadow
Disabled
0022
[svcazenoss@monprodrkn02 ~]$

As you can see, there is no output for the grep, because apache is an AD account.

This (the account in AD) actually bit me on the rear already because the install only checks to see if nagios (which is also an AD account) is in /etc/passwd and /etc/group -- which it is not, and then errors out because it can't create the account. I had to add fake entries in the files to get around that. Will I have to do the same thing with apache?

[lmiltchev]

Will I have to do the same thing with apache?

Most probably, but I would like to point out that you are NOT installing Nagios XI on a "clean" system. Installing XI on heavily customized systems is out of scope for Nagios support. We can try to help but we cannot guarantee that your Nagios XI will install (or function after it's been installed) correctly.

Important: Nagios Enterprises highly recommends and will only support installing Nagios XI on a newly installed, "clean" system. Attempting to install Nagios XI on a pre-existing system with other applications already installed can cause the Nagios XI installation process to fail, critical system components and settings (e.g. database servers) to be modified in a way that negatively affects other applications, and previously installed applications to be automatically upgraded or removed. While installing XI on a system with other applications is possible, it is not recommended due to the possible interactions and complexity of multiple components that are required for Nagios XI to function. If you choose to ignore these warnings, you do so at your own risk.

[dcrites]

So, since I asked:

What can I do to get past this?

More attempts that have not worked:

I tried disabling PAM.

1) I used the suggestion on this web site: http://www.ehow.com/how_7623588_disable ... ation.html
There was no /etc/pam.conf, so I created one with 'skip-authentication' as the only entry.

2) I next checked out the web site: https://www.centos.org/docs/5/html/Depl ... h-pam.html
This told me that /etc/pam.conf is ignored if the directory /etc/pam.d exists, so I renamed it, then rebooted, and guess what? I now cannot log into it.
IMPORTANT SAFETY TIP: DO NOT TRY THIS STEP -- YOU HAVE TO REBOOT INTO RECOVERY MODE AND FIX IT!!!!!

So, the hope that disabling PAM is not a workaround.

DL

[dcrites]

Most probably, but I would like to point out that you are NOT installing Nagios XI on a "clean" system. Installing XI on heavily customized systems is out of scope for Nagios support. We can try to help but we cannot guarantee that your Nagios XI will install (or function after it's been installed) correctly.

This is on a "clean install," but the only way we can get into it is via the AD accounts. We cannot be the only enterprise customer who uses AD or LDAP for logins. Indeed, the reason for the install process on a production environment without "outside world" connectivity is BECAUSE it is an enterprise customer who most probably has their systems locked down so only AD/LDAP users can access them.

This installation process only runs on RHEL/CentOS, so making sure it has PAM access is something I would imagine your customers have had to deal with in the past.

So while I understand the quote above, the problems I am having are the result of what is a common environment for every company I have worked with for the past decade. So, again, I can't imagine I am unique with these issues.

DL

[bheden]

Unfortunately no, and this is the only way I know of how to install Nagios XI.

Is there no way to install the services required first via yum and then try to install XI?

Or to try and spin up a machine without connecting to AD/LDAP first AND THEN later connecting and wrapping up the pieces?

I've never had the request to install XI on an LDAP or AD controlled server. It is an interesting one that we've never even looked into. I'll add it as a Feature Request and spend some time digging up information.

If you have any suggestions, or if you get it working, I'd love some feedback in regards to how.

Thanks!

[dcrites]

If you have any suggestions, or if you get it working, I'd love some feedback in regards to how.

First suggestion: change how you look for a user/group. Right now you grep /etc/passwd and /etc/group. Try this on for size:

Code: Select all

#!/usr/bin/env bash
readonly bzero=$(basename $0 .sh)
readonly now=$(date '+%Y%m%d.%H%M%S')
readonly fname=/tmp/$bzero.$now.txt

readonly usr=${1-nagios}
readonly grp=${2-nagios}

date 1>$fname 2>&1
rcode=$(sudo chown $usr $fname 2>/dev/null || echo "nada")
if [[ "Z$rcode" == "Znada" ]] ; then
    echo "$bzero -- user $usr error"
    sudo rm -f $fname
    exit 1
    fi

rcode=$(sudo chgrp $grp $fname 2>/dev/null || echo "nada")
if [[ "Z$rcode" == "Znada" ]] ; then
    echo "$bzero -- group $usr error"
    sudo rm -f $fname
    exit 2
    fi

echo "$bzero -- ${usr}:${grp} appear to be okay"
sudo rm -f $fname
exit 0

It doesn't matter if the user or group are local, AD, LDAP, or whatever -- if they are "live" on that system, this will work.

Here is how I tested it:

$ for a in nagios goober ; do for b in nagios goober ; do ./checkuser.sh $a $b ; echo $? ; done ; done
checkuser -- nagios:nagios appear to be okay
0
checkuser -- group nagios error
2
checkuser -- user goober error
1
checkuser -- user goober error
1

[tacolover101]

If you have any suggestions, or if you get it working, I'd love some feedback in regards to how.

First suggestion: change how you look for a user/group. Right now you grep /etc/passwd and /etc/group. Try this on for size:

Code: Select all

#!/usr/bin/env bash
readonly bzero=$(basename $0 .sh)
readonly now=$(date '+%Y%m%d.%H%M%S')
readonly fname=/tmp/$bzero.$now.txt

readonly usr=${1-nagios}
readonly grp=${2-nagios}

date 1>$fname 2>&1
rcode=$(sudo chown $usr $fname 2>/dev/null || echo "nada")
if [[ "Z$rcode" == "Znada" ]] ; then
    echo "$bzero -- user $usr error"
    sudo rm -f $fname
    exit 1
    fi

rcode=$(sudo chgrp $grp $fname 2>/dev/null || echo "nada")
if [[ "Z$rcode" == "Znada" ]] ; then
    echo "$bzero -- group $usr error"
    sudo rm -f $fname
    exit 2
    fi

echo "$bzero -- ${usr}:${grp} appear to be okay"
sudo rm -f $fname
exit 0

It doesn't matter if the user or group are local, AD, LDAP, or whatever -- if they are "live" on that system, this will work.

Here is how I tested it:

$ for a in nagios goober ; do for b in nagios goober ; do ./checkuser.sh $a $b ; echo $? ; done ; done
checkuser -- nagios:nagios appear to be okay
0
checkuser -- group nagios error
2
checkuser -- user goober error
1
checkuser -- user goober error
1

kudos to you, and +1 for this thought. we use all sorts of accounts here, and this would really help to make sure an install would go properly.

[eloyd]

I do not like your script. It makes assumptions. It's also not temp file safe. Look into "man mktemp" by the way.

You can also do all this in one command:

Code: Select all

# useradd  nagios
useradd: user 'nagios' already exists

Return code is 9 in that case, by the way, so:

Code: Select all

useradd nagios 2>/dev/null
[ "$?" == "9" ] && echo "user already exists"

Will work in all cases where "useradd" exists.