Homogeneous Administration of UNIX and NT with VAMOS

1. Homogeneous Administration of UNIX and NT with VAMOS Wolfgang Friebel A Versatile Administration tool in a Multi OS environment And Gandalf said: 'Many folk like to know beforehand what is to be set on the table; but those who have laboured to prepare the feast like to keep their secret; for wonder makes the words of praise louder.’ Quote from Tolkien VAMOS system administration

2. A buzzword compliant talk VAMOS system administration

3. Why VAMOS • New tasks for Sysadmins to cope with • managing AFS volumes and AFS home directories • common password management for UNIX and NT users • presently used tool GenuAdmin not prepared for future tasks • Increasing interdependence between UNIX and NT admin tasks • registering hosts for DNS • shared (AFS) directories for users • mail access and delivery • Rising number of tools and potentially inconsistent data collections • need to manage Oracle tables (user registry, phone book, …) • keep configuration files up to date ( for DNS, NIS, printer support, …) • influence of asset management on system administration VAMOS system administration

4. Present situation • In use at Zeuthen (UNIX) • GenuAdmin for registering users and configuring services • sue/cfengine for installing systems and administering software • logserver and prlog to analyze logfiles • access database for rudimentary asset management • In use at Hamburg (UNIX) • qddb based user registry • Tcl/Tk based tool to administer AFS and DFS volumes • salad/wboom for installing systems and administering software • In use for NT • tools accessing Oracle databases and NT internal data VAMOS system administration

5. Deficits • Tools are incompatible to each other • Similar tasks get solved with differing methods • Tools are not extensible/flexible enough • Tools are usually not running on multiple platforms • The same data are stored in several locations and are to a certain percentage inconsistent to each other • Access to the data is often done with dedicated programs VAMOS system administration

6. Why not commercially available tools • Candidates are Unicenter, Tivoli, HP Open View • Tools provide a framework and some basic functionality • Tools will require extensive adaptation and configuration work • Tools will not cover all “exotic” solutions (e.g. AFS, krb4, DCE, …) • Tools are very expensive • Cost effectiveness probably only for very large installations • Number of items to handle is small in terms of a database ( O(1000) ) • Tasks are presently solved with relatively simple tools VAMOS system administration

7. Our approach (VAMOS) Aims of the project • step by step replacement of existing tools by creating a set of programs with identical underlying mechanisms • Creation and management of consistent data collections and its efficient storage in databases • Development of interfaces to existing data sources • modular object oriented design of • interfaces to data • user interfaces • administration modules • platform independent system management and access to data • Creation of reliable and scalable tools without single points of failure VAMOS system administration

8. Our approach (2) Expected results • Consistent description of work and data flows in the computer center • Synergy effects by merging similar mechanisms on different platforms • Further automation of the system management, release of manpower within a larger time scale • Education and training on the fields of modern software concepts (OO design, UML, CORBA, DCOM, RMI, XML) • Increased motivation of the project members • Reuse of software for other projects • Use of the tools to be developed outside the computer center / at other sites VAMOS system administration

9. Our approach (3) Time frame • Demonstration of the concepts within two month after start of project • Essential parts ready within one year (including platform spanning userreg) Resources • higher productivity by using new techniques (OO) • expect further people to share the project (due to well separated tasks) • additional manpower (students) • extensive use of internet resources • productivity tools already at DESY (e.g. Rational Rose) • external coach would be helpful VAMOS system administration

10. Managing the project • Try to stick to formal project management models (found in literature, e.g. V-model 97) • Description of the project in varying detail, identification of components, describing required data and processes, … • Modelling the project with classes and methods • definition of milestones • Quality management by • formal test suites • coding rules • external test by an independent group • Establishing the project team and assigning tasks VAMOS system administration

11. Authentication/ Authorization User interfaces, OO consultant Database interfaces, Project leader Logging and change management Classification of data using UML Administrative modules Client/server modules NT integration Mac integration Quality control Documentation Alf Wachsmann Angelika Leich Wolfgang Friebel Waltraut Niepraschk Dirk Kamrad, Thorsten Kleinwort Waltraut Niepraschk, T. Kleinwort Fatima Streit, Wolfgang Friebel Gunter Trowitzsch, Fatima Streit Michael Winde N.N. N.N . The current project team plus interested people listening VAMOS system administration

