Doerzbach Engineering GmbH

COVID 19 simulation

Covid 19 simulation

As I did not found yet an open source covid 19 simulation, I tried to write one myself.
The result can be found on github https://github.com/adoerzbach/covid19simulation. I know that no simulation really is able to predict the future of the pandemic exactly. But with a simulation you can at least try to predict the outcome of some scenarios in a scientific manner. I checked the model on the data available from the epidemic outbreak at Wuhan. It is quite near the data which I was able to find on the internet. For Switzerland I was not able to get well validated data for some parameters. The data provided is missing key figures for: How many people infected are there? How is the age structure and health condition of people hospitalized, died and having mild symptoms?
If this data would be available a much better prediction of the outcome would be possible. But I tried to get some realistic estimates from the data available on cases on cruising ships 2020 coronavirus pandemic on cruise ships and some other resources.
If you have any better data and would like to check the model, feel free.

Solaris 10 Ldap authentication with Windows AD server

Introduction

Well documented is the User Management of Solaris using a Directory Server. Thisis documented in the Solaris manuals.
How to do a SSO using a Windows AD Server is also documented on various sites.
What is less obvious and not documented is how to just authenticate (check passwords) using ldap. Thats what should be documented in this post.

Setup

Bind User in Windows AD Server

First you need to create a bind user on the Window AD Server who has the rights to lookup all usernames, which should be able to authenticate.

Setup a user:


cn=unixbind,ou=USER system,ou=yyy,dc=xxx,dc=com

This user needs only to have read-only rights on the user objects. It is used to lookup the users cn using the sAMAccountName field to do the bind.

Import the CA-Cert into the certdb

If you are going to use ldaps you need the Certification authorithy certificate. This can be a root ca of you own organisation or a ca from an official authority like verisign, which was used to sign you certificate.

To find the authority cert use:


Armins-Air:Desktop ado$ openssl x509 -noout -text -in google.crt 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 8057627504494046370 (0x6fd2718631c8eca2)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Google Trust Services, CN=Google Internet Authority G3
        ...
        ...

Here it would be "Google Internet Authority G3"

As this is an official Trust authority you can find the cert in your web browser and export it.

For Firefox: Preferences -> Privacy & Security -> Certificates -> View Certificates -> Authorities.

The cert found for Google Internet Authority G3 was:


Armins-Air:Desktop ado$ openssl x509 -noout -in GoogleInternetAuthorityG3.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            01:e3:a9:30:1c:fc:72:06:38:3f:9a:53:1d
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign


This cert was issued by GlobalSign Root CA - R2. So we get this cert from the browser too and then we check the trust chain using openssl:

We put the two certs in one file:

Armins-Air:Desktop ado$ cat GoogleInternetAuthorityG3.crt GlobalSignRootCA-R2.crt > ca.crt

and check then the cert of google.

Armins-Air:Desktop ado$ openssl verify -CAfile ca.crt google.crt 
google.crt: OK



Then create a empty certdb:

/usr/sfw/bin/certutil -N -d /var/ldap

Then import the ca cert into the db:

/usr/sfw/bin/certutil -A -d /var/ldap -i ca.crt -n xxxx.com -t 'C,C,C'

The binary /usr/sfw/bin/certutil is installed by the package SUNWtlsu

Change the pam.conf


You can use ldap authentication for all logins. This is done using this "other section":

other   auth requisite        pam_authtok_get.so.1
other   auth required         pam_dhkeys.so.1
other   auth required         pam_unix_cred.so.1
other   auth sufficient         pam_ldap.so.1
other   auth binding          pam_unix_auth.so.1 server_policy

Or you can use it only for ssh:
/

sshd-kbdint    auth requisite          pam_authtok_get.so.1
sshd-kbdint    auth required           pam_dhkeys.so.1
sshd-kbdint    auth required           pam_unix_cred.so.1
sshd-kbdint   auth binding         pam_ldap.so.1
sshd-password    auth requisite          pam_authtok_get.so.1
sshd-password    auth required           pam_dhkeys.so.1
sshd-password    auth required           pam_unix_cred.so.1
sshd-password   auth binding         pam_ldap.so.1

Then on the console no ldap authentication is used.

Setup ldap client


ldapclient manual \
-a domainName=xxx.com \
-a credentialLevel=proxy \
-a authenticationMethod=tls:simple \
-a defaultSearchBase=dc=xxx,dc=com \
-a "proxyDN=cn=unixbind,ou=USER system,ou=LI,dc=xxx,dc=com" \
-a proxyPassword=wassimmer \
-a objectClassMap=passwd:posixaccount=user \
-a attributeMap=passwd:uid=sAMAccountName \
-a serviceSearchDescriptor=passwd:dc=xxx,dc=com?sub \
-a followReferrals=false \
-a preferredServerList="10.10.1.1"

 
This will create to files in /var/ldap :

/var/ldap/ldap_client_cred: Bind user with its encrypted password
/var/ldap/ldap_client_file: The configration of the ldap service


Start ldap Service

Now we just have to enable the ldap service:


svcadm enable ldap/client

check the ldap service now:

xxx@yyy> /usr/lib/ldap/ldap_cachemgr -g

cachemgr configuration:
server debug level          0
server log file "/var/ldap/cachemgr.log"
number of calls to ldapcachemgr         63

cachemgr cache data statistics:
Configuration refresh information: 
  Previous refresh time: 2018/07/06 19:46:58
  Next refresh time:     2018/07/12 19:47:11
Server information: 
  Previous refresh time: 2018/07/12 07:47:11
  Next refresh time:     2018/07/12 10:57:02
  server: xx.yy.zz.66, xyz, status: UP
Cache data information: 
  Maximum cache entries:          256
  Number of cache entries:          0

Clone Pluggable Database using zfs clones

Fast cloning using zfs snapshots and clones is very simple for pluggable databases.

In this example a pluggable database PDB1 is cloned to a pluggable database PDB4. All database files are located in /u01/PDB1 which is a zfs filesystem.

First you need to create an xml description of the pluggable database


SQL> alter pluggable database pdb1 close;
SQL> alter pluggable database pdb1 open read only;
SQL> alter session set container=PDB1;
SQL> exec dbms_pdb.describe(pdb_descr_file=>'/u00/pdb1.xml');

Then you have to create the snapshot and clone filesystems:


oracle@devx02e:CDB1:/u00# /usr/sbin/zfs snapshot devx02e_data/u01/PDB1@PDB4
oracle@devx02e:CDB1:/u00# /usr/sbin/zfs clone devx02e_data/u01/PDB1@PDB4 devx02e_data/u01/PDB4

Then create the database using the following commands


SQL> create pluggable database pdb4 AS CLONE using '/u00/pdb1.xml' source_file_name_convert=('/u01/PDB1','/u01/PDB4') nocopy tempfile reuse;

Then you just need to open the pluggable databases:


SQL> alter pluggable database pdbspe1 open force;
SQL> alter pluggable database pdbspe4 open;

ZPOOL hangs during rollback of a zfs snapshot

Starting with Kernel Patch 150401-09 of Oracle we experienced hangs of the whole zpool when we did a rollback of a snapshot.
Up to now (2015/12/05) there is no fix available for this problem. Last tests with Kernel patch 150401-28 where not successful.
The hangs occur if we had to rollback a snapshot of cloned filesystem.
Here the setup of our filesystems:


testsystem_data                                              11.5T  2.22T    31K  legacy
testsystem_data/u01                              9.65T  2.22T    46K  /zones/testsystem/root/u01
testsystem_data/u01/DB1                      8.77T  2.22T  2.19T  /zones/testsystem/root/u01/DB1
testsystem_data/u01/DB1@DB5              2.18T      -  2.18T  -
testsystem_data/u01/DB1@DB8              2.19T      -  2.19T  -
testsystem_data/u01/DB1@DB4              1.72G      -  2.19T  -
testsystem_data/u01/DB1@DB7               223M      -  2.19T  -
testsystem_data/u01/DB1@DB6               216M      -  2.19T  -
testsystem_data/u01/DB1@DB2               242M      -  2.19T  -
testsystem_data/u01/DB1@DB3               268M      -  2.19T  -
testsystem_data/u01/DB1@DB9              1.72G      -  2.19T  -
testsystem_data/u01/DB2                      95.3G  2.22T  2.26T  /zones/testsystem/root/u01/DB2
testsystem_data/u01/DB2@db2_after_clone  8.81G      -  2.19T  -
testsystem_data/u01/DB3                      95.5G  2.22T  2.26T  /zones/testsystem/root/u01/DB3
testsystem_data/u01/DB3@db3_after_clone  8.87G      -  2.19T  -
testsystem_data/u01/DB4                       209G  2.22T  2.28T  /zones/testsystem/root/u01/DB4
testsystem_data/u01/DB5                      30.8G  2.22T  2.18T  /zones/testsystem/root/u01/DB5
testsystem_data/u01/DB5@db5_after_clone  7.53G      -  2.18T  -
testsystem_data/u01/DB6                      91.9G  2.22T  2.26T  /zones/testsystem/root/u01/DB6
testsystem_data/u01/DB6@db6_after_clone  8.75G      -  2.19T  -
testsystem_data/u01/DB7                       128G  2.22T  2.26T  /zones/testsystem/root/u01/DB7
testsystem_data/u01/DB7@db7_after_clone  9.14G      -  2.19T  -
testsystem_data/u01/DB8                       163G  2.22T  2.26T  /zones/testsystem/root/u01/DB8
testsystem_data/u01/DB8@db8_after_clone  9.27G      -  2.19T  -
testsystem_data/u01/DB9                      92.0G  2.22T  2.26T  /zones/testsystem/root/u01/DB9
testsystem_data/u01/DB9@db9_after_clone  8.78G      -  2.19T  -

If we had to rollback a snapshot testsystem_data/u01/DB7@db7_after_clone we experienced long hang times. Sometimes the whole pool was blocked for several minutes.
The filesystem testsystem_data/u01/DB7 is a clone of the snapshot testsystem_data/u01/DB1@DB7.

After one year of testing all possible IDR Patches and Kernel Patches we found a simple workaround:

First delete all files in the Filesystem which you want to rollback. E.g. if you want to rollback testsystem_data/u01/DB7@db7_after_clone then first delete all files in /zones/testsystem/root/u01/DB7 and then run the rollback:


rm -r /zones/testsystem/root/u01/DB7
zfs rollback testsystem_data/u01/DB7@db7_after_clone

The "rm -r" command will take a while, depending on the size of the Filesystem (for 2TB about 40 Minutes), but then the "zfs rollback" will only take a few seconds, and the zpool will never hang during the whole procedure.

Solaris rescan SCSI device on VMware

If you want to add a SCSI device on a VMware virtual maschine which is running Solaris you normally just have to use the following command to see the new device

devfsadm

If you do not see the disk from Solaris then you just have to use the following commands:

root@xxxxx # cfgadm -al
Ap_Id                          Type         Receptacle   Occupant    
Condition
c1                             scsi-bus     connected    configured   unknown
c1::dsk/c1t0d0                 disk         connected    configured   unknown
c1::dsk/c1t1d0                 disk         connected    configured   unknown
c1::dsk/c1t2d0                 disk         connected    configured   unknown
c1::dsk/c1t3d0                 disk         connected    configured   unknown
pcie160                        etherne/hp   connected    configured   ok
..
..
pcie263                        unknown      empty        unconfigured unknown
root@xxxxx # cfgadm -x reset_all c1
root@xxxxx # devfsadm
root@xxxxx # cfgadm -al
Ap_Id                          Type         Receptacle   Occupant    
Condition
c1                             scsi-bus     connected    configured   unknown
c1::dsk/c1t0d0                 disk         connected    configured   unknown
c1::dsk/c1t1d0                 disk         connected    configured   unknown
c1::dsk/c1t2d0                 disk         connected    configured   unknown
c1::dsk/c1t3d0                 disk         connected    configured   unknown
c1::dsk/c1t4d0                 disk         connected    configured   unknown
pcie160                        etherne/hp   connected    configured   ok
...

Solaris rescan SAN devices

Rescan for new SAN devices can be done using the command

cfgadm -al

If a completely new storage system (e.g. Hitache Storage Systems) is added to the SAN, the storage may not be accessible even after using the command above. A relogin of each host bus adapter of the server in to the SAN is needed. Either you reboot the system or you use

luxadm -e forcelip /dev/cfg/cX; sleep 10 ; cfgadm -al

for each SAN adapter listed in the cfgadm -al output. Wait a few seconds between after each host bus adapter.

Or just do a relogin on each HBA port in use by the following commands


luxadm -e port |while read port rest ; do 
luxadm -e forcelip $port 
sleep 30 
cfgadm -al 
sleep 30
done
devfsadm

Backup to the disaster site using ZFS Replication

ZFS replication can be used to create a backup to the disaster site using a low bandwidth link. The replication is based on ZFS snapshots and only the amount of changed blocks between two snapshots on the filesystem need to be transferred to the disaster site after an initial transfer of all the data.
It can be used to replicate nearly all application data in a consistent manner as creating a snapshot is quick atomic operation. Therefore you can either shutdown the application or just put the application in a backup mode for a few seconds. If the data is stored in only one zfs filesystem the data should even be consistent without stopping or putting the application in a special mode, if the application is able to recover automatically after system crash.
A simple solution is the tool ZFS Replication on this site.

From a CSV-Addresslist to a Fritzbox Phonebook (CSV2Fritzbox)

If you want to convert a CSV-addressbook into a Phonebook for importing into your fritzbox you can use the following script

An example how to use it:


cat adressbook.csv |csv2fritzbox.bash -n 3 -h 9 -o 8 -m 12 -t -d , > fritzboxphonebook

The file fritzboxphonebook can then be imported using the web admin interface of the fritzbox.

The Usage of the script is


Usage: csv2fritzbox.bash -n namecol -h homenumbercol -m mobilenumbercol -o officenumbercol -t -d delimiter -l localcountrypredial -L localareapredial
namecol: The number if the column where the name of the contact is stored
homenumbercol: The number if the column where the home phone number of the contact is stored
mobilenumbercol: The number if the column where the mobile phone number of the contact is stored
officenumbercol: The number if the column where the office phone number of the contact is stored
delimiter: the delimiter character used to separate columns
localcountrypredial: The local country predial. in Switzerland for example 0041 which is default
localareapredial: The predial code used to substitute the local contry predial. in Switzerland for example 0 which is default
-t: There is a title line at the top

Changing Coordinator Disks online in Veritas Cluster Server (VCS) without vxfenswap

Starting with Veritas Cluster Server 5.0 MP3 there is an official tool "vxfenswap" to change the coordinator disks online. Before there was no such tool and no official statement how to change to coordinator disks while applications could stay online, although there is a simple solution which works normally without any problems.

The steps are:

1) Check the cluster state (LLT, GAB)


root@node1 # lltstat -n
LLT node information:
    Node                 State    Links
     0 node1              OPEN        3
     1 node2              OPEN        3
     2 node3              OPEN        3
root@node1 # gabconfig -a
GAB Port Memberships
===============================================================
Port a gen   f3b50f membership 012                       
Port b gen   f3b51a membership 012
Port h gen   f3b51a membership 012                       ^

2) Freeze all service groups and systems persistent.


root@node1 # haconf -makerw
root@node1 # hagrp -list |awk '[{print $1}' | sort -u | while read g ; do hagrp -freeze $g -persistent ; done
VCS WARNING V-16-1-50894 Command (hagrp -freeze -persistent ClusterService ) failed. The Group ClusterService cannot be frozen

root@node1 # hasys -list | while read s ; do hasys -freeze -persistent $s ; done
root@node1 # haconf -dump -makero

3) Stop the cluster monitoring


root@node1 # hastop -all -force

4) Stop the Fencing driver on all cluster nodes


root@nodeXXX # /etc/init.d/vxfen stop
Stopping VxFEN:

5) Stop the GAB driver on all cluster nodes


root@nodeXXX # /etc/init.d/gab stop
Stopping GAB:

6) Stop the LLT driver on all cluster nodes


root@nodeXXX # /etc/init.d/llt stop
Stopping LLT:

7) import the coordinator diskgroup on one node


root@node1 # vxdg -ftC import `cat /etc/vxfendg`

8) Set the coordinator flag off


root@node1 # vxdg -g `cat /etc/vxfendg` set coordinator=off

9) Remove unwanted coordinator disks


root@node1 # vxdg -g `cat /etc/vxfendg` rmdisk

where unwantetdiskname is the diskname out of the output of the command "vxprint -g `cat /etc/vxfendg`"
10) Add new coordinator disks


root@node1 # vxdctl enable
root@node1 # vxdisksetup -i 
root@node1 # vxdg -g `cat /etc/vxfendg` adddisk =

where is to "DEVICE" out of the output of the command "vxdisk list" and is a name you choose to name the disk in the diskgroup.
11) Rescan the partitions of the new coordinator disk on all systems
As the partition table is changed when a new disk is initialized by Volume Manager and the other nodes do not know about it, we have to Rescan the partition table on the ohter cluster nodes:

First get the diskid for the new coordinator disk on node1:


root@node1 # vxdisk list  |grep '^disk:'
disk:      name= id=1327668260.266.node1

Then create the script rescan_partitions.sh on all other nodes with the following content:


#!/bin/bash

vxdctl enable
vxdisk -o alldgs list|grep `cat /etc/vxfendg`|while read disk rest; do
  if vxdisk list $disk|grep $1 >/dev/null ; then                 
    if [ "`uname`" = "Linux" ] ; then
      vxdisk list $disk | grep state=enabled |while read dev re ; do
        grep $dev /proc/partitions
        blockdev --rereadpt /dev/$dev
      done
     fi
     vxdisk rm $disk
     vxdctl enable
  fi
done

And run it with the diskid as paramter on the other nodes


root@nodexxx # ./rescan_partitions.sh 1327668260.266.node1

12) Set the coordinator flag on


root@node1 # vxdg -g `cat /etc/vxfendg` set coordinator=on

13) deport the coordinator diskgroup


root@node1 # vxdg -g `cat /etc/vxfendg` deport

14) Start LLT on all nodes:


root@nodex # /etc/init.d/llt start
Starting LLT: 
LLT: loading module...
WARNING:  No modules found for 2.6.9-55.ELsmp, using compatible modules for 2.6.9-34.ELsmp.
LLT: configuring module...

15) Start GAB on all nodes:


root@nodex # /etc/init.d/gab start
Starting GAB: 
WARNING:  No modules found for 2.6.9-55.ELsmp, using compatible modules for 2.6.9-34.ELsmp.

16) Start Fencing Driver on all nodes


root@nodex # /etc/init.d/vxfen start
Starting VxFEN: 
WARNING:  No modules found for 2.6.9-55.ELsmp, using compatible modules for 2.6.9-34.ELsmp.
Starting vxfen.. Done

17) Start the cluster monitoring on all nodes


root@nodex # hastart

18) Unfreeze all service groups and systems persistent.
Wait for the cluster startup to complete. Check it with the command below. There shoud be no output:


root@node1 # hastatus -summ|grep '^D'
D  BWP          Proxy                LAN-PBWP           node1                
D  MIP          Proxy                LAN-PMIP           node2

Here some resources where still not probed. Just wait another minute and recheck...
As soon as all resources are probed you can safely unfreeze the servicegroups and systems:


root@node1 # haconf -makerw
root@node1 # hagrp -list |awk '[{print $1}' | sort -u | while read g ; do hagrp -unfreeze $g -persistent ; done
VCS WARNING V-16-1-40202 Group is not persistently frozen
root@node1 # hasys -list | while read s ; do hasys -unfreeze -persistent $s ; done
root@node1 # haconf -dump -makero

VMware and Virtualbox timer causes on Solaris 10 update 8 and later nanosleep to hang for ever

The system call nanosleep uses the system call cv_timedwait_sig to wait. Starting with Solaris 10 update 8 the system call cv_timedwait_sig uses the system call cv_timedwait_sig_hires to wait which then uses gethrtime() to schedule the wake up time. As this high resolution timer can jump on Solaris 10 running on top of a VMware ESX 3.5, VMware vSphere 4.x, VirtualBox virtual maschine with more than 1 CPU assigned, it can happen if the sleep exactly starts when such a jump occurs, that the end time is so far in the future, that it seems to system call is hanging for ever. As soon as one uses truss, pstack, jstack, ... to analyze the live process, the nanosleep call will wake up on a signal and continue.
To see if the high resolution timer is making jumps you can use the following small program gethrtime_test.c to test:


#include 
#include 
#include 

int main(int argc, char** argv)
{
     hrtime_t start, end;
     long iters = 1000000000;
     hrtime_t delta;
     delta=10000000;
 
     if (argc > 1) iters = atol(argv[1]);
     if (argc > 2) delta = atol(argv[2]);
     printf("%ld iterations\n", iters);
 
     start = gethrtime();
 
     long i;
     for (i = 0; i < iters; i++)
     {
         end = gethrtime();
 
         if ( start > end || start+delta < end)
             printf("%ld:\n  start %lld\n  end   %lld\n  diff  %lld\n",
                 i, start, end, (end-start));
 
         start=end;
     }
     exit(0);
}

Create the file called gethrtime_test.c and compile it


root@hostname# gcc -o gethrtime_test gethrtime_test.c

Then let it run.


root@hostname# ./gethrtime_test
1000000000 iterations

You should not see any message like


5750624:
  start 415551665195
  end   415150888326
  diff  -400776869
6387810:
  start 416494513021
  end   416509397658
  diff  14884637

Especially negative jumps should never happen.

If you see negative jumps, you can set the following paramters in a VMware virtual machines vmx file and reboot to avoid this:

VMware ESX 3.5


monitor_control.disable_tsc_offsetting=TRUE
monitor_control.disable_rdtscopt_bt=TRUE

VMware vSphere 4.x


timeTracker.forceMonotonicTTAT=TRUE

On VirtualBox I do not know any solution yet.