Ispconfig3: Let’s Encrypt not working

There can be several reasons for Let’s Encrypt certificates not being issued for sites. These are some things to check:

  • When creating a new website, save it first, then open it again and check Let’s encrypt and then save it (i.e. don’t check the Let’s Encrypt unless the website has been saved at least once in Ispconfig3)
  • Delete any existing certificates under the SSL tab for the website, including self signed
  • Check that all host names for the website and webaliases are pointing to the correct server
  • Use A records, not CNAME
  • Make sure there are no redirects on the website
  • Check for error messages in the log file; /var/log/letsencrypt/letsencrypt.log

Roundcube – add client’s IP-address and host name to outgoing email headers

By default, the logged in client’s IP-address and hostname are not present in the outgoing email headers which makes it hard to trace the origin in case of abuse.

To make roundcube add this to the email headers of outgoing email, put this in the roundcube configuration file:

// put user's ip and host name in mail headers to enable trace
$config['http_received_header'] = true;

Ispconfig3: awstats/webalizer not working, client web logs empty

If awstats or webalizer is not containing any data and the client web logs are empty, the cause might be missing mounts of the log directories in /etc/fstab.

Search /etc/fstab for the client domain name. If no log mount is found, add a line for the client web site manually in this form:

/var/log/ispconfig/httpd/DOMAIN.COM /var/www/clients/clientNNN/webNNN/log    none    bind,nobootwait    0 0

After that do:

mount -a
mount

to verify it is mounted. After nightly cron, check that awstats or webalizer contains data.

Asterisk / FreePBX sip trunk registration problem, Serious Network Trouble

The asterisk log file (/var/log/asterisk/full) shows entries like this:

[Sep  3 04:02:08] ERROR[3984] chan_sip.c: Serious Network Trouble; __sip_xmit returns error for pkt data

Solution: The server had been moved from one public IP-address to another. In Asterisk PBX settings, the fields for both External IP and Bind Address (under Advanced) needed adjustment to the new IP-address. After server reload everything worked normally.

/etc/cron.daily/amavisd-new: Please run this cronjob as user amavis

After a system update I started to receive cron messages saying “/etc/cron.daily/amavisd-new:
Please run this cronjob as user amavis”.

It turns out that this happens because the cron script is replaced by a new one located in /etc/cron.d and the one in /etc/cron.daily is left behind giving this error message.

Solution: After checking that the new script exists in /etc/cron.d, just delete /etc/cron.daily/amavisd-new

More information about this here (bug report).

MySQL 5.7 and mysql_secure_installation

If you are using mysql:secure_installation witch you should, beware of that the script reset all passwords in the SQL server database mysql. To fix this problem use the following.
Root password:
ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘MyNewPass’;
Session password:
ALTER USER ‘mysql.session’@’localhost’ IDENTIFIED BY ‘password’ PASSWORD EXPIRE NEVER;

Exampel error messages:
ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.

Netbeans and git over ssh

Netbeans 8.2, git clone over ssh “Incorrect credentials for repository at ssh://”

Trying to git clone a repository over ssh in Netbeans 8.2 displaying an error message saying “Incorrect credentials for repository at ssh://” gave me a bit of a headache. I could successfully connect to the repository server using ssh from the terminal in my Mac running OSX.

Netbeans and git over ssh

After spending some time troubleshooting I tried to check for updates in Netbeans and that gave me an error message saying Netbeans could connect to the Internet in order to check for updates.

It turned out the problem was not incorrect credentials for SSH when trying to git clone, but in reality Netbeans could just not access the Internet. This was caused by the TripMode application I am using to control which applications can access the Internet when I am on mobile broadband where data rates applies.

So the error message “Incorrect credentials for repository at ssh://” in Netbeans can be misleading. It can be caused by the fact Netbeans just can’t connect at all to the repository server.

FreeNAS, VMware and iSCSI with MTU 9000

In order to improve perfomance there are recommendations to set the MTU for the iSCSI interface to MTU 9000 instead of the default 1500.

To do this, it important that you set MTU to 9000 on all devices involved; FreeNAS network interface, VMware NICs and vSwitch and all switch ports on the switches connecting those.

Note: When changing these settings, it will cause loss of connectivity so it might be a good idea not to do it on systems in production.

At one point I had forgotten to set the MTU to 9000 for the VMware NIC (only for the vSwitch) causing connectivity problems and error messages in the FreeNAS logs looking like this:

WARNING: 172.16.1.200 (iqn.1998-01.com.vmware:host-585e8872): no ping reply (NOP-Out) after 5 seconds; dropping connection

FreeNAS settings

  • In Network interface setup, add “mtu 9000” to options.

VMware settings

  • Networking -> VMkernel NICs -> edit -> set MTU to 9000 -> Save
  • Networking -> Virtual switches -> edit -> set MTU to 9000 -> Save

Network switch ports

  • Make sure all network switch ports all the way between the FreeNAS and VMware host have MTU set to 9000

Testing

On the VMware host, enable SSH and login using SSH. Use the command:

vmkping -s 8972 172.16.1.100 -d

Replace 172.17.1.100 above with the IP-address of your FreeNAS. -s 8972 sets packet size to 8972 bytes allowing 28 bytes for headers and -d means fragmentation should not be allowed.

If everyting works you will get echo replies. If you get the error message “Message too long” it means somewhere on the way between your VMware host and the FreeNAS there is a limit not allowing MTU 9000.

Akeeba restore error – 1118 – Row size too large (>8126) [solution]

When restoring an Akeeba backup of a WordPress site the restore process was interrupted with the error message saying 1118 – Row size too large (>8126).

Solution:

  • Use SSH to log in to your database server
  • Edit /etc/mysql/my.cnf or if you use a config file under /etc/mysql/conf.d, edit that one
  • Under the [mysqld] section add:
    internal_tmp_disk_storage_engine=MyISAM
    innodb_strict_mode = 0
  • Restart mysql:
    service mysql restart

Edit: After you successfully restored the site, remove the lines and restart MySQL. I didn’t do this and later tried to move another site from this server to another using Akeeba. When the site was installed on the new server, I just got an error message saying “Error Establishing a Database Connection”. To resolve it, I had to go back to the above server, remove the lines from mysql config, restart MySQL, make a new backup of the site using Akeeba and successfully restore it on the new server.

Credit: The solution to this problem was found here.

What Supermicro motherboard model does my server have?

When getting the latest IPMI firmware for your Supermicro server, you need to know what model of the motherboard your server has. Often the server lives in a datacenter somewhere and you don’t want to go there, take down the server, pull it out of the rack and investigate it. If you are running Linux on it, you can simply check the dmesg log for “Supermicro”.

grep Supermicro /var/log/dmesg

Supermicro motherboard model

Supermicro motherboard model