System inventory is an application with many uses ranging from hardware and software inventory data and collecting business-related information to configuration management and software distribution. Several commercial software options are available in the market. However, some of the challenges to deploying such commercial software are: compatibility with various platforms, integration complexity (heavy customization), high cost due to proprietary concept, function extensibility, lack of data security, and lack of standards. There are also homegrown solutions, such as using scripts and cron jobs to collect data that illustrate the limitations of scalability, security, and standardization.
Ansible
Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.
Designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time.
It uses no agents and no additional custom security infrastructure, so it’s easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English.
On this page, we’ll give you a really quick overview so you can see things in context. For more detail, hop over to docs.ansible.com.
LDAP
LDAP stands for Lightweight Directory Access Protocol. In most cases, it is the core element of security applications such as authentication, authorization, policy management, and single sign-on. In the Unix system arena, LDAP is also becoming popular as a replacement for Network Information Service (NIS), not only for traditional password authentication but for other maps as well (hosts, automount, aliases, etc.). On the PC side, Active Directory is the LDAP implementation in the Windows environment. Organizations with an LDAP infrastructure can take full advantage of LDAP properties without investing in any additional software.
LDAP is not limited to contact information, or even information about people. LDAP is used to look up encryption certificates, pointers to printers and other services on a network, and provide “single sign-on” where one password for a user is shared between many services. LDAP is appropriate for any kind of directory-like information, where fast lookups and less-frequent updates are the norm.
As a protocol, LDAP does not define how programs work on either the client or server side. It defines the “language” used for client programs to talk to servers (and servers to servers, too). On the client side, a client may be an email program, a printer browser, or an address book. The server may speak only LDAP, or have other methods of sending and receiving data—LDAP may just be an add-on method.
LDAP also defines: Permissions, set by the administrator to allow only certain people to access the LDAP database, and optionally keep certain data private. Schema: a way to describe the format and attributes of data in the server. For example: a schema entered in an LDAP server might define a “groovyPerson” entry type, which has attributes of “instantMessageAddress”, and “coffeeRoastPreference”. The normal attributes of name, email address, etc., would be inherited from one of the standard schemas, which are rooted in X.500 (see below).
LDAP was designed at the University of Michigan to adapt a complex enterprise directory system (called X.500) to the modern Internet. X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service “for the rest of us.”
Bridging the gap
if one already has a domain controller (AD or similar) then one already has a central source of truth that is tracking computers when they join the domain. Thus, the devgateway/lia dynamic inventory module gives ansible a way to look up these machines directly from your domain controller.