If 3rd party software is installed it is quite likely that the autocomplete attribute for password fields is not set to off. Editing such settings directly in the sourceode is possible most of the time, but it’s not the nicest way and you also run into the problem that everything could be gone again after an update of the software.
A nice workaround is to use the substitute module to accomplish that.
Till now I didn’t configured any mail support for wordpress but today I wanted to enable wordpress to send mails to me and became aware that I didn’t configure postfix for my system.
In fact a basic configuration is quite easy. If the webserver should be able to send mails to an address of your choice you may hav to adapt the follwoing parameters in the /etc/postfix/main.cf:
myhostname = vps.fawcs.info
mydomain = fawcs.info
myorigin = $mydomain
After those three parameters are configured the postfix service has to be restarted: systemctl restart postfix.service
If there are still no mails comming in check if the /etc/php.ini is configured to use sendmail_path = /usr/sbin/sendmail -t -i
I also recogized that there are some mail in the inbox for the root user so I decided to also enable mail fowarding to get new mails directly to my mail-address instead of the root’s inbox.
Herfore the last line in /etc/aliases has to be uncommented to look like:
# Person who should get root’s mail
Afterwards the postfix service has to be restarted once again and in the future all mails will be forwareded to the system.
if you have troubles receiving mails the mailq command is helpful to debug problems with unsent mails or mails which get rejected by the receiving mail server. A look at the /var/log/maillog logfile is also worth a try. 😉
Mostly the following PHP.ini settings are enough to make php display errors in a production environement where error_reporting & display_errors are disabled in the PHP.ini.
But in some cases there will not be an error message displayed. The only solution I found was to enable the dispaly_errors in the php.ini.
To avoid setting this aparameter globally it could also be set in the conf-file for the virtual host which worked for me pritty fine.
Today I got some time to take care of my server so i installed the latest updates checkt the system for attacks and when I checkt my SSL-certificates i found out, that they were just valid till April 2015 … UPS … ok they are not officially signed and i just use them to encrypt sensitive communication with my server but i wanted to fix that issue and some other little issues i found when checking my blog with https://www.ssllabs.com/ssltest/analyze.html?d=blog.fawcs.info.
Because I also had to regenerate the certificates for my other subdomains I wrote a little script to do that for me (and to use it in the future, because I always have to look up the SSL-certificat generation)
So here is the script:
I also updated the security settings in my virtual host configuration files for some settings. The DH-KeyExchange cipher got excluded from the available ciphers because there is a new attack against DH which makes it vulnerable to MITM-attacks.
Extract of settings:
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH !EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS”
And it’s always a good idea to to use htaccess with extra users or IP-ACLs to secure specific directories. (for example the wp-admin directory 🙂 )
Some other interesting settings to macke apache more secure can be found her: http://www.tecmint.com/apache-security-tips/