250 likes | 418 Vues
VO Naming Proposals. Explanation (first) and Discussion (after first) Oscar Koeroo JRA3. Index.voms. Widely known VO name constraints VO naming known guidelines Global VO Naming proposals Using normal DNS features to solve the problem What we did for GIN
E N D
VO Naming Proposals Explanation (first) and Discussion (after first) Oscar Koeroo JRA3
Index.voms • Widely known VO name constraints • VO naming known guidelines • Global VO Naming proposals • Using normal DNS features to solve the problem • What we did for GIN • Discussion moment: Where do you want to go today? To change: View -> Header and Footer
VO Name Information • Allowed VO (and group/role name) characters: • [a-zA-Z0-9-_\.] • In English: • VO names can start with a number • VO Names are alphanumeric and can also contain the characters minus/dash/hyphen, underscore and dot • The FQAN format is ‘defacto’ standardized to the following format according to Vincenzo’s memo: • /<VO Name> [[/<group 1>]/<subgroup N>] [/Role=<your role>] • Info from: VOMS developers (vomsd and VOMS-Admin) To change: View -> Header and Footer
VO Name Information • VO names *should* not have a limited length (including the group and role names) • /United-Federation-Of-Planets_Starship.Enterprise.NGC1701 • /picard/whatistheexactamountofcharactersthatIcanputintothishugestringtobeusedforanormaltypeofgroupinthevonamedafterthecaptainoftheussenterprisefromthestartrekthenextgenerationseriesfromthenineteennightees • /picard/whatistheexactamountofcharactersthatIcanputintothishugestringtobeusedforanormaltypeofgroupinthevonamedafterthecaptainoftheussenterprisefromthestartrekthenextgenerationseriesfromthenineteennightees/Role=thisisanewrolespecificallycreatedtocrashasystemthatusesVOMSofcourseIhopethatmysoftwarewhichisLCMAPSprimarilywillholdoutofcourse • An initiative of Steven Burke to test these things To change: View -> Header and Footer
Known Guidelines – Naming a VO • Decide on a name for the VO that it: • Corresponds to its identity • e.g. DTEAM for the Deployment Team VO • Easy to remember and recognise • Also for Resource Admins how are not affiliated to the VO themselves like BIOMED for the Biomedical activity VO. • Don’t risk on using names longer then 6 characters or use special characters which could be mistaken for a regular expression • Like DZERO for the D0 experiment VO • Doesn’t clash with reserved service or file names in the Grid software distributions • Give appropriate DNS host aliases and host certificates, when necessary • e.g the sixt-vo.cern.ch is the host alias of the VODB server of the SIXT VO • Info from: Maria Dimou To change: View -> Header and Footer
New Global VO naming proposal • Problem: • No name (space) control • Name clashes are startinig to appear • FUSION and FUSION’ • ATLAS vs. USATLAS vs. Swiss Atlas vs. NorduGrid ATLAS • uscms vs. cms • Biomed vs. Bio Italy • Solution: • A hierarchical, extensible VO name space is needed Info from: Oxana Smirnova To change: View -> Header and Footer
#1 The proposal from Oxana Smirnova: Global VO Naming To change: View -> Header and Footer
New Global VO naming proposal Overall rules: • Character set is limited to alphanumeric without punctuation marks • Case-insensitive • A full VO name is constructed of: • level (domain) name fragments • separated by a period (dot) • in level ascending order • level 0 name leftmost, level 1 - next to the right, etc • Like: <level0>[.level1][.level2]<.level3> To change: View -> Header and Footer
level 0 • Level 0: (top level) national, global/international • Consists of 241 domains • 240 official two-letter country code • one cross-country domain named "int“ • Each national level is controlled by the respective national Grid Forum or a similar body • INT domain is controlled by the GGF/EGA • Examples: • SE.SWEGRID (Swedish VOs) • RU.DUBNAGRID (Town Grid project) • IT.ENEA (a cross-national VO) • INT.CERN (International HEP lab) To change: View -> Header and Footer
level 1 • Level 1: International regional level (optional) • INT domain may have several sub-domains, introduced whenever necessity appears • Each such sub-domain is controlled by the respective international Grid initiative, congress or another forum • This level is optional and can be omitted for global transnational organizations, such as CERN • The level can contain VOs or area/infrastructure sub-levels • Examples: • INT.BALTIC.BALTICGRID (a regional VO) • INT.CE.VOCE (a regional VO) • INT.EU.EGEE (EU infrastructure sub-level) To change: View -> Header and Footer
level 2 • Level 2: Area or infrastructure level (optional) • If necessary, regional, national or international domains may have area- or infrastructure-specific sub-domains, aiming at grouping VOs • Each such sub-domain is controlled by the respective infrastructure project or area-specific initiative • Examples: • CH.SWISSGRID.ATLAS (Swiss ATLAS Grid VO) • SE.SWEGRID.snic-003-04-59 (a national VO) • INT.EU.EGEE.DTEAM (EGEE VO) • INT.CERN.ATLAS (International HEP VO) To change: View -> Header and Footer
level 3 • Level 3: Virtual Organization Level • This is the actual level controlled by VOs and having VO-specific structure (not discussed here) • User communities can decide on a simple name here and should consider to use the guidelines of naming a VO To change: View -> Header and Footer
Summary of this proposal • The complete VO name is thus composed from mandatory and optional components as: • <level0> [.level1][.level2] <.level3> • Valid VO names are: • NL.Astrop • EE.TTU • US.OSG.GROW • CH.SWISSGRID.ATLAS • INT.Dzero • INT.CERN.CMS • INT.NORDIC.ARC-COMMUNITY • INT.EU.EGEE.DTEAM To change: View -> Header and Footer
Personal feelings • It looks like a reversed DNS naming, but it isn’t • It relies on community effort • No formal bodies are do this work which means they’ll need to be appointed • People could freely interpret the rules if this scheme doesn’t come with (practical) guidelines • How to endorse? • Who is the boss of int.* or int.eu* or us.*? • Tendency to put meta-data in these names • Some organizational meta-data could perhaps not fit the scheme To change: View -> Header and Footer
#2 An idea from David Groep / Oscar Koeroo: DNS (and making use of RFC 2782) To change: View -> Header and Footer
DNS • Personally I would vote for a real DNS solution… • Less confusion and mix-ups • Why should we not use standards if they’re already available? • RFC 1034 • Domain names - concepts and facilities • Section 3.4 - Example name space • Strong urge to only use 7-bit ASCII characters • a-zA-Z[a-zA-Z0-9-\.]*\. • RFC 2782 • A DNS RR for specifying the location of services (DNS SRV) To change: View -> Header and Footer
RFC 1034 - Domain names • You might know this RFC… the one with the ‘normal’ DNS names To change: View -> Header and Footer
RFC 2782 - DNS SRV • The SVR RR allows administrators to use several servers for a single domain • To move services from host to host with little fuss • To designate some hosts as primary servers for a service and others as backups. To change: View -> Header and Footer
Small example • If a SRV-cognizant LDAP client wants to discover an LDAP server that supports TCP and provides LDAP for the domain ‘example.com’, it does a lookup to: • _ldap._tcp.example.com • Which could also have been: • _voms._tcp.nikhef.nl To change: View -> Header and Footer
The format _Service._Proto.Name TTL Class SRV Priority Weight Port Target • Service: • The symbolic name for the desired service • Proto: • The symbolic name for the desired protocol • Name • The domain this RR refers to. • TTL • Standard DNS meaning • Class • Standard DNS meaning; SRV records occur in the IN Class • Priority • The priority of this target host expressed in a 16 bit unsigned integer. • Lowest value is best and the client MUST try the best service first • The weight field is considered when two services have the same priority • Weight • Expressed in a 16bit unsigned integer • Larger weight SHOULD be given a proportionately higher probability of being selected • When there is no server selection, the admin SHOULD use Weight 0 when there isn’t any server selection • Client computes the sum of all weights, then creates a random number between 0 and the sum of weights. The first weight greater or equal then the random number is the service to be used by the client • Port • 16 bit unsigned integer service port number • Target • Domain name of the target host Note: the _ (underscore) is used to avoid collisions with DNS labels To change: View -> Header and Footer
RFC 2782 – fictional example $ORIGIN example.com. @ SOA server.example.com. root.example.com. ( 1995032001 3600 3600 604800 86400 ) NS server.example.com. NS ns1.ip-provider.net. NS ns2.ip-provider.net. ; voms - use old-slow-box or new-fast-box if either is ; available, make three quarters of the logins go to ; new-fast-box. _voms._tcp SRV 0 1 9 old-slow-box.example.com. SRV 0 3 9 new-fast-box.example.com. ; if neither old-slow-box or new-fast-box is up, switch to ; using the sysdmin's box and the server SRV 1 0 9 sysadmins-box.example.com. SRV 1 0 9 server.example.com. server A 172.30.79.10 old-slow-box A 172.30.79.11 sysadmins-box A 172.30.79.12 new-fast-box A 172.30.79.13 ; NO other services are supported *._tcp SRV 0 0 0 . *._udp SRV 0 0 0 . To change: View -> Header and Footer
Short explanation • The client of the ‘voms’ service in the ‘example.com.’ domain needs an SRV lookup of “_voms._tcp.example.com” • Possibly A lookups of “new-fast-box.example.com.” (and/or other hosts name) To change: View -> Header and Footer
Critical detail • DNS Spoofing could become a whole new ballgame… • As a service you are not controlling this information flow about your service To change: View -> Header and Footer
Time for GIN? • Hot discussions on MWSG and GIN-Auth list about VO Naming and all kinds of things passed by • including the use a new TLD: .grid • Since I was moved forward to be the VOMS-Admin for GIN therefore I’ve put all the ideas in my virtual blender and added my own twist to the mix • The VO name: GIN-GGF-ORG is now active • Because it is clearly not DNS, but logically looks like DNS • Quote from my announcement e-mail: • This VO name can be changed when we have a common agreement on the VO naming convention To change: View -> Header and Footer
Where do you want to go today? A few options: • 1.) We keep on hurdling with just the VO names • Pro: no change needed anywhere • Con: one can expect pitfalls down the road… • 2.) Implement the VO Naming proposal • Pro: Name space regulation, controlled by ‘others’ • Cons: takes time to setup authoritive groups • Cons: relocation problems when pinned to a level0 to level3 domain • 3.) A real DNS solution • RFC 1034 for Domain Names • RFC 2782 for the DNS SRV • 4.) Something completely different? • DNS trickery • Logical DNS: GIN-GGF-ORG • DNS-alike: picard|kuiken.nikhef.nl • e-mail-alike: picard@kuiken.nikhef.nl • 5.) Please fill in blank with your idea: ______ To change: View -> Header and Footer