← Previous | ↑ Home | → Next |
itadmin
Using itadmin you can keep your IT information in a database. The following files can be generated from the database contents:
Building all these files from the same database ensures consistency.
You can run
pdflatex netdocu && pdflatex netdocu && pdflatex netdocu
pdflatex licenses && pdflatex licenses && pdflatex licenses
to produce netdocu.pdf and licenses.pdf
Use "pdflatex -interaction=batchmode" instead of "pdflatex" to run the PDF creation less noisy.
Option | Purpose |
---|---|
-c | Produce configuration files only. |
-l | Produce license report only. |
-h | Show help text. |
-v | Show version information. |
-L | Show license information. |
The program produces configuration files and license report if neither -c nor -l is specified.
0 on success, all other status codes indicate an error.
Database (required)
A database server is required to store the IT database.
At the momemt only MariaDB or MySQL databases can be used.
GUI program for database access (recommended)
Typically you don't like to edit the database using a command line tool. So you should install the MariaDB/MySQL ODBC connector and use programs from an office suite to access the database via GUI from your desktop.
LDAP server (optional)
The itadmin program produces both configuration files (hosts/ethers) and LDIF files for data import on an LDAP server. If you plan to use netgroups, you need an LDAP server.
DHCP server (optional)
If you want to provide dynamic IP address configuration, you need a DHCP server to do so. Itadmin writes a dhcpd.conf file for use with the ISC DHCP server.
LaTeX distribution (optional)
Don't be afraid, you don't need to learn LaTeX syntax to use itadmin.
Itadmin creates the files netdocu.tex and licenses.tex for you.
You just run
pdflatex netdocu
pdflatex licenses
three times to produce the network documentation netdocu.pdf and the license report licenses.pdf from them.
The program uses configuration files named "itadmin.conf". Run
itadmin --/log/stderr/level=debug
to see which files are attempted and processed in which order.
Each line in the configuration file is a key=value entry. The following keys can be used:
Key | Value type | Purpose |
---|---|---|
database host | Hostname | Host name or IP address of database server. |
database name | Identifier | Name of the IT database. |
database type | String | Database type. At this time only "mysql" is supported (used for both MariaDB and MySQL). |
database credentials file | Path name | Name of the file containing the database credentials (You can use your .my.cnf file, specify the full path name). |
create dhcpd.conf | Boolean | Create dhcpd.conf file. |
dhcpd.conf vlan | Identifier | Name of the virtual LAN (VLAN) in which the DHCP server is placed. If the VLAN is specified only IP networks contained in this VLAN are listed in dhcpd.conf. Otherwise all IP networks are written to dhcpd.conf. |
msft release lease on shutdown | String | Decide whether to attempt to keep the IP address or to release it on shutdown of Windows PCs. One from:
|
ldap base | String | The name of your LDAP base object, i.e. "dc=my-corporation,dc=com". If this entry is missing, no files "hosts.ldif", "ethers.ldif" or "netgroup.ldif" are produced. |
administrator name | Text | Name of the network administrator, written to the netdocu.tex and licenses.tex file. Use a full name, i.e. "John Doe". |
marker point | Boolean | Write marker points to dhcpd.conf output file. Default: On. |
marker vlan | Boolean | Write range markers into vlan definitions in dhcpd.conf output file. Default: On. |
marker subnet | Boolean | Write range markers into subnet definitions in dhcpd.conf output file. Default: On. |
marker group | Boolean | Write range markers into group definitions in dhcpd.conf output file. Default: On. |
marker pool | Boolean | Write range markers into pool definitions in dhcpd.conf output file. Default: On. |
marker host | Boolean | Write range markers into host definitions in dhcpd.conf output file. Default: On. |
organization | Text | The name of the organization, written to netdocu.tex and licenses.tex. Use a full name like "University of Somewhere, Anywhere". |
organizational unit | Text | Name of the organizational unit, written to netdocu.tex and licenses.tex. Use a full name like "Fun and jokes department". |
use koma-script | Boolean | Use LaTeX document classes "scrbook" and "scrartcl" instead of "book" and "article". Recommded when printing on A4 paper instead of Letter. |
SQL files to install the initial database are copied to /usr/share/dktools/itadmin or /usr/local/share/dktools/itadmin during installation.
Use the mysql command to install it:
mysql -u root -p < /.../dktools/itadmin/it-latin1.sql
You can use the it-latin1.sql file to create the initial database structure. German users can use it-de.sql instead.
The it-utf8.sql file is experimental and untested. Someone from regions where UTF-8 encoding is needed because the latin1 character set ist not sufficient should make tests with it and give me feedback.
The users table contains information about persons. There is no need to list all your organization's people, just list those in charge for computers and licensing.
Each record contains the following fields:
Field name | Contents |
---|---|
us_s | The login name of the user (or a short abbreviation of the name). Primary key. |
us_t | Job title or academic degree, optional. |
us_sn | Surname, optional. |
us_fn | Name (family name). |
us_em | E-mail address, optional. |
us_ko | Account number for costs controlling, optional. |
us_se | Job ID number, optional. |
The buildings table lists buildings where computers can be placed.
Field name | Contents |
---|---|
gb_s | Short name of the building (abbreviation). Primary key. |
gb_l | Name of the building, optional. |
gb_a1 | First address line of the building, optional. |
gb_a2 | Second address line, optional. |
gb_a3 | Third address line, optional. |
gb_a4 | Fourth address line, optional. |
gb_plz | ZIP code, optional. |
gb_ort | Name of town/city, optional. |
The ddspeed table lists possible speed settings for ethernet connections.
Field name | Contents |
---|---|
sp_s | Abbreviation for setting. Primary key. |
sp_l | Description, optional. |
The vlans table lists the virtual LANS (VLANS) built on top of the physical network.
Field name | Contents |
---|---|
vl_s | VLAN name. Primary key. |
vl_l | Full name or description, optional. |
The patches table lists the ethernet sockets in the rooms.
Field name | Contents |
---|---|
dd_n | Name of the ethernet socket. Primary key. Example: For an ethernet socket in House "D", connected to hub/switch/router "A" port number 64 one could use "D/A/0064" here. |
sp_s | Speed setting for the socket, optional. Must match en entry in the ddspeed table. |
vl_s | VLAN the ethernet socket is assigned to, optional. Must match an entry in the vlans table. |
dd_p | Hub port used by this ethernet socket, optional. |
gb_s | Building in which the ethernet socket is placed, optional. Must match an entry in the buildings table. |
dd_r | Room within the building where the ethernet socket is placed, optional. |
The networks table lists IP networks.
Field name | Contents |
---|---|
nw_ip | IP class base address. Primary key. |
nw_ma | Network mask. |
nw_gw | Router of this net (IP address). |
nw_bc | Broadcast address in this network, optional. The broadcast address is calculated automatically from base address and netmask if it is not specified. |
vl_s | VLAN in which the IP network is placed, optional. Must match an entry in the vlans table. |
Netgroups are a mechanism to assign permissions to computers. The same permissions can be applied to a group of computers.
If you specify computer permissions for — i.e. Samba, NFS and tcpd — directly in the configuration files you have to restart the services after making changes.
Using netgroups avoids these restarts, simply assign permissions to the netgroups in the configuration files. You can add/remove hosts to/from netgroups without having to restart daemons.
In NIS netgroups can be nested. If netgroup A is a member of netgroup B all member hosts of A are automatically members of netgroup B.
With itadmin you can use nested netgroups with LDAP too, the itadmin program resolves nested netgroups to plain host lists before writing the netgroups.ldap file.
In the IT database you can use a nested netgroup structure.
The itadmin program resolves dependencies of nested netgroups before creating the netgroup.ldif file. So in netgroup.ldif each netgroup only contains hosts.
This flattening is done for two reasons:
Performance
If a NIS/LDAP client needs to know whether or not a host is in a netgroup it asks the NIS/LDAP server whether or not the client is a direct member of the netgroup. If it isn't, the client asks for a list of all member subgroups of the netgroup. For all these subgroups the client needs to check again whether the host is in the subgroup … recursively. This might result in a larger number of requests and responses.
If the server has the flattened information the client can stop after requesting the the subgroups of the initial netgroup as this request returns an empty list.
Problems with some nss implemtations in the past
Previously I had problems with clients not doing the recursive check correctly.
The netgroups table lists the netgroups.
Field name | Contents |
---|---|
ng_s | Netgroup name. Primary key. |
ng_l | Description of the netgroup, i.e. purpose. Optional, but recommended. |
The ngdeps table configures the netgroup dependencies.
Field name | Contents |
---|---|
nd_pk | Primary key in this table. Unique numeric value not of further interest. |
nd_p | Parent group, required. Must match an entry in the netgroups table. |
nd_c | Child group, required. Must match an entry in the netgroups table. |
All member hosts of the nd_c netgroup are automatically members of the nd_p netgroup.
The computers table lists the computers.
Field name | Contents |
---|---|
co_s | Short host name of the computer. This field is the primary key in the table. |
us_s | The person responsible for the computer. This is not the IT people installing the software and probably not the person using the computer. Enter the person "in charge" for the computer here. This person has budget permission to buy needed licenses for software and decides what purpose the computer is used for. Do not enter persons just using the computer here. Do not enter persons just doing technical support. If the field is used there must be an appropriate entry in the users table. |
co_co | Comment about the purpose of the computer, optional but recommended. |
co_mc | MAC address (ethernet address) of the computer, optional. |
co_ip | IP address, optional. |
co_dd | DNS domain the computer belongs to, optional. |
co_ff | Flag "full name first". If this flag is set, the FQDN is written to the hosts and hosts.ldif file first. Without this flag the normal (short) host name is used. |
co_hi | Host ID, optional. Host IDs are typically found on Unix systems. Floating licenses are often bound to a host ID. |
dd_n | Name of the ethernet socket the computer is connected to, optional. Must match an entry in the patches table. |
gb_s | Name of the building in which the computer is placed, optional. Must match an entry in the buildings table. |
co_r | Room number within the building, optional. |
co_in | Inventory ID of the computer, optional. |
co_sn | Serial number of the computer, if any. Optional. |
ng_s | Name of the primary netgroup assigned to the computer, optional. Must match an entry in the netgroups table. |
co_gu | Guest status and licensing, see below. |
co_ex | Expiration date for a host. If a host is granted access for a limited time only, enter the end date here. Note: The itadmin program does not force expiration, it just writes a notice that you should delete the entry from the table manually. |
dc_s | Name of the DHCP class for that computer, optional. Must match an entry in the dhcpclasses table. |
dg_s | Name of a DHCP group for that computer, optional. Must match an entry in the dhcpgroups table. |
The co_gu field is used for licensing responsibility.
co_gu | Purpose |
---|---|
0 | Physical and virtual machines our organizational unit is responsible for (in terms of licensing). |
1 | Private computers (BYOD: bring your own device). The owner is responsible for licensing. |
2 | Computers outside our departments responsibility, i.e. hosts in neighbour departments our hosts have to communicate to. The owner is responsible for licensing, not our department. |
3 | Dynamically assigned IP address and host names, assigned i.e. by DHCP servers, WiFi access points or VPN software. Licenses are assigned to the real host names. |
4 | Secondary (or further) network interfaces of a computer. Licenses are assigned to the real host names, connected to the primary network interface. |
5 | Network interfaces of non-computer devices without user-installable software (i.e. measurement devices, oscilloscopes, control units). As we can not install software on the device, the device is not subject to license management. |
6 | IP addresses and hostnames reserved for later use, but not used yet. |
7 | Retired devices no longer in use. |
A DHCP service allows client computers to obtain an IP address. When a DHCP client is booted it sends a broadcast request to obtain IP configuration data.
The DHCP server processes the request. Depending on the data sent by the client (i.e. the clients ethernet address, host name…) it chooses an appropriate IP address and sends a response containing IP address, net mask, gateway and optionally other information back to the client.
The IP address can be either an address from an address pool or a fixed address statically assigned to the client.
For addresses from a pool the client is allowed to use the address for a limited time (lease time). If the client doesn't renew the lease (request the IP address for yet another period) the server assumes the IP address is no longer used by the client.
In a network there might be different types of computers (i.e. in a university faculty there are staff members and students). You might decide to use different address pools for different types of computers, so you have to assign a DHCP class to computers. Use different DHCP class names for different types of computers obtaining IP addresses from different address pools.
DHCP options (additional information sent in the response, i.e. boot file and boot server) can be assigned to the server, a VLAN, an IP network, a DHCP address pool, a DHCP group or a host.
The dhcpclasses table lists the available DHCP classes:
Field name | Contents |
---|---|
dc_s | DHCP class name (short name). Primary key. |
nw_ip | Network the DHCP class belongs too, required. Must match an entry in the networks table. |
dc_d | Long name / description, optional. |
The dhcpgroups table lists DHCP groups (groups of hosts sharing the same DHCP attributes).
Field name | Contents |
---|---|
dg_s | Group name. Primary key. |
dg_l | Long name / description of the group, optional. |
The dhcppools table lists the available DHCP address pools.
Field name | Contents |
---|---|
dp_pk | Primary key, unique numeric value not of further interest. |
dp_st | Start IP address of the pool, required. |
dp_en | End IP address of the pool, required. |
nw_ip | Network the pool belongs to, optional. Must match an entry in the networks table. If no entry is specified, the network is found automatically. |
dp_al | Flag: Allow unknown clients to use the address pool. |
dp_dn | Flag: Deny unknown clients. |
dc_s | Name of the DHCP class which is allowed to use this address pool if dp_dn is set. |
To grant general access to a pool, even for unknown clients:
dp_al=1, dp_dn=0, dc_s=undefined.
To restrict access to a pool, allow only clients from a specified DHCP class:
dp_al=0, dp_dn=1, dc_s=class.
The dhcpoptions table can be used to assign DHCP options to the entire server, a VLAN an IP network, a DHCP address pool, a DHCP group, or a single host.
Field name | Contents |
---|---|
do_pk | Primary key, unique numeric value not of further interest. |
do_sc | option scope type, one from "server", "vlan", "network", "pool", "group", or "host". |
do_sn | The option scope name: empty (NULL) for the server, a VLAN name for a vlan, an IP start address for an IP network, a pool start address for an address pool, a name for a group or host. |
do_n | Option name. |
do_v | Option value, may be NULL for options not requiring a value. |
Several tables are involved in license management:
The swmanufacturers table lists software manufacturers:
Field name | Contents |
---|---|
sm_s | Short name (abbreviation). Primary key. |
sm_l | Full name of software manufacturer. |
The swproducts table lists products you can purchase from software manufactures: program licenses (full versions), upgrades, software insurances…:
Field name | Contents |
---|---|
sw_s | Short name / abbreviation. Primary key. |
sw_l | Full name. |
Enter the full name of the software product including version number.
If the product is an upgrade license requiring a previous product from the same product line, include the word UPGRADE here.
If the product is an "Upgrade Advantage" allowing an upgrade from previous versions and lower product lines, include "UPGRADE from …" here and list the products allowing the upgrade.
If the product is a software insurance, enter "SA from … until 2034-08-31" here while in the software insurance period. Change it to "SA from … up to version x.y" after the software insurance period.
Example:
"SA from Desktop 3.5 until 2034-08-31" while the software insurance is running, "SA from Desktop 3.5 up to Desktop 25.8" after 2034-08-31.
Note: For all updates and insurances the full name must explain which product version(s) can be used as upgrade base and which version is the upgrade destination.
The swresellers table is currently not used by itadmin:
Field name | Contents |
---|---|
sr_s | Short name / abbreviation. Primary key. |
sr_l | Full name. |
sr_a1 | Address line 1. |
sr_a2 | Address line 2. |
sr_a3 | Address line 3. |
sr_a4 | Address line 4. |
sr_plz | ZIP code (postal code). |
sr_ort | Town / city name. |
The licensestypes table lists the different license types:
Field name | Contents |
---|---|
lt_s | Short license type name, abbreviation. This field is the primary key of the table. |
lt_l | Full name, description. |
lt_i | Number of licenses for floating license servers. |
The licenses table lists the licenses purchased by the organizational unit or purchased by the organization and assigned to the organizational unit:
Field name | Contents |
---|---|
li_pk | Unique numeric value not of further interest. Primary key. |
li_on | ID number of the purchase process within the organization or organizational unit (german: Beschaffungsauftrag, Auftragsnummer) combined with the name of the person keeping the paperwork for the purchase process (delivery note, invoice, copy of order sheet…), required. |
sw_s | The software the license is for, required. Must match an entry in the swproducts table. |
us_s | User the license is assigned to, or NULL if the license was purchased bot not yet assigned to a specific user. Must match an entry in the users table. |
co_s | Computer where the software is installed/used, optional. Must match an entry in the computers table. |
lt_s | License type, required. Must match an entry in the licensetypes table. |
li_no | An optional note about the license and license usage. |
sr_s | The software reseller short name, optional. Must match an entry in the swresellers table. |
li_dd | Delivery date, optional. |
li_nd | Delivery note number, optional. |
li_di | Invoice date, optional. |
li_ni | Invoice number, optional. |
At this time only the MariaDB / MySQL database server is supported.
The program is not available on Windows platforms.
This program uses DK libraries version 3.
MySQL is available at http://www.mysql.com. The community edition server is available free of charge.
Depending on the office suite you use on your desktop you most likely need the Connector/ODBC. On Linux systems your package management should allow you to install server, client software, and connector.
I prefer the ODBC connector, it is significantly faster on my computer.
Make sure you have installed the "mysql-connector-odbc" and "unixODBC" packages.
The /etc/odbcinst.ini file should contain a section like:
# Driver from the mysql-connector-odbc package
# Setup from the unixODBC package
[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib/libmyodbc5.so
Setup = /usr/lib/libodbcmyS.so
Driver64 = /usr/lib64/libmyodbc5.so
Setup64 = /usr/lib64/libodbcmyS.so
FileUsage = 1
If the section doesn't exist - add it. The file names of the shared libraries may change, i.e. if there is a new version of MySQL.
In /etc/odbc.ini create a section:
[it]
Description = IT database
Driver = /usr/lib/libmyodbc5.so
Server = 127.0.0.1
Database = it
Port = 3306
Socket = /var/lib/mysql/mysql.sock
Option = 3
ReadOnly = No
ServerType = MySQL
charset = utf8
It depends on your system whether or not you need the final "charset" line and which setting to choose.
Check the LANG environment variable. If it ends on ".UTF-8" or ".utf8" the "utf8" setting is correct. If the LANG environment variable ends on ".latin1" you must set the charset to "latin1". In general the "charset" setting specifies the character set used by the application processing the data, not the character set used in the database tables.
Now you should be able to open the database in oobase as ODBC database.
Visit http://www.isc.org/.
Normally you do not run itadmin alone, you combine it with other steps in a shell script.
Change into a special directory.
cd /root/scripts/itadmin
Note: Do not use the /etc directory!
Clean up the directory
Remove the files "hosts", "ethers-by-ip", "ethers-by-mac", "hosts.ldif", "ethers.ldif", "netgroup.ldif", "dhcpd.conf", "netdocu.tex", "licenses.tex", "netdocu.pdf", and "licenses.pdf".
Run itadmin and check the result
Continue with the following steps only if itadmin succeeded and returned exit status 0.
itadmin
Copy hosts and ethers to the /etc directory.
cp hosts /etc/hosts
cp ethers-by-mac /etc/ethers
It depends on your system whether to copy ethers-by-mac or ethers-by-ip to /etc/ethers. On Linux use ethers-by-mac, on Solaris use ethers-by-ip. Check your systems documentation to choose the correct file.
If you are running a DHCP server: Bring the new dhcpd.conf file in place.
/etc/rc2.d/Sxxdhcp stop
sleep 2
cp dhcpd.conf /etc/dhcpd.conf
/etc/rc2.d/Sxxdhcp start
You need to customize the above commands.
If you run an LDAP service: Update LDAP data.
Create a list of LDAP objects to delete (hosts, ethers and netgroup objects).
itacldap.pl
You can run the itacldap.pl script if you have Perl available on your system. Save the script as /usr/local/bin/itacldap.pl, the script must be customized before it can be used. It creates a file "objects-to-delete".
Delete LDAP objects.
ldapdelete -f objects-to-delete
Further command line options are necessary to specify an LDAP bind DN, a password or password file, a host or URI.
Enter new LDAP objects.
Run either
ldapaddent -f hosts hosts
ldapaddent -f ethers ethers
ldapadd -f netgroup.ldif
or
ldapadd -f hosts.ldif
ldapadd -f ethers.ldif
ldapadd -f netgroup.ldif
Create network documentation and license report.
PDFLATEX="pdflatex -interaction=batchmode"
$PDFLATEX netdocu && $PDFLATEX netdocu && $PDFLATEX netdocu
$PDFLATEX licenses && $PDFLATEX licenses && $PDFLATEX licenses
Copy network documentation, license report, and probably other files from the server to your desktop PC.
You might want to copy all the files from the current directory from the server to your desktop PC.
The files are needed the most if there are problems with network and/or file server, so make sure to have them accessable when the server is unreachable.
When connecting to a database service, a user name and a password is needed. This user name/password combination is not written directly to the itadmin.conf file, a reference to a credentials file containing user name and password is used instead. Only the credentials file needs protection against illegal access — set permissions to 600 so nobody else can even read it. For the itadmin.conf file you can use relaxed permissions 644, other users can read it as it does not contain confidential data.
A database credentials file looks like:
[client]
user=...
password=...
Netgroups are an elegant method to administer host-based permissions.
Without using netgroups you have to enter each host manually into access lists of daemons (i.e. Samba, ssh, tcpd…) and restart the service to apply the changes.
When using netgroups you configure the services to grant a group of hosts access to the service. The group name is written into the service configuration files. When adding a new computer to or removing a computer from a netgroup no service restart is necessary as the service configuration file was not changed and the group membership is checked at runtime when a client attempts to use a service.
You need an LDAP service to use netgroups.
If you are still using NIS, use the hostsadm script from dktools 2.x.x to produce an input file for NIS service. And plan to migrate to LDAP as soon as possible.
Netgroups can be nested, one netgroup A can be a member of another netgroup B. This means all member hosts of A are automatically member hosts of B too.
I suggest a two-level netgroup scheme: On the lower level hosts are grouped by type, i.e. desktop PCs, student PCs, bring-your-own-device, guest laptops… On the higher level there are groups with access to resources, the lower level groups are members of the higher level groups.
When purchasing a new PC you only have to add it to the appropriate lower level group, that's it.
When using DHCP pools in itadmin there are two variants to configure a DHCP pool:
When using itadmin, membership in DHCP classes is based on the MAC address.
To allow a computer to obtain an IP address dynamically, leave the "co_ip" field in the computers table empty. Set the "dc_s" field to the name of DHCP class the computer belongs to. Set the "co_mc" field to the MAC address of the computer.
You can obtain the MAC address by running "ifconfig -a" (*x) or "ipconfig /ALL" (Windows).
I recommend to have at least two pools:
The purpose of these different pools is that every guest, laptop owner… must visit the network administrator to register the computer for DHCP use. Depending on your organizations policies the user has to sign a contract or is simply tought about usage policies…
← Previous | ↑ Home | → Next |