ClueNet:New Infrastructure Overview
From ClueWiki
Cluenet has recently updated the entire back-end infrastructure, including the authentication systems, DNS servers, and MySQL servers. There are several key parts to the new system, including: changes to the authentication systems, making the authentication system fully redundant, adding redundancy to the core MySQL server, and custom modifications to several key areas of the LDAP/Kerberos authentication system. The final change is the addition of a standard API to interact with all the core Cluenet authentication and user management services. Each of these changes is detailed below.
Contents |
Core Servers
Cluenet now uses multiple core servers in a master/slave configuration. Currently we have 2 core servers, integral and solution. Integral plays the role of master, and replicates all data from multiple services to solution. If integral were to fail, solution can function as a hot-backup to resume services with as little downtime as possible. This allows much greater reliability for the vital services they run.
Changes to the authentication stack in general
Cluenet continues to use an LDAP and Kerberos authentication system, even after the rebuild of the back-end. The old system used LDAP and Kerberos separately; while this functioned, it had some inconsistencies. If a user were to change their password in the LDAP server, the Kerberos password would not change, resulting in possible confusion.
The new system combines the two seperate systems into a more symbiotic relationship. The slapd now uses the Kerberos system for pass-through authentication. In the old system, the LDAP entry for a user contained the password hash for that user in the userPassword attribute. The new system simply base64-encodes the user's Kerberos principal, and then uses that to authenticate the user. When a user authenticates via LDAP, nothing appears to have changed on the client side, the service simply does a normal authentication for the user. On the slapd, it performs nearly the same actions, but instead of checking the password hash, it finds that the user's userPassword contains the user's Kerberos principal, authenticates to the KDC, and then returns the same authentication results to the service that requested the authentication. So in reality, on the side of the service (be it a server's PAM stack for ssh, or a webpage like the gallery) nothing has changed, even though the back-end is very different. This allows any service that uses LDAP to function without modification.
Changes to the LDAP system specifically
There have also been several modifications to the LDAP server and databases specifically. The slapd now uses a differnt configuration method, several new attributes have been added, and the ability to allow users to control the access levels of the data in the LDAP database that they own.
New configuration type
The first major change to the LDAP system is the new configuration method. The old system used flat files to store the configuration data, and certain options could not be changed without a restart of the slapd. The new configuration method store the config data in the LDAP database itself. The data in this database is contained in cn=config tree. All options, including runtime options, can be modified in the same manner as normal LDAP data. By making an LDIF with the changes to the database, any aspect of the slapd server's operation can be changed with ldapmodify. This greatly simplifies management of the LDAP servers.
User controlable access levels on additional data types
The next major change is the adoption of additional attributes, and the inclusion of user-editable access control lists over that new data. The way this in implemented is the use of an additional attribute describing the access level of its related attribute. For example, say a user wanted to put their twitter username in the attribute twitterUser, and allow only authenticated cluenet users, they would set them like the following.
twitterUser: Cluenet acstwitterUser: user
The acs* attributes are what determine the access level required to view the associated attribute. This allows users to post additional info, and control who gets to view it, without the need to have an admin change this, or change the global settings. A detailed list of the attributes in the ldap database, along with their default access levels, and if they are able to have the access level changed can be found in the Cluenet LDAP Attributes Table.
Storage of server info and DNS data
Another change is the addition of the ou=servers organizational unit in the LDAP database. This ou contains the general information for each server, such as proc info and OS type, along with DNS data, list of admins, and several other pieces of data. A each server admin is listed as the owner, via their ldap DN, and given full access to change the data for that server, with a few exceptions such as official status. This allows a server owner to change the DNS records in the database to reflect any changes, not upgrades, changes in rules, and add authorized administrators (who in turn have access to change some of these attributes). This greatly reduces the amount of time it takes to get DNS records changed for a server.
DNS records generated from server LDAP entries
With the DNS data for a server being stored in the LDAP database, we are able to generate BIND zones and configurations from this data, and then update those files immediately, resulting in much faster DNS record changes. When the IP address for a server is changed, any user with a valid Kerberos TGT is allowed to run the DNS refresh API call, and update the DNS records.
Standardised API
In an effort to allow people to create programs that can interact with the authentication and user management system, an API was created. It consists of a series of commands, based on Kerberos remctl commands, that can change and gather info from the ldap database, IRC nickserv, DNS servers, DaVinci, and various other sources. Each command has a required access level to allow a user to run them. The use of remctl means that the api commands can be used directly from any computer set to use the CLUENET.ORG Kerberos realm, or by any programming language that is able to execute external programs, such as PHP, PERL, bash, ruby, and various others, without modification. All that is needed is a valid TGT. The product of this will be a varied array of interfaces to control user data, display this data, and manage the network in general.
