Introduction to LINCKS
LINCKS consists of eleven different programs which can divided into three different classes: the database server (monitor, netserv, and dbs); general utility programs (dbpasswd, dbdump, dbroot, t2lincks and cutoff which are normal clients), and the main application program (xlincks).
Both the application program and the utility programs take the last argument to be a path to a directory with the LINCKS database files. If you are only running one database server, or if you get tired of typing the path to the database directory, simply set the environment variable LINCKSDBDIR to point to this directory and omit the path. A typical database directory might look like:
-r--r--r-- 1 lincks iislab 33554 Aug 23 01:27 .fonttrans -rw-r--r-- 1 lincks iislab 18 Sep 18 19:30 .indexfile.lock -rw-r--r-- 1 lincks iislab 158 Aug 23 01:28 .lincksrc -rw-r--r-- 1 lincks iislab 592883 Aug 23 02:07 1.dat -rw-r--r-- 1 lincks iislab 82368 Aug 23 02:07 1.mol -rw-r--r-- 1 lincks iislab 6 Aug 23 01:56 data.names -rw------- 1 lincks iislab 494 Aug 23 01:27 groups -rw-r--r-- 1 lincks iislab 61944 Aug 23 02:07 index -rw-r--r-- 1 lincks iislab 6 Aug 23 01:56 molecule.names -rw-r--r-- 1 lincks iislab 305 Jun 28 17:08 passwd
The .lincksrc is the configuration file which tells the LINCKS software where to find the database directory, log file directory, executable, TCP/IP port, etc. The passwd file contains a user name, a user id, and an encrypted password for each user. Access protection is defined by the groups file and by an optional wrgroups file. The dbs processes, stores, and retrieves objects and their contents in the 1.dat and 1.mol files. The monitor process uses the index file for storing the object identifications for each object. The *.names files contain the names of all the *.dat and *.mol files, which hold the actual data.
Whenever a LINCKS program accesses the index file, it must create a .indexfile.lock file, which contains the program name, its process id, and current host name. For more information, please see the LINCKS System Administration Manual.
The monitor process serializes object creation, imposes access control, and provides for parallel editing notifications. The monitor allows you to define which objects a particular user has read and write access via the group file and the optional wrgroups file.
The netserv process handles connections from all clients. After validating the user name and password against the passwd file (which is changed using dbpasswd), netserv forks and creates the dbs process for each connected client.
Each dbs process interacts with one client. It retrieves and stores objects in the *.dat and *.mol files using the monitor to ensure unique object identifiers and to synchronize access to the common database files. The dbs process dies when the client process closes the connection.
The lincks program is used to start a LINCKS database server. If the database server is interrupted by a system crash, an .indexfile.lock file exists, but no LINCKS software is running. You will receive a warning message. Just remove the lock file (first check for a running process, please!) and re-execute the lincks command.
The dbstat utility is used to check for a running database server (monitor and netserv). dbstat connects to the netserv and monitor processes and returns some status information, as shown in Figure 1, dbstat
You use dbpasswd to add or to change a user's password. It is installed suid to enable every user to modify his or her own password, which is encrypted by default. When you add a new user, you must edit the passwd, groups and, if you use it, wrgroups files by hand. When you are finished editing, restart the database server to enable the monitor to re-read the protection files.
To export or dump a LINCKS database, use the dbdump program, which exports a whole LINCKS database in text format. If you have stored any binary object in the database (images, sounds, object code, etc) dbdump will create a file for each of the binary objects. You use t2lincks to import an exported database. Of course, t2lincks can also be used to import an object or any information into a database—registers or articles, for example—as long as it is in the proper format (see the t2lincks manual pages).
The two last utilities are not used very often—dbroot creates a completely empty database (it destroys any existing objects in the database if any already exist). You only run dbroot when setting up a new database. To garbage collect a LINCKS database run cutoff, which removes all objects which are not referenced by any other objects.
Webinar: 8 Signs You’re Beyond Cron
On Demand NOW
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.View Now!
- When Official Debian Support Ends, Who Will Save You?
- Ubuntu Ditches Upstart
- Video On Demand: 8 Signs You're Beyond Cron
- May 2015 Issue of Linux Journal: Cool Projects
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Picking Out the Nouns
- Return of the Mac
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites