UNIX for Beginners Questions & Answers

I have been searching the web for the answer to this question but without joy.
Hopefully, someone here can point me in the right direction...

We have a number of application OS accounts which require to be set with password non-expiry via the chage command, such as for example...

Code:

chage -M 0 -m 99999 -I -1 -E -1 <username>

However, the host OS VM (Exadata env) which runs on an Oracle Linux distribution was rebooted a few days ago. The below messaging was observed in the 'var/log/secure'

Code:

chage[12345]: changed password expiry for <username>
chage[67891]: changed password expiry for <other_username>
chage[01234]: changed password expiry for <some_other_user>

etc...

We uncovered this, too late, after the application account became locked due to password expiry.

I'm assuming that somewhere within the rc3 scripts, there is a something invoking this as part of init script startup but I have no idea what or why? I can't reboot again in order to script something to decipher the startup scripts and I can't seem to find any identifiable pointers as to specifically what would've been executing in or around the time.

Something has been invoked here and reset the chage properties for some accounts by resetting back to some defaults. We are using PAM for authentication.
Anyone have any idea what this might be or how to trace the origin?

Thanks
R

You want to switch off all password ageing with 'change age' (chage) so that passwords never expire??

If that's correct then try:

Code:

# chage -E -1 -M -1 <username>

Should work on most distributions of Linux.

Thanks hicksd8.

That's fine but what I really want to know is the origin of the 'chage' command messaging referenced during init (Or shortly after) in the /var/log/secure log.

I'm trying to locate the culprit script thats 'chage'ing my users without my consent....

Thanks

Hmmmm.......depending on which distribution you are running, have you tried going into the directory (e.g. /etc/rc3.d or whatever) and grep'ing everything for 'chage'??

I take your point that the log definitely seems to indicate that 'chage' is being run (at boot time) so I would try grep'ing for that.

Of course, something in rc3 could be calling something else which calling chage and that would need more detective work.

I'm answering you blind not knowing exactly which Linux dist you are running but more in depth detective work may entail:

(Make backup copies of any files you alter)

1. change the name of the 'chage' command to something else and create a script to call it whilst preceding with

Code:

echo "Running chage"

so that every time chage is run during boot it tells you on the console.

2. modify the rc3 boot script (e.g. /etc/rc3 or perhaps /etc/rc2) and insert an echo command to print the filenames of all 'S' files as it boots followed by a 'sleep 2' (2 second wait) after each. Test that it displays the name of each 'S' file on the console as it boots and slows the boot process right down.

Then you should be able to see each 'S' filename displayed before it's run AND one of them followed by "Running chage".

I've done many a booting hack such as this to very good effect in my time.

Other experts on this forum who are better at scripting than me might suggest better ideas.

Thanks - its Oracle Linux 6.9, so essentially RHEL.

Yep, that is precisely what I initially tried but no luck, and as you mentioned it could be a cascading effect of some other sub script being invoked.

Your idea to manipulate the init scripts is great, and I have done this myself in the past for debugging but for this host - reboot is not possible so no joy.

Regards
R

Okay, perhaps you are stuck with doing a system-wide 'find' of all files 'type -f' for string 'chage' and then justfying all files in the list to yourself as to why they should contain 'chage'.

I can't think of much else without rebooting unless someone on here knows your distribution inside out and backwards.