Engineering and technology notes

Blob – Binary large object

A Binary Large OBject (BLOB) is a collection of binary data stored as a single entity in a database management system. Blobs are typically images, audio or other multimedia objects, though sometimes binary executable code is stored as a blob. Database support for blobs is not universal.

Blobs were originally just big amorphous chunks of data invented by Jim Starkey at DEC, who describes them as “the thing that ate Cincinnati, Cleveland, or whatever” from “the 1958 Steve McQueen movie”, referring to The Blob. Later, Terry McKiever, a marketing person for Apollo, felt that it needed to be an acronym and invented the backronym Basic Large Object. Then Informix invented an alternative backronym, Binary Large Object.

The data type and definition was introduced to describe data not originally defined in traditional computer database systems, particularly because it was too large to store practically at the time the field of database systems was first being defined in the 1970s and 1980s. The data type became practical when disk space became cheap. This definition gained popularity with IBM‘s DB2.

The term is used in NoSQL databases, especially in Key-value store databases such as Redis.

The name “blob” is further borrowed by the deep learning software Caffe to represent multi-dimensional arrays.

In the world of free and open-source software, the term is also borrowed to refer to proprietary device drivers, which are distributed without their source code, exclusively through binary code; in such use, the term binary blob is common, even though the first letter in the blob abbreviation already stands for binary

https://en.m.wikipedia.org/wiki/Binary_large_object

Virtualbox – Teleporting Virtual Machines

Oracle VM VirtualBox supports teleporting. Teleporting is moving a virtual machine over a network from one Oracle VM VirtualBox host to another, while the virtual machine is running. This works regardless of the host operating system that is running on the hosts. You can teleport virtual machines between Oracle Solaris and Mac OS X hosts, for example.

Teleporting requires that a machine be currently running on one host, which is called the source. The host to which the virtual machine will be teleported is called the target. The machine on the target is then configured to wait for the source to contact the target. The machine’s running state will then be transferred from the source to the target with minimal downtime.

Teleporting happens over any TCP/IP network. The source and the target only need to agree on a TCP/IP port which is specified in the teleporting settings.

At this time, there are a few prerequisites for this to work, as follows:

  • On the target host, you must configure a virtual machine in Oracle VM VirtualBox with exactly the same hardware settings as the machine on the source that you want to teleport. This does not apply to settings which are merely descriptive, such as the VM name, but obviously for teleporting to work, the target machine must have the same amount of memory and other hardware settings. Otherwise teleporting will fail with an error message.
  • The two virtual machines on the source and the target must share the same storage, hard disks as well as floppy disks and CD/DVD images. This means that they either use the same iSCSI targets or that the storage resides somewhere on the network and both hosts have access to it using NFS or SMB/CIFS.

    This also means that neither the source nor the target machine can have any snapshots.

To configure teleporting, perform the following steps:

  1. On the target host, configure the virtual machine to wait for a teleport request to arrive when it is started, instead of actually attempting to start the machine. This is done with the following VBoxManage command:
    VBoxManage modifyvm targetvmname --teleporter on --teleporterport port

    targetvmname is the name of the virtual machine on the target host and port is a TCP/IP port number to be used on both the source and the target hosts. For example, use 6000. See Section 8.8, “VBoxManage modifyvm”.

  2. Start the VM on the target host. Instead of running, the VM shows a progress dialog, indicating that it is waiting for a teleport request to arrive.
  3. Start the VM on the source host as usual. When it is running and you want it to be teleported, issue the following command on the source host:
    VBoxManage controlvm sourcevmname teleport --host targethost --port port

    where sourcevmname is the name of the virtual machine on the source host, which is the machine that is currently running. targethost is the host or IP name of the target host on which the machine is waiting for the teleport request, and port must be the same number as specified in the command on the target host. See Section 8.13, “VBoxManage controlvm”.

For testing, you can also teleport machines on the same host. In that case, use localhost as the hostname on both the source and the target host.

