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.
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
- Using tshark to Watch and Inspect Network Traffic
- Optimization in GCC
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Firefox Security Exploit Targets Linux Users and Web Developers
- Where's That Pesky Hidden Word?
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization