Fri Sep 10 10:12:43 +07 2021

Configuring PHP SSL for Joomla and Horde

When it comes to authentication with MySQL, it seems that PHP is pushing for an hardcore SSL authentication rather than a simple encryption of the connection. The documentation about simple encryption is scarce and overwhelmed by the documentation about SHA256 or X509 authentication.

This translates into Joomal and Horde offering only some authentication schemes that do not correspond to what I am looking for.

There is no configuration option neither in Joomal nor in Horde to enable simple SSL encryption of the connection, as provided by MySQL user's ssl_type="ANY".

Joomla and Horde have to be patched to work the way I want. The patches are listed bellow.

Patch for Joomla

This patch has to change the connection from mysqli_connect to mysqli_real_connect in order to accept the SSL options. This also mean that the connection has to be created with mysqli_initfirst.

The file to patch is /web/csim/htdocs/joomla3/libraries/joomla/database/driver/mysqli.php.

--- mysqli.php.orig	2021-09-08 13:45:56.087238000 +0700
+++ /web/csim/htdocs/joomla3/libraries/joomla/database/driver/mysqli.php	2021-09-08 14:04:00.270357000 +0700
@@ -86,7 +86,33 @@
 		// Finalize initialisation.
+	/**	
+	* Adds SSL functionality to mysqli
+	*
+	* @return MySQL_Connection Returns mysqli connection if the database connected successfully.
+	* Based on
+	* @notice CUSTOM EDIT
+	*/
+    	public function ssl_mysqli_connect($host, $user, $password, $database, $port, $socket)
+	{
+	  $this->ssldberror = 'TRYING MYSQLI SSL CONNECTION';
+	  $sslconn=mysqli_init();
+	  if(!$sslconn){
+	    $this->ssldberror = "\n".'SSL DB ERROR ['.mysqli_errno($sslconn).']:'.mysqli_error($sslconn);
+	  }
+	  if($sslconn && !mysqli_real_connect($sslconn, $host, $user, $password, $database, $port, NULL, MYSQLI_CLIENT_SSL | MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT))
+	    {
+	      $this->ssldberror .= "\n".'SSL DB ERROR ['.mysqli_errno($sslconn).']:'.mysqli_error($sslconn);
+	    }
+	  return $sslconn;
+	}
 	 * Connects to the database if needed.
@@ -163,14 +189,16 @@
 			throw new JDatabaseExceptionUnsupported('The MySQLi extension for PHP is not installed or enabled.');
-		$this->connection = @mysqli_connect(
-			$this->options['host'], $this->options['user'], $this->options['password'], null, $this->options['port'], $this->options['socket']
+		$this->connection = $this->ssl_mysqli_connect(
+			$this->options['host'], $this->options['user'], $this->options['password'],
+			$this->options['database'], $this->options['port'], $this->options['socket']
 		// Attempt to connect to the server.
 		if (!$this->connection)
-			throw new JDatabaseExceptionConnecting('Could not connect to MySQL server.');
+			throw new JDatabaseExceptionConnecting('Could not connect to MySQL server.'."\n".
+			$this->ssldberror);
 		// Set sql_mode to non_strict mode

Patch for Horde

This patch is more simple, as it only needs to add the proper SSL options. The file to patch is /usr/local/share/pear/Horde/Db/Adapter/Pdo/Base.php.

--- Base.php~	2021-01-16 00:06:57.292776000 +0700
+++ /usr/local/share/pear/Horde/Db/Adapter/Pdo/Base.php	2021-09-08 16:23:54.040976000 +0700
@@ -39,7 +39,12 @@
         list($dsn, $user, $pass) = $this->_parseConfig();
         try {
-            $pdo = @new PDO($dsn, $user, $pass);
+	    $options = array(
+	                 PDO::MYSQL_ATTR_SSL_CA => true,
+			);
+            $pdo = @new PDO($dsn, $user, $pass, $options);
         } catch (PDOException $e) {
             $msg = 'Could not instantiate PDO. PDOException: '
                 . $e->getMessage();

Posted by Olivier | Permanent link | File under: administration, database, php

Thu Mar 25 12:39:36 +07 2021

Of OpenVPN

Cryptic title, see Steinbeck.

VMware ESXi has some mechanisms on the virtual switches to filter out packets coming from MAC addresses that does not correspond to addresses assignes to virtual machines.

A VPN sees the MAC of its clients that are coming trhough the encrypted tunnel. But ESXi deems these MAC as forged and the packets are not transmitted.

The virtual switch must have the security set to allow Promiscuous mode and Forged transits.

Posted by Olivier | Permanent link

Thu Oct 8 15:19:50 +07 2020

ClamAV Unofficial and Malware Patrol

OK, so I think I have a better understanding of ClamAV Unofficial signatures. It is all based upon the shell script by

In the configuration file, it is clear that /var/db/clamav-unofficial-sigs is only a working directory, but the signatures will end-up in /var/db/clamav. A working directory, so there is no reason to run a second instance of ClamAV from that directory; the first and only needed instance of ClamAV will pick-up the new unofficial signatures when they are installed in the signature directory.

So I killed the second instance of ClamAV (launched from /etc/rc.local). But I kept clamd-un.conf, just in case.

Now the problem with Malware Patrol: because malware is being distributed from Google Drive root they flag anything that contains the string It cannot work for us as it will flag any email that mention a document stored in Google Drive and cause disruption in our work.

The solution I have implemented is to have a Perl script (/usr/local/bin/ that is called by the ClamAV Unofficial script where it would call clamdscan --reload. My Perl script removes the signatures for Google Drive and executes the reload.

My Perl script is a dirty hack as I have started developping it based on the assumption that ClamAV signature reload was triggered by a signal. The skeleton f that is still in the script. All locations and stings are hard coded to fit my needs.And it can be modified is some future white listing must be applied.

Posted by Olivier | Permanent link | File under: administration, mail, anti-virus

Thu Sep 17 11:08:28 +07 2020

Managing multiple disks with virtual tapes for Amanda: chg-vdisk

The system chg-vdisk

Amanda introduced virtual tapes (vtape) to store backups on a disk instead of magnetc tapes. At the time, Amanda could pnly use a single disk to store virtual tapes; if you had several disks, it was suggested to use some disk concatenation like RAID 0.

While a solution, I think that it is not the best solution: if a single disk is to fail, the RAID is not available anymore and one lose all the backups. Using a RAID of higher level is not ideal, I would prefer to trade the reliability of RAID for more backup storage and more incremental backups.

To that effect, I have modified the tape changer for vtapes chg-disk to work on a bunch of disks.

Each disk is mounted at a mounting point in Unix. At this mounting point there must be a directory amanda that belongs to the user and group running Amanda server.

In the directory amanda there must exist a file called disklabel that contains a unique name for that disk that will be used further in the configuration. The directory amanda also contains the slots as defined by the vtapes. The slots are numbered in sequence across all the vdisks, 1 to a for the first disk, a+1 to b for the second disk, b+1 to c for the third, etc.

A configuration chg-vdisk.conf file must be created in Amanda configuration directory (where the file amanda.conf is saved). It will be described later.

Two files, chg-vdisk.cache.db and chg-vdisk.current, are created by chg-vdisk in that same Amanda configuration directory and should not be changed by the user.

The configuration file chg-vdisk.conf

The configuration file of chg-vdisk resides in the Amanda configuration directory and follow the syntax of Config::IniFiles of Perl, with sections between square brackets ([...]) and a list of parameter=value.

  • [syslog] defines options used by syslog:
    • facility= the facility used to log syslog messages.
  • [options] defines general options:
    • path= the path of Amanda configuration directory;
    • pid_file= the path of the file to store chg-vdisk pid;
    • lock_file= the path of the file that chg-vdisk can use for locking operation;
    • timeout= (obsolete, see below) the timeout in seconds to wait for autmount;
    • signal= (obsolete) the signal thatthe operator can send to chg-vdisk once the requested disk has been mounted.
  • [mountpoints] defines the list of mount points used by the disks, each parameter if of the form:
    • /path/to/the/mountpoint=1 where /path/to/the/mountpoint is the equivalent of the disk mountpoint in /etc/fstab. Note that the =1 is dictated by the file format that must associate a value to each entry.
  • [disklabel] for each disk in the system, there is a section named by the disklabel of the disk:
    • first-slot= is the first slot that exist on that disk;
    • last-slot= is the last slot that exist on that disk.
  • [email] (obsolete) defines the email address of the operator:
    • mailto= is the email address used for the recipient, uses Amanda configuration value by default;
    • mailfrom= is the email address used for the sender;
    • mailrepeat= is the frequency, in seconds, to send repeated email.
  • [week] and [holiday] (obsolete) define the date and time when an operator is present and can swap disks (see below). The syntax is equivalent to the one used for CSIM access control.

Adding a disk to the system

This presuppose that the disk is running and attached to the Unix server.

If you want to add a new disk to the system, there are two steps for initialisation of the new vdisk and one step for mounting the disk; if you need to mount a disk that has already been initialised and used, for example an old disk that has been retired but still holds backups, jump to the step 3:

  1. initialize the new vdisk and create the slots:

    You must create directory amanda and the file disklabel at the root of the vdisk; these must belong to the user and group running Amanda.

    Then the slots are created with the script ~on/create_slot:

    sudo ~on/create_slot disklabel #slot

    where disklabel is the label used in the file disklabel and #slot is the number of slots you want to create on that disk.

    For CSIM, each vtape is 110GB, so a 6TB disk would allow about 53 slots.

    Note that the slots are created with number starting at zero;

  2. initialize new new vtapes in the slots of the new vdisk:

    The script ~on/label_slot creates new vtapes in each slots of the disk disklabel; it uses amlabel internally and must be run by the user amanda.

    You can run the command:

    sudo -u amanda ~on/label_slot disklabel

    where disklabel is the same as above. Vtapes will have a sequential number starting from the maximum number found in the file tapelist;

  3. mount the vdisk:

    This step renumbers all the slots of the vdisks accessible on the server to make sure that the slot number are in sequence, this is because Amanda tape changer expects slots that are numbered in sequence from 1 to the maximum while adding a disk may introduce gaps or duplicated.

    This script does not change the vtapes or the contents of the backups that are present on the disks, only the slot numbers are modified, it is safe to run this scipt on disks that alread contain backups.

    The script ~on/renum_slot do the renumbering and issue a piece of configuration that must be updated manually inside chg-vdisk.conf. This script nust be run by root.

    You can simply issue the command:

    sudo ~on/renum_slot

    as a result you will get some information of the form:

    [disk CSIM-set-10]
    # mounted on /host/localhost/ada2
    [disk CSIM-set-11]
    # mounted on /host/localhost/ada1
    [disk CSIM-set-13]
    # mounted on /host/localhost/ada7

    This is to replace the corresponding section in chg-vdisk configuration file.

Removing a disk from the system

It may be necessary to remove a disk from the system if the disk has failed and became unusable or if a newer and larger disk would be installed.

Once the disk jas been physically removed from the server, two steps must be done:

  1. renumber the slots for the remaining disks:

    The script ~on/renum_slot is used and the output must be imported into chg-vdisk configuration, as described above;

  2. make Amanda aware that the vtapes are not mounted anymore and should be marked no-reuse:

    The script ~on/unlabel_slot can be used to make a list of vtapes listed as reuse in the file tapelist but that are not loaded in any slot. It must be used by TODO.

    The script outputs a list of vtapes that can be used to manually issue a command amadmin no-reuse. If the disk has been destroyed, the command TODO may be prefered to completely remove the vtapes from tapelist.

Disk automouting on FreeBSD

The other files created by chg-vdisk

  • chg-vdisk.current: the notion of a tape currently loaded in the tape changer is moot for vtapes, but it is part of the API for the tape changers in Amanda. This file keeps track of the tape "currently" in the changer.
  • chg-vdisk.cache.db: the system needs to keep a link between the slots and the vtape present in each slot. This information does not change frequently so it would a waste of resources to compute it again each time the the vdisk changer is called. This database keeps track of the vtapes mounted in the slots.

    When a certain vtape is needed, the slot number in the chache is checked first, and if the vtape on disk at this slot is the expected one, chg-vdisk continues its its operation. Else, if the vtape in the slot is different from the one cached, all the disks are read, one slot at a time and a new cache is saved.

Some other features

i originally envisioned chg-vdisk to work with USB attached disks, where a limited number of USB slots were available. The system would have been able to find out which of the disks were currently pluged in and request an operator to switch disk appropriately.

USB disk were slow and SATA interface rendered all that part very obsolete. But that is the reason of the part regarding email and holidays in the configuration file.

Finally, chg-vdisk should be modified to run as a multi-changer as it can write on several disks or files at the same time, but that has never been the bottleneck with vtapes, so it runs one vtape at a time.

Posted by Olivier | Permanent link | File under: administration, backup

Thu Jul 16 11:44:23 +07 2020

Add MAC address to the filter for SMC smart classroom

Smart classroom are set to use the specific SSID SMC.In order to prevent anyone using that SSID, a filtering has been setup on the MAC addresses of the devices that are allowed to connect to that wireless network.

The operating system DD-WRT used on the WiFi access points in CSIM does not allow MAC filtering per SSID, only per interface, so the filtering has to be done at the wouter level.

  1. Connect to CSIM router.

  2. List the existing MAC filtering rules withe the command:
    show firewall name SMCOutFilter
    The result should look like:
    IPv4 Firewall "SMCOutFilter":
     Active on (eth3.13,IN)
    rule  action   proto     packets  bytes                                   
    ----  ------   -----     -------  -----                                   
    1     accept   all       119375   14027513                                
      condition - MAC xx:xx:xx:xx:xx:xx
    2     accept   all       2817     597981                                  
      condition - MAC yy:yy:yy:yy:yy:yy
    10000 drop     all       1902     121212                                  
  3. Enter Vyatta configuration mode, use the command:
  4. Choose the next available rule, in the above example rule 3 and add a new rule:
    set firewall name SMCOutFilter rule 3 action accept 
    set firewall name SMCOutFilter rule 3 source mac-address xx:xx:xx:xx:xx:xx
    set firewall name SMCOutFilter rule 3 description "name of the devicce"

    Where xx:xx:xx:xx:xx:xx is the MAC address of the device and name of the devicce is a short description of the device, it;s owner, etc.

  5. Verify the new rule:
    show firewall name SMCOutFilter
    You expect to see the following in the listing:
    +rule 3 {
    +    action accept
    +    description "name of the devicce"
    +    source {
    +        mac-address xx:xx:xx:xx:xx:xx
    +    }

    The symbol + at the begining of the line means the rule has been added but is not yet committed.

  6. Commit the new rule:
    And save the configuration:
  7. Tules are deleted with the command:
    delete firewall name SMCOutFilter rule n

    Where n is the number of the rule to be deleted.

    This had to be committed and saved too.

Posted by Olivier | Permanent link

Fri Oct 4 11:29:42 +07 2019

VMware monitor Dell hard disks

Starting with ESXi 6.x, VMware could not monitor Dell hard disks properly on PowerEdge 1950, 2950, R510 and R710: some specific driver is not included anymore and an error message is saying that The Small Footprint CIM Broker Daemon (SFCBD) is running, but no data has been reported. You may need to install a CIM provider for your storage adapter.

The article Monitor storage for a Dell PERC H710 Mini on vSphere 6.5 by Wil van Antwerpen suggest to install the driver directly drom Broadcom-LSI.

I downloaded the latest driver,+Controllers,+and+ICs&pf=RAID+Controller+Cards&pn=MegaRAID+SAS+9266-8i&pa=Management+Software+and+Tools MegaRAID StorCLI MR 6.6 Version: 1.14.12 StorCLI User Guide VMware this package must be used on ESXi 4.x servers. VMware-MN This package must be used on ESXi 6.x servers and onwards when the driver used is a legacy MegaRAID SAS Device Driver. VMware MN-NDS This package must be used with MR driver, lsi_mr3, which is a native driver.

Posted by Olivier | Permanent link

Fri Sep 20 15:41:21 +07 2019

Upgrading OpenLDAP

When setting a test server, the binding IP address for OpenLDAP is defined in /etc/rc.conf.

Posted by Olivier | Permanent link | File under: administration, freebsd

Fri Sep 20 15:10:00 +07 2019

Upgrading freeradius

We run freeradius in a chroot'ed environement; as such, libraries from /usr/local/lib/freeradius-x.y.z must be copied manually in the equivalent directory under /var/chroot/freeradius.

When launching a temporary test server, the IP address used to bind freeradius is defined in /usr/local/etc/raddb/sites-enabled/default (in two places).

Posted by Olivier | Permanent link | File under: administration, freebsd

Fri Sep 20 13:51:50 +07 2019

Upgrading of clamav

  1. clamav must be build with gcc:
    setenv CC /usr/local/bin/gcc
  2. On mail serveur, clamav must run as user kluser:vscan, after each update, you must change the ownsership of /var/run/clamav and /var/db/clamav (they are overwritten by the install procedure).
    You must also install the proper /usr/local/etc/rc.d/clamav-clamd script that allows to run two versions of in parallel.

Posted by Olivier | Permanent link | File under: administration, freebsd

Tue Sep 17 14:23:41 +07 2019

Dealing with Let's Encrypt certificates

First usage

  1. Install
    git clone
  2. Install nsupdate (on FreeBSD you need to install bind-tools)
  3. Set the environment variable as follow:
    Note that NSUPDATE_KEY has to be copied from Olivier's account on banyan
    These variables are only needed on the first use of script, then they are saved in the configuration file but the update.key file needs to be present any time will be run in the future.
  4. On the DNS server, make a backup of /var/chroot/named/etc/named/, update the file /var/chroot/named/etc/namedb/named.conf to add the line
    grant acme-sh-update name TXT;
    then reload DNS.

Generate a certificate

This document sumarize the various tasks to perform.

There is a serious issue with CloudFlared DNS, be sure to setenv DOH_USE 2 before attempting to generate any certificate.

The way runs, it tries to verify locally that the _acme-challenge is enabled before going further and contacting Let's Encrypt. If the verifycation is performed through CloudFlare and fails, CloudFlare seems to cache the NXDOMAIN reply for about 48 hours, preventing the process to go any further. Setting DOH_USE ensure that the preliminary verification goes through Google and when Let's Encrypt uses CloudFlkare DNS later, the chalenge has already propagated properly. Google seems imune of that cache retention.

Note: it does not work on mail, puffer, guppy no gourami. Instead, generate the certificate on ufo.

With the DNS API, generating the Let's Encrypt certificate with DNS validation can be done in a single command:

~/ --issue --dns dns_nsupdate --force --signcsr --csr /usr/local/ssl/csr/ -d

The parameter --force is required because we use sudo.

Install the certificate

  1. Change directory to ~/
  2. Check the validity of the new certificate:
    openssl x509 -noout -modulus -in | md5
    sudo openssl rsa -noout -modulus -in /usr/local/ssl/key/|md5
    Both command should provide the same output, if they are not, something went terribly wrong, abort!
  3. Check the validity of the CA:
    diff ca.cer /usr/local/ssl/ca/
    The files should be similar (it may have a difference of a blank line).
  4. For Radius, the certificate must be installed in the chrooted directory.

    If it is the first time a certificate is being generated, or if the files differ, make a backup copy of /usr/local/ssl/ca/
    sudo cp /usr/local/ssl/ca/ /usr/local/ssl/ca/
    and copy the new file ca.cer in place:
    sudo cp ca.cer /usr/local/ssl/ca/
    Note that we maintain one CA file per certificate, even if all the CA files should be the same.
  5. Change directory to /usr/local/ssl/crt
  6. Make a backup copy of
    sudo cp
    and install the new certificate:
    sudo cp ~/
  7. On the mail server, you also need to go to /usr/local/ssl/crt/courier_combined and back up and generate a new file.
  8. On puffer, you need to create a combined file that contains the certificate and the CA, save this file in ~mdailey/JupyterHub/certs/server.crt
  9. On guppy and gourami, you need to create a combined file that contains the certificate and the CA, save this file in /usr/local/JupyterHub/certs/server.crt
  10. Restart the service xxx (or reboot the mail server). For puffer you must run ~mdailey/JupyterHub/bin/ then as user mdailey.
  11. Take note of the expiry date of the certificate:
    openssl x509 -text -noout -in
            Version: 3 (0x2)
            Serial Number:
        Signature Algorithm: sha256WithRSAEncryption
            Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
                Not Before: Sep 17 05:29:35 2019 GMT
                Not After : Dec 16 05:29:35 2019 GMT
    and record the Not After date to remember updating the certificate before in expires. A good rule is to renew the certificates two weeks before expiry date, taking into account the possible holiday.

After installing the certificates

If you don't want to keep the update on DNS, change back the configuration of named.conf, and restore with a new serial-number (because each iteration of had increased the serial-number). You may also need to remove the journal file for Then reload the DNS server.

Of course, you will have to grant the update access on DNS before you generate the next run of certificates.

Posted by Olivier | Permanent link | File under: administration