http://www.virtualbox.org/manual/ch07.html#teleporting

How can we get the Password attributes such as pwdMaxAge, pwdMaxFailure etc for LDAP server in Apigee ?

ou can use the below command to find out the values of Ldap attributes – pwdMaxAge, pwdMaxFailure

ldapsearch -H ldap://localhost:10389 -x -D "cn=manager,dc=apigee,dc=com" -W -b "cn=default,ou=pwpolicies,dc=apigee,dc=com"

Here’s the sample output for the above command:

# extended LDIF
#
# LDAPv3
# base <cn=default,ou=pwpolicies,dc=apigee,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# default, pwpolicies, apigee.com
dn: cn=default,ou=pwpolicies,dc=apigee,dc=com
objectClass: person
objectClass: pwdPolicy
objectClass: top
cn: default
pwdAttribute: userPassword
sn: dummy value
pwdExpireWarning: 604800
pwdInHistory: 3
pwdLockoutDuration: 300
pwdFailureCountInterval: 300
pwdMaxFailure: 3
pwdMinLength: 8
pwdMaxAge: 0
pwdLockout: FALSE
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

Source: How can we get the Password attributes such as pwdMaxAge, pwdMaxFailure etc for LDAP server in Apigee ?

Account expiration mail warning [LDAP Tool Box (LTB)]

Account expiration mail warning

Presentation

This script will browse the LDAP directory a look for entries that uses password policy. If the user’s password will expire soon, a mail is sent. It was only tested with OpenLDAP (ppolicy overlay).

This shell script must be run as a cronjob. You can run it daily.

It requires :

  • gawk (GNU awk)
  • ldapsearch
  • mailx
  • date

It was tested for GNU/Linux and SunOS 5.8.

Usage

There is no command line parameter:

sh checkLdapPwdExpiration.sh

Logs are sent through STDOUT and STDERR:

sh checkLdapPwdExpiration.sh 1>result.log 2>audit.log

Sample log files:

  • result.log
--- Statistics ---
Users checked: 5
Account expired: 1
Account in warning: 1
  • audit.log
No password policy for coudot
Password expired for sbahloul
No password change date for tchemineau
No password change date for rouazana
Mail sent to user farmand (farmand@example.com)

Configuration

Edit the script to adapt configuration:

  • MY_LDAP_HOSTURI: LDAP URI
  • MY_LDAP_ROOTDN (optional): DN to use to bind. No DN means anonymous
  • MY_LDAP_ROOTPW: Password
  • MY_LDAP_DEFAULTPWDPOLICYDN: Default password policy DN. Do not set if no default policy is used. In this case, the script will ony affect users with password policy in their entry (pwdPolicySubentry)
  • MY_LDAP_SEARCHBASE: Users search base
  • MY_LDAP_SEARCHFILTER: Users search filter
  • MY_LDAP_SEARCHBIN: Path to ldapsearch binary
  • MY_MAIL_DELAY: Time before expiration where a mail is sent. No mail sent after expiration. If no value, the script will take the pwdExpireWarning of the password policy
  • MY_LDAP_NAME_ATTR: attribute containing user’s name
  • MY_LDAP_LOGIN_ATTR: attribute containing user’s login
  • MY_LDAP_MAIL_ATTR:attribute containing user’s name
  • MY_MAIL_BODY: message body
  • MY_MAIL_SUBJECT: message subject
  • MY_MAIL_BIN: mail binary
  • MY_LOG_HEADER: log header
  • MY_GAWK_BIN: path to gawk binary

Mail content: you can edit MY_MAIL_BODY and use the following variables:

  • name
  • login
  • expireTimeTZ
  • expireDays
  • pwdMinLength
  • pwdInHistory

Date localization: you can change the lang by modifying this line:

export LC_ALL=en_US.UTF-8

 

Source: Account expiration mail warning [LDAP Tool Box (LTB)]

OpenLDAP Software 2.4 Administrator’s Guide: Overlays

12.10.2. Password Policy Configuration

Instantiate the module in the database where it will be used, after adding the new ppolicy schema and loading the ppolicy module. The following example shows the ppolicy module being added to the database that handles the naming context “dc=example,dc=com”. In this example we are also specifying the DN of a policy object to use if none other is specified in a user’s object.

       database mdb
       suffix "dc=example,dc=com"
       [...additional database configuration directives go here...]

       overlay ppolicy
       ppolicy_default "cn=default,ou=policies,dc=example,dc=com"

Now we need a container for the policy objects. In our example the password policy objects are going to be placed in a section of the tree called “ou=policies,dc=example,dc=com”:

       dn: ou=policies,dc=example,dc=com
       objectClass: organizationalUnit
       objectClass: top
       ou: policies

The default policy object that we are creating defines the following policies:

  • The user is allowed to change his own password. Note that the directory ACLs for this attribute can also affect this ability (pwdAllowUserChange: TRUE).
  • The name of the password attribute is “userPassword” (pwdAttribute: userPassword). Note that this is the only value that is accepted by OpenLDAP for this attribute.
  • The server will check the syntax of the password. If the server is unable to check the syntax (i.e., it was hashed or otherwise encoded by the client) it will return an error refusing the password (pwdCheckQuality: 2).
  • When a client includes the Password Policy Request control with a bind request, the server will respond with a password expiration warning if it is going to expire in ten minutes or less (pwdExpireWarning: 600). The warnings themselves are returned in a Password Policy Response control.
  • When the password for a DN has expired, the server will allow five additional “grace” logins (pwdGraceAuthNLimit: 5).
  • The server will maintain a history of the last five passwords that were used for a DN (pwdInHistory: 5).
  • The server will lock the account after the maximum number of failed bind attempts has been exceeded (pwdLockout: TRUE).
  • When the server has locked an account, the server will keep it locked until an administrator unlocks it (pwdLockoutDuration: 0)
  • The server will reset its failed bind count after a period of 30 seconds.
  • Passwords will not expire (pwdMaxAge: 0).
  • Passwords can be changed as often as desired (pwdMinAge: 0).
  • Passwords must be at least 5 characters in length (pwdMinLength: 5).
  • The password does not need to be changed at the first bind or when the administrator has reset the password (pwdMustChange: FALSE)
  • The current password does not need to be included with password change requests (pwdSafeModify: FALSE)
  • The server will only allow five failed binds in a row for a particular DN (pwdMaxFailure: 5).

The actual policy would be:

       dn: cn=default,ou=policies,dc=example,dc=com
       cn: default
       objectClass: pwdPolicy
       objectClass: person
       objectClass: top
       pwdAllowUserChange: TRUE
       pwdAttribute: userPassword
       pwdCheckQuality: 2
       pwdExpireWarning: 600
       pwdFailureCountInterval: 30
       pwdGraceAuthNLimit: 5
       pwdInHistory: 5
       pwdLockout: TRUE
       pwdLockoutDuration: 0
       pwdMaxAge: 0
       pwdMaxFailure: 5
       pwdMinAge: 0
       pwdMinLength: 5
       pwdMustChange: FALSE
       pwdSafeModify: FALSE
       sn: dummy value

You can create additional policy objects as needed.

There are two ways password policy can be applied to individual objects:

1. The pwdPolicySubentry in a user’s object – If a user’s object has a pwdPolicySubEntry attribute specifying the DN of a policy object, then the policy defined by that object is applied.

2. Default password policy – If there is no specific pwdPolicySubentry set for an object, and the password policy module was configured with the DN of a default policy object and if that object exists, then the policy defined in that object is applied.

Please see slapo-ppolicy(5) for complete explanations of features and discussion of “Password Management Issues” at http://www.symas.com/blog/?page_id=66

12.10.3. Further Information

slapo-ppolicy(5)

Source: OpenLDAP Software 2.4 Administrator’s Guide: Overlays