C-cronjobs has apache error???

[dcrites]

I do not like your script.
It makes assumptions.
It's also not temp file safe.
Will work in all cases where "useradd" exists.

Liking my script is immaterial -- anything that actually does the job is good enough. Style is a personal thing. For instance, I haven't used the backtic version of running a command in years; so what?

Not sure what the"assumptions" you are talking about, but everything has to assume something.

I could replace the line creating the fname variable with, which could make it more "temp file safe." This script was pulled together from my larger script, which makes sure there is not another copy running at the same time, so the way I did it is good enough. So the style I used made sense in the grand scheme of things, perhaps not so much in this small example. There are very real style differences between minimalist quick-and-dirty scripts and those hardened for production work.

Bottom line, my example worked, or, at least, showed something that could be incorporated into the larger process.

The current installation script does not work properly. However the current installation script gets fixed so it does not tank the entire installation simply because the user exists outside of the current /etc/passwd or the group exists outside of the current /etc/group, then I'm okay with it. I was asked for a suggestion, I offered one.

[eloyd]

Backtick is the same as $(...) so I don't see much of a difference.

Yes, your script is good enough. Which is how most security issues start. I don't mean to insult you, your intelligence, or your script. I offered an alternative. I leave it to the universe to figure which one's "best" because that's not my intention. Your assumptions, however, include things like a specific PATH and sudo access. Things that always pop in my head as "security must be examined, here."

Edit: Oh, and I went back and removed the backticks from my example, just to make sure that those weren't a problem for you.

[dcrites]

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

I added code in my wrapper script to make sure all of the ancillary apps were installed -- so MySQL (mariadb) and Apache are already installed and running before the XI install script is run.

The problem isn't that Apache is being installed, it is that something is attempting to add an entry to cron, getting an error, and then tanking the installation.

DL

[tgriep]

Yes, the install is trying to create / verify that a crontab can be created by the apache user account as that account is used for certain processes Nagios XI uses.
I did find this link below you can look at to see if you can fix the pam permission issue. Take a look at it and see if the solution works for you.
https://serverfault.com/questions/62015 ... or-message

[dcrites]

Backtick is the same as $(...) so I don't see much of a difference.

Yes, your script is good enough. Which is how most security issues start. I don't mean to insult you, your intelligence, or your script. I offered an alternative. I leave it to the universe to figure which one's "best" because that's not my intention. Your assumptions, however, include things like a specific PATH and sudo access. Things that always pop in my head as "security must be examined, here."

Edit: Oh, and I went back and removed the backticks from my example, just to make sure that those weren't a problem for you.

The "problem" wasn't the backticks, it was making a comment about not liking the script, and then using an old style to show me how it should be done. There are differences between the backtick and the $(), or even between [] and [[]], but it is not my intention to get into a religious discussion about style.

And, frankly, to answer the last point, it is exactly a security issue that needs to be examined which caused me to start this thread in the first place. The current script does not work in an environment which uses secured logins via AD/LDAP. Once this thread is finished, the next problem has to do with PAM authentication for the Navios XI install making a cron entry for Apache. These are actual security issues, as opposed to stylistic or theoretical ones -- which, I admit, could be discussed from the code snipped I offered, instead of addressing the issue I brought up.

[dcrites]

Yes, the install is trying to create / verify that a crontab can be created by the apache user account as that account is used for certain processes Nagios XI uses.
I did find this link below you can look at to see if you can fix the pam permission issue. Take a look at it and see if the solution works for you.
https://serverfault.com/questions/62015 ... or-message

Thanks for the reference, but, unfortunately, both of the suggestions were already tried, and did not change things. They should have, but didn't.

Part of the problem, from what I am seeing, is back to the AD configuration. In order to get past the first issue, I had to "fake out" the install by creating dummy entries in /etc/passwd and /etc/group, which, then, don't match what AD returns. Thus the PAM error. When the first issue is solved (meaning the installation doesn't tank because the user isn't found in /etc/passwd), it might automagically solve the second one.

DL

[jomann]

We can look into making this work in a future release. I don't know all that much about how the account works when it's connected to LDAP but would we not be able to su into it still? You may be able to do something like below to get the cronjobs to install properly for the user if crontab cannot actually find the user (unless you're running as it) - I just edited the C-cronjobs script to the following at line 20-23.

Code: Select all

dir=$(pwd)
cronfile=$dir/nagiosxi/crontab.apache
(
    su $apacheuser-s /bin/bash -c "crontab $cronfile"
)
chown $apacheuser:$apachegroup /var/spool/cron/apache
chmod g+r /var/spool/cron/apache

You could also try touching the /var/spool/cron/apache file before you do the chown and chmod too, to see if that would work also.