Reporting Status or Progress

312 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
312
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Reporting Status or Progress

  1. 1. Towards a tool for common sysadmin tasks under UNIX and NT - A proposal Wolfgang Friebel DESY
  2. 2. Motivation <ul><li>New tasks for Sysadmins to cope with </li></ul><ul><ul><li>managing AFS volumes and AFS home directories </li></ul></ul><ul><ul><li>common password management for UNIX and NT users </li></ul></ul><ul><ul><li>presently used tool GenuAdmin not prepared for future tasks </li></ul></ul><ul><li>Increasing interdependence between UNIX and NT admin tasks </li></ul><ul><ul><li>registering hosts for DNS </li></ul></ul><ul><ul><li>shared (AFS) directories for users </li></ul></ul><ul><ul><li>mail access and delivery </li></ul></ul><ul><li>Rising number of tools and potentially inconsistent data collections </li></ul><ul><ul><li>need to manage Oracle tables (user registry, phone book, …) </li></ul></ul><ul><ul><li>keep configuration files up to date ( for DNS, NIS, printer support, …) </li></ul></ul><ul><ul><li>influence of asset management on system administration </li></ul></ul>
  3. 3. Present situation <ul><li>In use at Zeuthen (UNIX) </li></ul><ul><ul><li>GenuAdmin for registering users and configuring services </li></ul></ul><ul><ul><li>sue/cfengine for installing systems and administering software </li></ul></ul><ul><ul><li>logserver and prlog to analyze logfiles </li></ul></ul><ul><ul><li>access database for rudimentary asset management </li></ul></ul><ul><li>In use at Hamburg (UNIX) </li></ul><ul><ul><li>qddb based user registry </li></ul></ul><ul><ul><li>Tcl/Tk based tool to administer AFS and DFS volumes </li></ul></ul><ul><ul><li>salad/wboom for installing systems and administering software </li></ul></ul><ul><li>In use for NT </li></ul><ul><ul><li>tools accessing Oracle databases and NT internal data (see talk by Christian Trachimov, DESY) </li></ul></ul>
  4. 4. Deficits <ul><li>Tools are incompatible to each other </li></ul><ul><li>Similar tasks get solved with differing methods </li></ul><ul><li>Tools are not extensible/flexible enough </li></ul><ul><li>Tools are usually not running on multiple platforms </li></ul><ul><li>The same data are stored in several locations and are to a certain percentage inconsistent to each other </li></ul><ul><li>Access to the data is often done with dedicated programs </li></ul>
  5. 5. Why not commercially available tools <ul><li>Candidates are </li></ul><ul><li>Unicenter, Tivoli, HP Open View, ... </li></ul><ul><li>Tools provide a framework and some basic functionality </li></ul><ul><li>Tools will require extensive adaptation and configuration work </li></ul><ul><li>Tools will not cover all “exotic” solutions (e.g. AFS, krb4, DCE, …) </li></ul><ul><li>Tools are very expensive </li></ul><ul><li>Cost effectiveness probably only for very large installations </li></ul><ul><li>Number of items to handle is small in terms of a database ( O(1000) ) </li></ul><ul><li>Tasks are presently solved with relatively simple tools </li></ul>
  6. 6. Our proposal: Project VAMOS <ul><li>A V ersatile A dministration tool in a M ulti OS environment </li></ul><ul><li>Aims of the project </li></ul><ul><ul><li>step by step replacement of existing tools by creating a set of programs with identical underlying mechanisms </li></ul></ul><ul><ul><li>Creation and management of consistent data collections and its efficient storage in databases </li></ul></ul><ul><ul><li>Development of interfaces to existing data sources </li></ul></ul><ul><ul><li>modular object oriented design of </li></ul></ul><ul><ul><ul><li>interfaces to data </li></ul></ul></ul><ul><ul><ul><li>user interfaces </li></ul></ul></ul><ul><ul><ul><li>administration modules </li></ul></ul></ul><ul><ul><li>platform independent system management and access to data </li></ul></ul><ul><ul><li>Creation of reliable and scalable tools without single points of failure </li></ul></ul>
  7. 7. Expected results <ul><ul><li>Consistent description of work and data flows in the computer center </li></ul></ul><ul><ul><li>Synergy effects by merging similar mechanisms on different platforms </li></ul></ul><ul><ul><li>Further automation of the system management, release of manpower within a larger time scale </li></ul></ul><ul><ul><li>Education and training on the fields of modern software concepts (OO design, UML, CORBA, DCOM, XML) </li></ul></ul><ul><ul><li>Reuse of software for other projects </li></ul></ul><ul><ul><li>Use of the tools to be developed outside the computer center / at other sites </li></ul></ul>
  8. 8. Design criteria <ul><li>OO design as opposed to procedural design </li></ul><ul><li>Modularity, necessary modules: </li></ul><ul><ul><li>User Interfaces (Command line, Tk based, WWW based, ASCII, …) </li></ul></ul><ul><ul><li>Authentication, Authorization, Encryption (Kerberos, ...) </li></ul></ul><ul><ul><li>SQL Database Interfaces (Oracle, mySQL, Access, flat files, …) </li></ul></ul><ul><ul><li>Interfaces to other data sources (db, dbm, LDAP, NT registry) </li></ul></ul><ul><ul><li>Logging, change management (syslog, history databases) </li></ul></ul><ul><ul><li>Communication modules (Client/Server, Proxies, RPC, …) </li></ul></ul><ul><ul><li>Administrative modules (configuring the OS, file system tasks (AFS, NFS, ...), process mgmt, subsystems (NIS, DNS), software repository,…) </li></ul></ul>
  9. 9. Design criteria(2) <ul><li>No dependence on data locations and data access methods </li></ul><ul><ul><li>fetch (inconsistent) data from anywhere (using common interfaces) </li></ul></ul><ul><ul><li>make consistency checks </li></ul></ul><ul><ul><li>store consistent data for later retrieval (ODBMS or RDBMS) </li></ul></ul><ul><li> uniform description of data sources and acces rights (metadata ) </li></ul><ul><li>Platform independence as far as possible </li></ul><ul><li>Class design and documentation using UML </li></ul><ul><li>Project documentation in a format, that can be converted to XML </li></ul>
  10. 10. The language choice: Perl <ul><li>Popular choices: C++, Java, Perl, Python, Eiffel, Smalltalk (others?) </li></ul><ul><li>Knowledge of C++ and Java not sufficient for such a project </li></ul><ul><li>Perl is THE language for system administrators </li></ul><ul><li>Huge number of modules centrally maintained (1000, quickly rising) </li></ul><ul><li>Major admin tasks already well covered </li></ul><ul><ul><li>(Database support, NIS, AFS, LDAP, NT registry…) </li></ul></ul><ul><li>Wide range of available user interfaces </li></ul><ul><ul><li>(WWW, Tk, gTk, xforms, curses, …) </li></ul></ul><ul><li>Rapid prototyping, short development cycles </li></ul><ul><ul><li>“ You can write faster programs in C, but you can faster write programs in perl ” </li></ul></ul><ul><li>essentially all OO features (multiple inheritance, encapsulation, …) </li></ul>
  11. 11. Proposed architecture Client(s) (G)UI Crypt Comm Auth ORB DBI Log Comm App Server 2 App Server 3 App Server 1 Data DB server App servers Crypt
  12. 12. Modularity: Example Data access Oracle ODBC mSQL CSV File Database engines Database specific drivers (DBD) API Layer (perl) Generic Database interface (DBI) DBI Layer (perl) Data access methods (get, update, check,...) VAMOS Layer Application Access LDAP slapd
  13. 13. Managing the project <ul><li>Description of the project in varying detail, identification of components, describing required data and processes, … </li></ul><ul><li>Modeling the project with classes and methods </li></ul><ul><li>Definition of milestones </li></ul><ul><li>Quality management by </li></ul><ul><ul><li>formal test suites </li></ul></ul><ul><ul><li>coding rules </li></ul></ul><ul><ul><li>external test by an independent group </li></ul></ul><ul><li>Establish the project team and assign tasks </li></ul>
  14. 14. Milestones <ul><li>Already achieved </li></ul><ul><ul><li>Access to databases (Oracle, m(y)SQL, Access, flat file) </li></ul></ul><ul><ul><li>Installation of tools: perl on UNIX and NT, Rational Rose </li></ul></ul><ul><ul><li>UI design , simple implementation for perl/Tk, plain ASCII </li></ul></ul><ul><ul><li>demo of simple WWW user interface </li></ul></ul><ul><ul><li>Sample program demonstrating DB access, (G)UI and Client/Server </li></ul></ul><ul><ul><li>Kerberos password administration (still with old GenuAdmin tool) </li></ul></ul><ul><li>October 99 </li></ul><ul><ul><li>Authentication, authorization, encryption, logging </li></ul></ul>
  15. 15. Milestones (2) <ul><li>December </li></ul><ul><ul><li>Class definitions for NetNode and User classes </li></ul></ul><ul><ul><li>Design of a new user registry </li></ul></ul><ul><ul><li>AFS volume management module </li></ul></ul><ul><ul><li>Prototype of a new user registry (password, quota, finger info) </li></ul></ul><ul><li>till 3/2000 </li></ul><ul><ul><li>User registry (final version) </li></ul></ul><ul><ul><li>Host management tool </li></ul></ul><ul><ul><li>Software registry </li></ul></ul>
  16. 16. Tested modules <ul><li>UI (ASCII, Tk) (similar solution for WWW in Linux Magazin 5/99 ) </li></ul><ul><li>DBI/DBD both from NT and UNIX </li></ul><ul><li>Access to Berkeley db and dbm files (NIS) </li></ul><ul><li>Socket communication UNIX<->NT and proxy servers </li></ul><ul><li>Quota management (read, write including AFS!) </li></ul><ul><li>AFS module (adding a new user with directories, quota, ACLs, Kerberos account data, group management (pts)) vos suite missing </li></ul><ul><li>Kerberos4 authentication/authorization </li></ul><ul><li>existing but not tested </li></ul><ul><ul><li>Access to NT registry, NT admin tasks, LDAP, UNIX df and ps interface, syslog, ... </li></ul></ul>
  17. 17. Sample class design <ul><li>UML definition of a NetNode (host, printer, switch, …) </li></ul>
  18. 18. A simple application <ul><li>Platform independent access to data </li></ul><ul><li>in various databases using several </li></ul><ul><li>user interfaces </li></ul>
  19. 19. Status of VAMOS <ul><ul><li>Initial proposal spring 1999 </li></ul></ul><ul><ul><li>Demonstration of the concepts already done for various parts </li></ul></ul><ul><ul><li>Progress very slow due to lack of manpower </li></ul></ul><ul><ul><ul><li>at the moment few enthusiasts at Zeuthen </li></ul></ul></ul><ul><ul><ul><li>part time help by two students (starting Oct 99) </li></ul></ul></ul><ul><ul><li>Real application (e.g. Quota mgmt) expected by end of 1999 </li></ul></ul><ul><ul><li>Essential parts planned for II/2000 (including UNIX/NT userreg) </li></ul></ul><ul><ul><li>Project already 3 months late compared to initial planning </li></ul></ul><ul><ul><li>Project might fail without additional resources </li></ul></ul>
  20. 20. Further information <ul><li>Mailing list vamos@ifh.de </li></ul><ul><ul><li>mail to vamos-request@ifh.de, “subscribe” in mail body </li></ul></ul><ul><li>Files in /afs/ifh.de/project/VAMOS (CVS repository) </li></ul><ul><li>Books on OO, Perl, UML, ... </li></ul>

×