12. Decisions and Achievements • OO design as opposed to procedural design • Modularity, necessary modules: • User Interfaces (Command line, Tk based, WWW based, ASCII, …) • Authentication, Authorization, Encryption (Kerberos, ...) • SQL Database Interfaces (Oracle, mSQL, db, dbm, Access, flat files, …) • Logging, change management (syslog, history databases) • Communication modules (Client/Server, Proxies, CORBA, daemons, …) • Interfaces to various data sources (Quota, Process Table, UFS, NFS, AFS, NIS, DNS, NT registry, software repository,…) • Administrative modules (configuring the OS, hardware, software) VAMOS system administration

13. Decisions and Achievements(2) • No dependence on data locations and data access methods • fetch (inconsistent) data from anywhere (using common interfaces) • make consistency checks • store consistent data for later retrieval (ODBMS or RDBMS) • Platform independence as far as possible • Class design and documentation using UML • Project documentation in a format, that can be converted to XML VAMOS system administration

14. OO Programming in Perl • Perl is THE language for system administrators • Huge number of modules centrally maintained (850, quickly rising) • Major admin tasks already well covered (Database support, NIS, AFS, LDAP, …) • Wide range of available user interfaces (WWW, Tk, gTk, xforms, curses, …) • Rapid prototyping, short development cycles “You can write faster programs in C, but you can faster write programs in perl” • essentially all OO features (multiple inheritance, encapsulation, …) • future versions or certain modules might be reworked in C++, Java VAMOS system administration

15. The evolution of tools Admin Task(s) Auth GUI Standalone DBI Data VAMOS system administration

16. The evolution of tools Admin Task(s) Admin Task(s) Auth GUI Standalone Client / Server RPC Auth GUI Comm Crypt Comm Log DBI Data DBI Data VAMOS system administration

17. The evolution of tools Admin Task(s) Admin Task(s) Auth GUI Standalone Client / Server RPC Auth GUI Comm Crypt Comm Log DBI Data DBI Data Hierarchical Architecture ORB Auth GUI Comm App Server 1 App Server 2 Crypt Comm Log App Server 3 DBI Data VAMOS system administration

18. Modularity: Example Databases Access slapd Oracle mSQL ODBC CSV File Database Layer Database specific drivers (DBD) LDAP DBD Layer (perl) Generic Database interface (DBI) DBI Layer (perl) Database methods (get, update, check,...) VAMOS Layer Application VAMOS system administration

19. Milestones • Now • Read only access to databases (Oracle, mSQL, Access, flat file) • Installation of tools: perl on UNIX and NT, Rational Rose • UI design , simple implementation for perl/Tk, plain ASCII • Sample program demonstrating DB access and (G)UI • May • write access to databases • Authentication, authorization, encryption • command line and WWW user interface • June • Class definitions for NetNode, User • Modules for logging, RPC and Kerberos password administration VAMOS system administration

20. Milestones (2) • July • Design of a new user registry (HH and Zeuthen features combined) • AFS volume management module • August • Refinement of UI (and other modules) • September • Prototype of a new user registry (password, quota, finger info) • till 3/2000 • User registry (working version) • Host management tool • Software registry • 3/2000 start of usage in a production environment VAMOS system administration

21. Tested modules • UI (ASCII, Tk) (similar solution for WWW in Linux 5/99 journal) • DBI/DBD both from NT and UNIX • Access to Berkeley db and dbm files (NIS) • Socket communication UNIX<->NT and proxy servers • Quota management (read, write including AFS!) • AFS module (adding a new user with directories, quota, ACLs, Kerberos account data, group management (pts)) vos suite missing • Kerberos4 authentication/authorization • existing but not tested • Access to NT registry, NT admin tasks, LDAP, UNIX df and ps interface, syslog, ... VAMOS system administration

22. Sample classdesign UML definition of a NetNode (host, printer, switch, …) VAMOS system administration

23. A simple application • Demonstration of Database Access, same script works for • mSQL, Oracle, MS Access, flat CSV File • Tk/perl, ASCII, (cmdline and WWW will follow) Unix, NT VAMOS system administration

24. Further information • Mailing list vamos@ifh.de • mail to vamos-request@ifh.de, “subscribe” in mail body • Files in /afs/ifh.de/project/VAMOS (CVS repository) • URL: http://www.ifh.de/computing/projects/VAMOS • Books on OO, Perl, UML, ... VAMOS system administration