If you need to update your DirectAdmin license manually, you can do so by running the following commands:
./getLicense.sh 123 1234
123 and 1234 are your Client ID and respectively License ID.
If there are errrors extracting the update.tar.gz file, then run the following to see the errors that show up :
head -n 1 /usr/local/directadmin/conf/license.key
If you have multiple IPs on your device and wget is binding to the incorrect one, you can specify the IP to bind to by adding it as the last argument:
./getLicense.sh 123 1234 188.8.131.52
This issue is related to PAM not authenticating the users correctly anymore because of a few possible modifications, or something got screwed up on your server.
If you get this error you may wan to try and see if the user that is trying to run that cron exists under
As Andrew pointed up in one of the comments you can also get this error if the cron user’s account has expired so you may want to verify that before going ahead.
If you hardened your server security using some of the scripts that are floating around the internet and now get a
CRON (username) ERROR: failed to open PAM security session: Success error you may wan to check the
/var/log/secure log file and check for any references to cron like:
Jul 7 16:30:01 server crond: pam_access(crond:account): access denied for user `username' from `cron'
A fix for this is to check the following two files and make sure that the lines in there match the following:
/etc/pam.d/crond file should contain the following lines:
auth sufficient pam_rootok.so
auth required pam_env.so
auth include system-auth
#account sufficient pam_rootok.so
account required pam_access.so
account include system-auth
session required pam_loginuid.so
session include system-auth
Check the commented line
#account sufficient pam_rootok.so and if you see this line in there and uncommented the comment it out.
Secondly check the
/etc/security/access.conf file and if you see at the end of this file anything that is uncommented like:
-:ALL EXCEPT root:LOCAL
+ : ALL : cron crond
then comment this two lines also.
Check your cron log file after this and see if the cron will run correctly.
When trying to restart named process after making modifications may end up in a corrupt rndc.key key and the error will show like this:
Jul 7 08:10:46 server named: /etc/rndc.key:1: configuring key 'rndc-key': bad base64 encoding
Jul 7 08:10:46 server named: loading configuration: bad base64 encoding
Jul 7 08:10:46 server named: exiting (due to fatal error)
A simple explanation to this is that the key got modified somehow.
What to do about this? Well it is simple just check the
/etc/rndc.conf file and copy the key from there(you will see the key in the first lines of the file) and replace the key that it is in
/etc/rndc.key file and restart named process.