-- MariaALANDESPRADILLO - 11 Oct 2007

New YAIM features for system administrators

Future YAIM developments affecting yaim core should take into account the needs and requirements of system administrators. After the EGEE 2007 conference, we have started a new task to collect feedback from sys admins to be able to plan the content of future yaim core releases. The goal is to try to provide new functionality that makes the life of sys admins easier.

In this wiki page we are collecting feedback from sys admins gathered at the conference and at CERN. We would like to increase the number of items in this list with feedback from other people that haven't yet had the chance to contact us with their proposals. Any type of sys admin is welcome to contribute. The needs and experiences of each sys admin vary considerably from one site to another, so all the points of view are important for us, since the aim of YAIM is to support all types of sites.

If you have access to the wiki pages, please, feel free to add new items in the list, describing the feature you would like to see in YAIM, or otherwise send a mail to yaim-contact@cernNOSPAMPLEASE.ch and we will publish your feature request.

After the first collect, we will probably ask you to tell us which of these items should have more priority in our development plans according to your needs, but we will contact you again for that.


  • from Ulrich Schwickerath, CERN-FIO, system administrator of WNs and lcg CEs in Production:
    1. Mark node-info.d files as config files to allow local customizations..
    2. It would very good if YAIM could always leave the machine in a 'clean' status where one knows exactly what has been installed and what files have been modified. This also implies removing files that are no longer used unless these files are controlled by another package manager (eg. rpm)
    3. Separate site specific management tools and customisations from YAIM so sys admins can easily 'switch off' certain YAIM configurations that are not needed (like user management or file ownership/permissions management).
    4. Improve YAIM log. Print information in a more organised way, maybe per module.
    5. Print a summary after running a configuration to quickly detect which files have been modified, which services have been started, etc.
    6. Allow to always include new functions in the function list without modifying manually the function list. For instance, a directory containing new functions that will always be executed after the default ones in node-info.d
    7. Implement a mechanism similar to .rpmnew in order not to overwrite configuration files modified by the system admin.

  • from Jose Miguel Dana, CERN Openlab, grid deployment and virtualisation:
    1. Mechanism to quickly notice the changes from one release to another. This could be done by printing the changes at the beginning of the log file and/or by implementing a deprecated mechanism like in JAVA and/or by documenting the changes in the wiki in a clearly and easy to access/find way.
    2. List which nodes can be configured by YAIM and with wich configuration target name.
    3. It would be very useful to know which log files have been modified during the configuration, and in general which log files are involved in the deployment of a service, so afterwards it's easy to debbug problems.

  • from GGUS tickets:
    1. When using LDAP for users/groups, YAIM is unable to handle this in config_users. GGUS #20711.

  • from Romain Wartel, EGEE Operational Security Coordination Team:
    1. YAIM could perform basic security checks on the node to test if it is 'reasonably' secure.

  • from Patrik Lason, system administrator of CYFRONET-LCG2:
    1. It would be usefull to have a new variable for each VO, i.e. VO_ATLAS_SGM_PROD_POOL=static/dynamic to deal with different requests for sgm/prd mappings. I could then have static and dynamic accounts in users.conf.

  • from Antun Balaz, Institute of Physics, Belgrade
    1. It would be good to have the possibility of using a different wn-list.conf, users.conf and groups.conf depending on the service/node.

  • from Alessandra Forti, University of Manchester, UK
    1. Bug #17552. Create a function to be able to automatically do all the necessary configuration steps when a new VO has been added.

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r6 - 2007-11-20 - MariaALANDESPRADILLO
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback