From blu@sac.sfbay.sun.com Fri Apr 17 10:19:03 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HHJ30g011463 for ; Fri, 17 Apr 2009 10:19:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3HHJ0a7005918; Fri, 17 Apr 2009 10:19:02 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900K0N9FQSW00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Apr 2009 10:19:02 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI9005HY9FP79E0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Apr 2009 10:19:01 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HHJ1cD042892; Fri, 17 Apr 2009 10:19:01 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HHJ074011457; Fri, 17 Apr 2009 10:19:00 -0700 (PDT) Received: (from blu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3HHJ002011453; Fri, 17 Apr 2009 10:19:00 -0700 (PDT) Date: Fri, 17 Apr 2009 10:19:00 -0700 (PDT) From: Brian Utterback Subject: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] To: PSARC-ext@sun.com Message-id: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2469 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Upgrade NTP to Version 4 1.2. Name of Document Author/Supplier: Author: Brian Utterback 1.3 Date of This Document: 17 April, 2009 4. Technical Description Upgrade NTP to version 4. This project proposes to remove the current version 3.4 NTP deliverables and replace them with version 4.2.5. The current version in Solaris was released 11 years ago. The NTP project has continued to advance the code base for the entire time. This will be done by removing the current SUNWntpr and SUNWntpu packages from the ON consolidation and move them to the more appropriate SFW consolidation. In addition to the replacements for the current deliverables, the packages will include man pages and HTML documentation. While not 100% backwards compatible, the incompatibilities in the configuration file are mostly semantic in nature rather than syntatic, with the only major exceptions being in Sun added features, which we will not be adding. However, because of the popularity of the "slewalways" feature, the startup method will detect the presence of this Sun added keyword and configure the NTP daemon to use the NTP version 4 equivalent. The NTP community project, while not having an explicit requirement for backwards compatibility, in 11 years of development, including a full re-write of the configuration code, has had no major incompatibilities were introduced. The NTP community is very receptive to contributed code and integration of features needed by Solaris. I am a committer on the NTP project and I expect to work with the community to push all fixes and changes back into the community codebase. While the man pages are derived from the HTML documentation, they are specific to these deliverables and as far as possible complete and accurate regarding them. The HTML documenation, is delivered "as is" and may or may not reflect the deliverables. A notice to this effect is included in the man pages. This work is being sponsored by chris.armes@sun.com. This project seeks a minor release binding. This project supercedes PSARC 2001/162, which should considered withdrawn. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From brian.utterback@sun.com Fri Apr 17 10:26:40 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HHQeMc011653 for ; Fri, 17 Apr 2009 10:26:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3HHQeuX010029 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 17 Apr 2009 10:26:40 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900L0D9SGSX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 10:26:40 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI900LOO9SE0F10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 10:26:39 -0700 (PDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HHQa6a031081; Fri, 17 Apr 2009 13:26:37 -0400 (EDT) Date: Fri, 17 Apr 2009 13:26:36 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> To: Brian Utterback Cc: PSARC-ext@sun.com Message-id: <49E8BBCC.2090005@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_tfq+29d7LJLDxcEUwsbHKw)" X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 17130 This is a multi-part message in MIME format. --Boundary_(ID_tfq+29d7LJLDxcEUwsbHKw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I am submitting this case on my own behalf. The timer is set to expire on April 23rd. Man pages and the manifest are in the materials directory under the case directory. I am enclosing the FOSS checklist and a new proposal file with typos corrected. -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom --Boundary_(ID_tfq+29d7LJLDxcEUwsbHKw) Content-type: text/plain; name=FOSS_Checklist.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=FOSS_Checklist.txt 1.0 Project Information 1.1 Name of project/component Upgrade NTP to version 4 1.2 Author of document brian.utterback@sun.com 2.0 Project Summary 2.1 Project Description Replace the existing NTP version 3 with version 4. 2.2 Release binding What is is the release binding? (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) [ ] Major [x] Minor [ ] Patch or Micro [ ] Unknown -- ARC review required 2.3 Type of project Is this case a Linux Familiarity project? [x] Yes [ ] No 2.4 Originating Community 2.4.1 Community Name NTP.org 2.4.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [x] Contributor [ ] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [x] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [x] No 3.0 Technical Description 3.1 Installation & Sharable 3.1.1S Solaris Installation - section only required for Solaris Software (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details) Does this project follow the Install Locations best practice? [x] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [x] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [x] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [x] No or N/A Do any of the components of this project conflict with anything under /usr? (see http://opensolaris.org/os/community/arc/caselog/2007/047/ for details) [ ] Yes - explain below [x] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [x] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [x] No 3.1.2 Share and Sharable Does the module include any components that are used or shared by other projects? [ ] Yes [x] No If yes are these components packaged to be shared with the other FOSS? [ ] Yes [ ] No - ARC review required [x] N/A 3.2 Exported Libraries Are libraries being delivered by this project? [ ] Yes [x] No - continue with next section (section 3.3) 3.3 Services and the /etc Directory (see http://opensolaris.org/os/community/arc/policies/SMF-policy/) Does the project integrate anything into /etc/init.d or /etc/rc?.d? [ ] Yes - ARC review required [x] No Does the project integrate any new entries into /etc/inittab or /etc/inetd.conf? [ ] Yes - ARC review required [x] No Does the project integrate any private non-public files into /etc/default or /etc/ configuration files? [ ] Yes - ARC review required [x] No Does the service manifests method context grant rights above that of the noaccess user and basic privilege set? [ ] Yes - ARC review required [x] No 3.4 Security 3.4.1 Secure By Default (see http://opensolaris.org/os/community/arc/policies/secure-by-default/ for details) (see http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ for details) (see parts of http://opensolaris.org/os/community/arc/policies/SMF-policy/ for addtional details) Are there any network services provided by this project? [x] Yes [ ] No - continue with the next section (section 3.4.2) Are network services enabled by default? [ ] Yes - ARC review required [x] No [ ] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [x] No [ ] N/A Are inbound network communications denied by default? [x] Yes [ ] No - ARC review required [ ] N/A Is inbound data checked to prevent content-based attacks? [x] Yes [ ] No - ARC review required [ ] N/A Is the outbound receiver authenticated? [ ] Yes [ ] No - ARC review required [x] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [ ] Yes [ ] No - ARC review required [x] N/A 3.4.2 Authorization (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ and http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ for details) Are there any setuid/setgid privileged binaries in the project? [ ] Yes - ARC review required [x] No - continue with next section (section 3.4.3) 3.4.3 Auditing (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details) Does this component contain administrative or security enforcing software? [ ] Yes - ARC review required [x] No - continue to next section (section 3.4.4) 3.4.4 Authentication (see http://opensolaris.org/os/community/arc/policies/PAM/) Do the components contain any authentication code? [ ] Yes [x] No - continue to next section (section 3.4.5) 3.4.5 Passwords (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for details) Do any of the components for the project deal with passwords? [x] Yes [ ] No - continue to next section (section 3.4.6) If yes are these passwords entered via the CLI or environment? [ ] Yes - ARC review required [x] No Are passwords stored within the file system for the component? [x] Yes [ ] No - continue to next section (section 3.4.6) If yes are the permissions on the file such to protect exposing the password(s)? [x] Yes [ ] No - ARC review required The passwords are stored in the /etc/inet/ntp.keys file, which is not delivered. This file is administrator created. The passwords in question authenticate NTP servers and clients to one another and not individual users. It is up to the administrator to set permissions appropriately when the file is created. 3.4.6 General Security Questions (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details) Are there any network protocols used by this project? [x] Yes [ ] No - continue with the next section (section 3.5) Do the components use standard network protocols? [x] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [x] Yes - explain below [ ] No [ ] N/A Crypto authentication can used to verify the trust relationships between NTP servers and clients. Do the components make use of secret information during authentication and/or authorization? [x] Yes - explain below [ ] No [ ] N/A The high security crypto key options for authentication can be used to verify server identity. These require a public and private key pair generation in a manner analogous to the one used to identify systems by ssh. 3.5 Networking Do the components access the network? [x] Yes [ ] No - continue with the next section (section 3.6) If yes do the components support IPv6? [x] Yes [ ] No - ARC review required 3.6 Core Solaris Components Do the components of this project compete with or duplicate core Solaris components? [ ] Yes - ARC review required [x] No They replace current core components. 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces Interface Name Classification Comments --------------------------- ------------------- --------------------------- SUNWntpr Uncomitted Root package SUNWntpu Uncomitted /usr package /etc/inet/ntp.conf Uncomitted Configuration file /usr/lib/inet/ntpd Uncomitted NTP daemon /usr/lib/inet/ntp-wait Project Private /usr/sbin/ntpdate Volatile /usr/sbin/ntptrace Volatile /usr/sbin/ntpq Uncomitted /usr/sbin/ntpdc Volatile /usr/sbin/ntp-keygen Uncomitted Crypto key gen utility. /usr/sbin/ntptime Volatile Kernel NTP state utility. /usr/share/doc/ntp Uncommitted Location for html docs /usr/share/doc/ntp/* Volatile Contents of HTML docs. SMF properties config/debugfile Uncomitted config/debuglevel Uncomitted config/logfile Uncomitted config/no_auth_required Uncomitted Restores Solaris 9 default. config/slew_always Uncomitted Raises threshold for step. config/wait_for_sync Uncomitted Prevents method completion until sync. config/mdnsregister Uncomitted Registers server with mDNS config/verbose_logging Uncomitted 4.2 Imported Interfaces Interface Name Classification Comments ----------------------------------- ----------- -------------------------- /usr/lib/libdns_sd.so Committed /usr/sfw/lib/libcrypto.so Private Contracted svc:/network/dns/multicast:default Used to test if mDNS configured. ntp_adjtime,ntp_gettime syscalls Project Private Brief Interface Classifications - See Appendix C for definitions Volatile - interfaces are fluid and will follow a rapidly changing community Uncommitted - interfaces are still evolving in the community and might follow the community Committed - interfaces are stable in the community Project Private - no review required, just document in table Contracted (interface modifier) - further review required Appendix A - References 1. Solaris Installation Locations Policy http://opensolaris.org/os/community/arc/policies/install-locations/ 2. /usr/gnu Installation ARC case http://opensolaris.org/os/community/arc/caselog/2007/047/ 3. Secure By Default Policy http://opensolaris.org/os/community/arc/policies/secure-by-default/ 4. Network Install Time Securityuy Policy http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ 5. Adding RBAC Authorizations Policy http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/ 6. When to use setuid -vs- RBAC roles and profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and 7. Building RBAC Rights Profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ 8. Solaris Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ 9. Security questionaire http://opensolaris.org/os/community/arc/bestpractices/security-questions/ 10. Interface Taxonomy http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ 11. Plugable Authentication Modules -- PAM http://opensolaris.org/os/community/arc/policies/PAM/ 12. Reusable Passwords In Command Line Arguments and Environment Variables http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ 13. Storing Reusable Passwords on a Filesystem http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ 14. Release Taxonomy http://opensolaris.org/os/community/arc/policies/release-taxonomy/ 15. Service Management Facility (SMF) usage http://opensolaris.org/os/community/arc/policies/SMF-policy/ Appendix B - Suggested case materials 1. man pages 2. SMF manifests 3. links to contracts Appendix C - Definitions Submitter an agent responsible for creation of an ARC project along with the materials describing that project. Owner the ARC agent responsible for shepherding the case through review and ensuring a formal opinion is written where required. Maintainer an agent responsible for releasing new versions of a program, typically the "main" contributor or person incharge of making Architectural decisions for the project Contributor an agent who make contributions to a project, typically has a voice in making Architectural decisions for the project Monitoring an agent who is only following the changes made in the community and has no Architectural input into the project Volatile* interfaces that are very fluid and typically follow the originating community. Typically these interfaces can not be imported by other projects. Uncommitted* interfaces that are still evolving but will most likely be present from release to release. Committed* interfaces that are stable and with Sun guaranteeing some level of compatibility from release to release. Project Private* interfaces that are exposed only to or intended to be used only by the project being reviewed. These interfaces can not be imported by other projects. Not-An-Interface* components that are not interfaces. Contracted* (interface modifier) - ARC review of Contract required interfaces that do not allow another project to import can be *Note: see http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details --Boundary_(ID_tfq+29d7LJLDxcEUwsbHKw) Content-type: text/plain; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=proposal.txt Upgrade NTP to version 4. This project proposes to remove the current version 3.4 NTP deliverables and replace them with version 4.2.5. The current version in Solaris was released 11 years ago. The NTP project has continued to advance the code base for the entire time. This will be done by removing the current SUNWntpr and SUNWntpu packages from the ON consolidation and move them to the more appropriate SFW consolidation. In addition to the replacements for the current deliverables, the packages will include man pages and HTML documentation. While not 100% backwards compatible, the incompatibilities in the configuration file are mostly semantic in nature rather than syntactic, with the only major exceptions being in Sun added features, which we will not be adding. However, because of the popularity of the "slewalways" feature, the startup method will detect the presence of this Sun added keyword and configure the NTP daemon to use the NTP version 4 equivalent. The NTP community project, while not having an explicit requirement for backwards compatibility, in 11 years of development, including a full re-write of the configuration code, has had no major incompatibilities were introduced. The NTP community is very receptive to contributed code and integration of features needed by Solaris. I am a committer on the NTP project and I expect to work with the community to push all fixes and changes back into the community codebase. While the man pages are derived from the HTML documentation, they are specific to these deliverables and as far as possible complete and accurate regarding them. The HTML documentation, is delivered "as is" and may or may not reflect the deliverables. A notice to this effect is included in the man pages. This work is being sponsored by chris.armes@sun.com. This project seeks a minor release binding. This project supersedes PSARC 2001/162, which should considered withdrawn. --Boundary_(ID_tfq+29d7LJLDxcEUwsbHKw)-- From gdamore@sun.com Fri Apr 17 10:28:05 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HHS4sn011667 for ; Fri, 17 Apr 2009 10:28:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3HHS3ah012580 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 17 Apr 2009 10:28:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI90010P9US1A00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 10:28:04 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI900JJC9UR7250@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 10:28:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3HHS334003028 for ; Fri, 17 Apr 2009 10:28:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI900K009JS0C00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 10:28:03 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI900C9M9UQRO50@fe-sfbay-10.sun.com>; Fri, 17 Apr 2009 10:28:02 -0700 (PDT) Date: Fri, 17 Apr 2009 10:28:02 -0700 From: "Garrett D'Amore" Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Brian Utterback Cc: PSARC-ext@sun.com Message-id: <49E8BC22.3090405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3673 Sounds like this is a good way forward. I do have two questions though: 1) Synchronization with audio... you had told me at one point that one of the time sources was an audio source that emitted a tone at specific intervals -- such that accurate timing information was critical for you. Have you tested with Boomer? Will this project rely on, or make use of, the OSS API that is being integrated with Boomer? (PSARC 2008/318) 2) Suspend/resume interaction. One of the problems that we've been discussing lately is NTP getting out of sync on a resume event. How well does the new NTP code deal with this? There is SIGTHAW delivered on a resume, but you might not get it "right away" -- and SIGFREEZE is useless because you might not get that until *after* the system has resumed from a suspend cycle. Anyway, I'm interested to know what work has been done here, and what needs still to be done. I'm willing to help out, since I have similar issues for audio drivers, and I think Randy is willing to help as well. Thanks. -- Garrett Brian Utterback wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Upgrade NTP to Version 4 > 1.2. Name of Document Author/Supplier: > Author: Brian Utterback > 1.3 Date of This Document: > 17 April, 2009 > 4. Technical Description > Upgrade NTP to version 4. > > > This project proposes to remove the current version 3.4 NTP > deliverables and replace them with version 4.2.5. The current > version in Solaris was released 11 years ago. The NTP project > has continued to advance the code base for the entire time. > > This will be done by removing the current SUNWntpr and SUNWntpu > packages from the ON consolidation and move them to the more > appropriate SFW consolidation. In addition to the replacements > for the current deliverables, the packages will include man pages > and HTML documentation. > > While not 100% backwards compatible, the incompatibilities in the > configuration file are mostly semantic in nature rather than > syntatic, with the only major exceptions being in Sun added features, > which we will not be adding. However, because of the popularity of > the "slewalways" feature, the startup method will detect the > presence of this Sun added keyword and configure the NTP daemon to > use the NTP version 4 equivalent. > > The NTP community project, while not having an explicit requirement > for backwards compatibility, in 11 years > of development, including a full re-write of the configuration > code, has had no major incompatibilities were introduced. > > The NTP community is very receptive to contributed code and > integration of features needed by Solaris. I am a committer on > the NTP project and I expect to work with the community to > push all fixes and changes back into the community codebase. > > While the man pages are derived from the HTML documentation, they > are specific to these deliverables and as far as possible complete and > accurate regarding them. The HTML documenation, is delivered "as is" > and may or may not reflect the deliverables. A notice to this effect is > included in the man pages. > > This work is being sponsored by chris.armes@sun.com. > > This project seeks a minor release binding. > > This project supercedes PSARC 2001/162, which should considered > withdrawn. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Nicolas.Williams@sun.com Fri Apr 17 10:42:56 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HHgt4l012551 for ; Fri, 17 Apr 2009 10:42:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3HHgsEp018173; Fri, 17 Apr 2009 10:42:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900919AJH2100@brm-avmta-1.central.sun.com>; Fri, 17 Apr 2009 11:42:53 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI9007LWAJGTZ00@brm-avmta-1.central.sun.com>; Fri, 17 Apr 2009 11:42:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3HHetSV013062; Fri, 17 Apr 2009 12:40:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3HHetoH013061; Fri, 17 Apr 2009 12:40:55 -0500 (CDT) Date: Fri, 17 Apr 2009 12:40:55 -0500 From: Nicolas Williams Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49E8BBCC.2090005@sun.com> To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <20090417174055.GN1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2176 On Fri, Apr 17, 2009 at 01:26:36PM -0400, Brian Utterback wrote: > 4.1 Exported Interfaces > > Interface Name Classification Comments > --------------------------- ------------------- --------------------------- > SUNWntpr Uncomitted Root package > SUNWntpu Uncomitted /usr package > /etc/inet/ntp.conf Uncomitted Configuration file The configuration file format is Uncommitted, right? Also, you mentioned some incompatible changes. Can you list them all? Will a follow on project move more of the configuration into SMF service properties? > /usr/lib/inet/ntpd Uncomitted NTP daemon > /usr/lib/inet/ntp-wait Project Private > /usr/sbin/ntpdate Volatile The manpages for NTP in Solaris now don't state interface stability. But it seems to me that it's all as if Committed. ntpdate(1M) in particular is quite useful, though I see that its main use is being subsumed into the ntp service via the config/wait_for_sync property, I think. Also, why would ntpd have a stronger commitment than ntpdate? > /usr/sbin/ntptrace Volatile > /usr/sbin/ntpq Uncomitted > /usr/sbin/ntpdc Volatile Will there be a link for 'xntpdc'? Or does that just go away? > /usr/sbin/ntp-keygen Uncomitted Crypto key gen utility. > /usr/sbin/ntptime Volatile Kernel NTP state utility. > /usr/share/doc/ntp Uncommitted Location for html docs > /usr/share/doc/ntp/* Volatile Contents of HTML docs. > SMF properties > config/debugfile Uncomitted > config/debuglevel Uncomitted > config/logfile Uncomitted > config/no_auth_required Uncomitted Restores Solaris 9 default. > config/slew_always Uncomitted Raises threshold for step. > config/wait_for_sync Uncomitted Prevents method completion until sync. > config/mdnsregister Uncomitted Registers server with mDNS > config/verbose_logging Uncomitted I wonder if it wouldn't be better to have a separate SMF service for doing an ntpdate early at boot time (say, svc:/network/ntpdate:default), with svc:/network/ntp:default having an optional dependency on the former. Nico -- From brian.utterback@sun.com Fri Apr 17 11:48:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HImpG3015094 for ; Fri, 17 Apr 2009 11:48:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HImk4R011785 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 17 Apr 2009 19:48:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900905DLD4500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 11:48:49 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI90092ODLC1Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 11:48:49 -0700 (PDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HImlZL006317; Fri, 17 Apr 2009 14:48:47 -0400 (EDT) Date: Fri, 17 Apr 2009 14:48:43 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <20090417174055.GN1500@Sun.COM> To: Nicolas Williams Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49E8CF0B.4000505@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_M5yvSHBkHO5QMEd3MD0rnw)" X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <20090417174055.GN1500@Sun.COM> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 3807 This is a multi-part message in MIME format. --Boundary_(ID_M5yvSHBkHO5QMEd3MD0rnw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Nicolas Williams wrote: > > you > mentioned some incompatible changes. Can you list them all? To answer this, please find enclosed a list of all the incompatibilities I know of. -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom --Boundary_(ID_M5yvSHBkHO5QMEd3MD0rnw) Content-type: text/plain; name=incompat Content-transfer-encoding: 7BIT Content-disposition: inline; filename=incompat ntpd incompatibilites 1. The Sun added slewalways option is not present. The startup method detects the presence of this option and will automatically set the command line option "--slew" with is the closest approximation. This option does not provide a true "slewalways" feature. Instead it increases the threshold at which a step is done. It also automatically disables the kernel PLL, which we always required when slewalways was used, but since it was a separate step, it was prone to operator error. The default threshold with this option is 600 seconds, and is tunable in the configuration file. Since 600 seconds would take 14 days to slew, this is already a very high upper bound. 2. The default is to require authentication (keys) of broadcast, multicast and active peer servers. This makes using these modes more difficult since the keys must be set up, but allowing unsolicited anonymous servers to influence your clock is highly dangerous. Because of the danger, the default was changed in Solaris 10, so this is not really incompatible with the current version. We mitigate this by providing a settable SMF property to turn this requirement off. It can also be changed by placing "disable auth" in the configuration file. 2. The method to disable the kernel phase-locked-loop has been changed from "disable pll" to "disable kernel". 3. The keyword "pps" to disable/enable was removed. This is now controled at the "server" keyword lines. 4. The "noserve" restriction was made more strict. Previously, a noserve client could be used as a peer and time served to us, even though we would not serve time to him. In the new version, time is prevented from flowing either way. 5. The "donttrust" restriction was loosened. In the previous version, we woiuld never trust the host. In the new version, the host is trusted if there are valid authentication keys with the request. In other words, it amounts to a "check id" option. 6. Clock types 2(TRAK), 15(TRUE), 23(PTB), 24(USNO) and 25(TRUE) are no longer available. However, all of these clock types were retired because support for their corresponding hardware was folded into other clock types. 7. The "authentication (yes|no)" keyword line was dropped in favor of the already present "enable/disable auth" form. 8. The "precision" keyword line was dropped because ntpd now detects the precision automatically. 9. The clientlimit and clientperiod keyword lines were dropped because the system that rate limits clients was changed to work without these settings. 10. The tickadj keywork line was dropped. The value is now read directly from the kernel. ntpdate incompatibilities. 1. The Sun added "-m" option to use mutlicast servers in the ntpdate call is not present. Also the names xntpdc and xntpd were replaced with ntpdc and ntpd. --Boundary_(ID_M5yvSHBkHO5QMEd3MD0rnw)-- From brian.utterback@sun.com Fri Apr 17 12:07:54 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HJ7rHJ021121 for ; Fri, 17 Apr 2009 12:07:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HJ7jdD023638 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 17 Apr 2009 20:07:52 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900H0FEH4RE00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 13:07:52 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI9007T9EH3UA50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 17 Apr 2009 13:07:51 -0600 (MDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HJ7oIu015443; Fri, 17 Apr 2009 15:07:50 -0400 (EDT) Date: Fri, 17 Apr 2009 15:07:44 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <20090417174055.GN1500@Sun.COM> To: Nicolas Williams Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49E8D380.8050500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <20090417174055.GN1500@Sun.COM> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 4818 Comments inline. Nicolas Williams wrote: > On Fri, Apr 17, 2009 at 01:26:36PM -0400, Brian Utterback wrote: >> 4.1 Exported Interfaces >> >> Interface Name Classification Comments >> --------------------------- ------------------- --------------------------- >> SUNWntpr Uncomitted Root package >> SUNWntpu Uncomitted /usr package >> /etc/inet/ntp.conf Uncomitted Configuration file > > The configuration file format is Uncommitted, right? Also, you > mentioned some incompatible changes. Can you list them all? Will a > follow on project move more of the configuration into SMF service > properties? I have no plans to do so, but I am open to this. Certainly any that make sense can be added. However, the configuration file has many more options available than the commandline, so it might be difficult. > >> /usr/lib/inet/ntpd Uncomitted NTP daemon >> /usr/lib/inet/ntp-wait Project Private >> /usr/sbin/ntpdate Volatile > > The manpages for NTP in Solaris now don't state interface stability. I thought that they should. If that is not the convention, then I can remove them. > > But it seems to me that it's all as if Committed. ntpdate(1M) in > particular is quite useful, though I see that its main use is being > subsumed into the ntp service via the config/wait_for_sync property, I > think. Correct, we have treated them as being largely committed. I don't expect this to change, per se, but since I intend to track the community, I didn't want to formally lock in. In particular, several of the existing commands are deprecated by the NTP project and may be removed at a future date. These are ntpdate and ntpdc. The functionality of ntpdate is being subsumed by ntpd itself, which now has a "ntpdate" mode. This mode is not a complete replacement yet, but that is the goal. Until then, ntpdate will continue to be delivered. Also, the ntpdc (xntpdc) command is likewise having its feature set folded into the ntpq command. Not all the functions are there yet, but again, that is the goal. The ntpdate program is no longer called from the service startup method. The ntpdate program, while useful was also a bit of a security hole. It does not support most of the newer authentication methods added in version 4, and it is very susceptible to getting the wrong time from a single bad server. The ntpd program has a mode that allows it to correct a very large offset once at startup just as ntpdate always does. Plus, the new iburst option to the server line allows ntpd to synchronize in seconds (like ntpdate) instead of the 5 minutes it used to require. These two features make the use of ntpdate during startup unnecessary. > > Also, why would ntpd have a stronger commitment than ntpdate? See the above. > >> /usr/sbin/ntptrace Volatile >> /usr/sbin/ntpq Uncomitted >> /usr/sbin/ntpdc Volatile > > Will there be a link for 'xntpdc'? Or does that just go away? We could, but it would be simpler to have it just "go away" since that is what the community delivers now, and has for 11 years. > >> /usr/sbin/ntp-keygen Uncomitted Crypto key gen utility. >> /usr/sbin/ntptime Volatile Kernel NTP state utility. >> /usr/share/doc/ntp Uncommitted Location for html docs >> /usr/share/doc/ntp/* Volatile Contents of HTML docs. >> SMF properties >> config/debugfile Uncomitted >> config/debuglevel Uncomitted >> config/logfile Uncomitted >> config/no_auth_required Uncomitted Restores Solaris 9 default. >> config/slew_always Uncomitted Raises threshold for step. >> config/wait_for_sync Uncomitted Prevents method completion until sync. >> config/mdnsregister Uncomitted Registers server with mDNS >> config/verbose_logging Uncomitted > > I wonder if it wouldn't be better to have a separate SMF service for > doing an ntpdate early at boot time (say, svc:/network/ntpdate:default), > with svc:/network/ntp:default having an optional dependency on the > former. As I explained above, that is no longer necessary. In addition, the ntpd program now has a feature to retry hostname look-ups that fail during initialization, so the need to wait for the naming service is also no longer a problem. So, ntp can now start very early without difficulty. This will make interaction with Secure DNS easy. > > Nico -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From brian.utterback@sun.com Fri Apr 17 12:18:29 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HJITWA012029 for ; Fri, 17 Apr 2009 12:18:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3HJIRkp063422; Fri, 17 Apr 2009 13:18:28 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900C0FEYRUG00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Apr 2009 12:18:27 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI9009GSEYQ1Z20@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Apr 2009 12:18:27 -0700 (PDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HJIPOv020060; Fri, 17 Apr 2009 15:18:25 -0400 (EDT) Date: Fri, 17 Apr 2009 15:18:20 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49E8BC22.3090405@sun.com> To: "Garrett D'Amore" Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49E8D5FC.5040305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BC22.3090405@sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 5072 Garrett D'Amore wrote: > Sounds like this is a good way forward. I do have two questions though: > > 1) Synchronization with audio... you had told me at one point that one > of the time sources was an audio source that emitted a tone at specific > intervals -- such that accurate timing information was critical for > you. Have you tested with Boomer? Will this project rely on, or make > use of, the OSS API that is being integrated with Boomer? (PSARC 2008/318) Since there are now over 40 hardware clocks available and I have access to only a couple, I have not tested many. Support for individual clocks will be done with community involvement as problems are reported. The audio clock has been reported to be less than stellar anyway, which is something I would like to address eventually. In the meantime, I expect to address hardware refclock problems as they are reported. I have sanity checked the ones I do have access to to ensure that the basic clock/ntpd/kernel interfaces work. > > 2) Suspend/resume interaction. One of the problems that we've been > discussing lately is NTP getting out of sync on a resume event. How > well does the new NTP code deal with this? There is SIGTHAW delivered > on a resume, but you might not get it "right away" -- and SIGFREEZE is > useless because you might not get that until *after* the system has > resumed from a suspend cycle. Anyway, I'm interested to know what work > has been done here, and what needs still to be done. I'm willing to > help out, since I have similar issues for audio drivers, and I think > Randy is willing to help as well. I have not done any work on this. I only became aware of this issue this week. However, the problem exists in both the old and the new versions, so I don't view that as a problem for this case. Since you ask, it would seem that the best solution is to simply restart the ntp service. We can deal with this in the CR outside this case. > > Thanks. > > -- Garrett > > Brian Utterback wrote: >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Upgrade NTP to Version 4 >> 1.2. Name of Document Author/Supplier: >> Author: Brian Utterback >> 1.3 Date of This Document: >> 17 April, 2009 >> 4. Technical Description >> Upgrade NTP to version 4. >> >> >> This project proposes to remove the current version 3.4 NTP >> deliverables and replace them with version 4.2.5. The current >> version in Solaris was released 11 years ago. The NTP project >> has continued to advance the code base for the entire time. >> This will be done by removing the current SUNWntpr and SUNWntpu >> packages from the ON consolidation and move them to the more >> appropriate SFW consolidation. In addition to the replacements >> for the current deliverables, the packages will include man pages >> and HTML documentation. >> >> While not 100% backwards compatible, the incompatibilities in the >> configuration file are mostly semantic in nature rather than syntatic, >> with the only major exceptions being in Sun added features, which we >> will not be adding. However, because of the popularity of >> the "slewalways" feature, the startup method will detect the presence >> of this Sun added keyword and configure the NTP daemon to use the NTP >> version 4 equivalent. >> The NTP community project, while not having an explicit requirement >> for backwards compatibility, in 11 years of development, including a >> full re-write of the configuration >> code, has had no major incompatibilities were introduced. >> The NTP community is very receptive to contributed code and >> integration of features needed by Solaris. I am a committer on >> the NTP project and I expect to work with the community to push all >> fixes and changes back into the community codebase. >> >> While the man pages are derived from the HTML documentation, they >> are specific to these deliverables and as far as possible complete and >> accurate regarding them. The HTML documenation, is delivered "as is" >> and may or may not reflect the deliverables. A notice to this effect is >> included in the man pages. >> >> This work is being sponsored by chris.armes@sun.com. >> >> This project seeks a minor release binding. >> This project supercedes PSARC 2001/162, which should considered >> withdrawn. >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> SFW >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> > -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Nicolas.Williams@sun.com Fri Apr 17 12:19:55 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HJJs38012066 for ; Fri, 17 Apr 2009 12:19:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3HJJqje028997; Fri, 17 Apr 2009 12:19:53 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900D0RF120Z00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Apr 2009 12:19:50 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI9009L6F101Z20@nwk-avmta-1.sfbay.Sun.COM>; Fri, 17 Apr 2009 12:19:49 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3HJHoNV013121; Fri, 17 Apr 2009 14:17:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3HJHoxd013120; Fri, 17 Apr 2009 14:17:50 -0500 (CDT) Date: Fri, 17 Apr 2009 14:17:50 -0500 From: Nicolas Williams Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49E8D380.8050500@sun.com> To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <20090417191749.GQ1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <20090417174055.GN1500@Sun.COM> <49E8D380.8050500@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3242 On Fri, Apr 17, 2009 at 03:07:44PM -0400, Brian Utterback wrote: > >> /usr/lib/inet/ntpd Uncomitted NTP daemon > >> /usr/lib/inet/ntp-wait Project Private > >> /usr/sbin/ntpdate Volatile > > > >The manpages for NTP in Solaris now don't state interface stability. > > I thought that they should. If that is not the convention, then I can > remove them. What I meant is that I looked at ntpdate(1M) and no stability attribute was listed. Therefore I'd assume it should be Committed. > > > >But it seems to me that it's all as if Committed. ntpdate(1M) in > >particular is quite useful, though I see that its main use is being > >subsumed into the ntp service via the config/wait_for_sync property, I > >think. > > Correct, we have treated them as being largely committed. I don't > expect this to change, per se, but since I intend to track the > community, I didn't want to formally lock in. In particular, several > of the existing commands are deprecated by the NTP project and may be > removed at a future date. These are ntpdate and ntpdc. The > functionality of ntpdate is being subsumed by ntpd itself, which now > has a "ntpdate" mode. This mode is not a complete replacement yet, but > that is the goal. Until then, ntpdate will continue to be delivered. Oh, I see, ntpdate has been deprecated. The perhaps you should make it Committed Obsolete rather than Volatile. > Also, the ntpdc (xntpdc) command is likewise having its feature set > folded into the ntpq command. Not all the functions are there yet, but > again, that is the goal. See above. > The ntpdate program is no longer called from the service startup > method. The ntpdate program, while useful was also a bit of a security > hole. It does not support most of the newer authentication methods > added in version 4, and it is very susceptible to getting the wrong > time from a single bad server. The ntpd program has a mode that allows > it to correct a very large offset once at startup just as ntpdate > always does. Plus, the new iburst option to the server line allows > ntpd to synchronize in seconds (like ntpdate) instead of the 5 minutes > it used to require. These two features make the use of ntpdate during > startup unnecessary. Ah, excellent. Thanks. > >Will there be a link for 'xntpdc'? Or does that just go away? > > We could, but it would be simpler to have it just "go away" since that > is what the community delivers now, and has for 11 years. Doesn't that require starting the EOF process? Wouldn't it be easier to add a link and mark it Committed Obsolete? Or is xntpdc different from ntpdc? > >I wonder if it wouldn't be better to have a separate SMF service for > >doing an ntpdate early at boot time (say, svc:/network/ntpdate:default), > >with svc:/network/ntp:default having an optional dependency on the > >former. > > As I explained above, that is no longer necessary. In addition, the > ntpd program now has a feature to retry hostname look-ups that fail > during initialization, so the need to wait for the naming service is > also no longer a problem. So, ntp can now start very early without > difficulty. This will make interaction with Secure DNS easy. Right, thanks. Nico -- From Nicolas.Williams@sun.com Fri Apr 17 12:24:25 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HJOOrj012201 for ; Fri, 17 Apr 2009 12:24:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HJOMrM005167; Fri, 17 Apr 2009 20:24:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900805F8M1J00@nwk-avmta-2.sfbay.sun.com>; Fri, 17 Apr 2009 12:24:22 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI900JX9F8L75B0@nwk-avmta-2.sfbay.sun.com>; Fri, 17 Apr 2009 12:24:22 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3HJMNwc013127; Fri, 17 Apr 2009 14:22:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3HJMNpC013126; Fri, 17 Apr 2009 14:22:23 -0500 (CDT) Date: Fri, 17 Apr 2009 14:22:23 -0500 From: Nicolas Williams Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49E8CF0B.4000505@sun.com> To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <20090417192223.GR1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <20090417174055.GN1500@Sun.COM> <49E8CF0B.4000505@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 354 On Fri, Apr 17, 2009 at 02:48:43PM -0400, Brian Utterback wrote: > Nicolas Williams wrote: > >you > >mentioned some incompatible changes. Can you list them all? > > To answer this, please find enclosed a list of all the > incompatibilities I know of. How is upgrade handled? Are old configs re-written to the new style on service start? Nico -- From gdamore@sun.com Fri Apr 17 12:33:57 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HJXvlg012326 for ; Fri, 17 Apr 2009 12:33:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3HJXtSn006296 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 17 Apr 2009 13:33:56 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900K0HFOKJB00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 17 Apr 2009 13:33:56 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI90077VFOIUA70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 17 Apr 2009 13:33:55 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3HJXsjb018183 for ; Fri, 17 Apr 2009 12:33:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI900A00FLTWN00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 17 Apr 2009 12:33:54 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI900FNNFOI2I60@fe-sfbay-10.sun.com>; Fri, 17 Apr 2009 12:33:54 -0700 (PDT) Date: Fri, 17 Apr 2009 12:33:53 -0700 From: "Garrett D'Amore" Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49E8D5FC.5040305@sun.com> Sender: Garrett.Damore@sun.com To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49E8D9A1.3090001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BC22.3090405@sun.com> <49E8D5FC.5040305@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 5692 Brian Utterback wrote: > > > Garrett D'Amore wrote: >> Sounds like this is a good way forward. I do have two questions though: >> >> 1) Synchronization with audio... you had told me at one point that >> one of the time sources was an audio source that emitted a tone at >> specific intervals -- such that accurate timing information was >> critical for you. Have you tested with Boomer? Will this project >> rely on, or make use of, the OSS API that is being integrated with >> Boomer? (PSARC 2008/318) > > Since there are now over 40 hardware clocks available and I have > access to only a couple, I have not tested many. Support for > individual clocks will be done with community involvement as problems > are reported. The audio clock has been reported to be less than > stellar anyway, which is something I would like to address eventually. > In the meantime, I expect to address hardware refclock problems as > they are reported. I have sanity checked the ones I do have access to > to ensure that the basic clock/ntpd/kernel interfaces work. Ok, so I don't know what this means. Will the audio clock use OSS or Sun audio? The Sun audio probably has a *lot* more jitter (perhaps unacceptably large?) than the OSS API does. Since ntp *must* support the OSS audio device (if it wants to work with FreeBSD at least, which I believe it does), I'd like supporting Boomer to be a requirement for this case going forward. (Put another way, I don't want to have to deal with bugs from this project using the legacy Sun audio interfaces...) > >> >> 2) Suspend/resume interaction. One of the problems that we've been >> discussing lately is NTP getting out of sync on a resume event. How >> well does the new NTP code deal with this? There is SIGTHAW >> delivered on a resume, but you might not get it "right away" -- and >> SIGFREEZE is useless because you might not get that until *after* the >> system has resumed from a suspend cycle. Anyway, I'm interested to >> know what work has been done here, and what needs still to be done. >> I'm willing to help out, since I have similar issues for audio >> drivers, and I think Randy is willing to help as well. > > I have not done any work on this. I only became aware of this issue > this week. However, the problem exists in both the old and the new > versions, so I don't view that as a problem for this case. > > Since you ask, it would seem that the best solution is to simply > restart the ntp service. We can deal with this in the CR outside this > case. I'm not sure I agree that restart is the right thing -- rereading the configuration file etc. might have unanticipated side effects. What is necessary is to put the server into some kind of "get your clocks in order quickly, because they are probably wrong" mode. I agree that we can do this outside of the context of this case. - -Garrett > >> >> Thanks. >> >> -- Garrett >> >> Brian Utterback wrote: >>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >>> This information is Copyright 2009 Sun Microsystems >>> 1. Introduction >>> 1.1. Project/Component Working Name: >>> Upgrade NTP to Version 4 >>> 1.2. Name of Document Author/Supplier: >>> Author: Brian Utterback >>> 1.3 Date of This Document: >>> 17 April, 2009 >>> 4. Technical Description >>> Upgrade NTP to version 4. >>> >>> >>> This project proposes to remove the current version 3.4 NTP >>> deliverables and replace them with version 4.2.5. The current >>> version in Solaris was released 11 years ago. The NTP project >>> has continued to advance the code base for the entire time. >>> This will be done by removing the current SUNWntpr and SUNWntpu >>> packages from the ON consolidation and move them to the more >>> appropriate SFW consolidation. In addition to the replacements >>> for the current deliverables, the packages will include man pages >>> and HTML documentation. >>> >>> While not 100% backwards compatible, the incompatibilities in the >>> configuration file are mostly semantic in nature rather than >>> syntatic, with the only major exceptions being in Sun added >>> features, which we will not be adding. However, because of the >>> popularity of >>> the "slewalways" feature, the startup method will detect the >>> presence of this Sun added keyword and configure the NTP daemon to >>> use the NTP version 4 equivalent. The NTP community project, while >>> not having an explicit requirement >>> for backwards compatibility, in 11 years of development, including a >>> full re-write of the configuration >>> code, has had no major incompatibilities were introduced. >>> The NTP community is very receptive to contributed code and >>> integration of features needed by Solaris. I am a committer on >>> the NTP project and I expect to work with the community to push all >>> fixes and changes back into the community codebase. >>> >>> While the man pages are derived from the HTML documentation, they >>> are specific to these deliverables and as far as possible complete and >>> accurate regarding them. The HTML documenation, is delivered "as is" >>> and may or may not reflect the deliverables. A notice to this effect is >>> included in the man pages. >>> >>> This work is being sponsored by chris.armes@sun.com. >>> >>> This project seeks a minor release binding. >>> This project supercedes PSARC 2001/162, which should considered >>> withdrawn. >>> >>> 6. Resources and Schedule >>> 6.4. Steering Committee requested information >>> 6.4.1. Consolidation C-team Name: >>> SFW >>> 6.5. ARC review type: FastTrack >>> 6.6. ARC Exposure: open >>> >>> >> > From brian.utterback@sun.com Mon Apr 20 13:37:57 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KKbvEs027505 for ; Mon, 20 Apr 2009 13:37:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KKbtPm036577; Mon, 20 Apr 2009 14:37:56 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIF00I0R2N6M500@brm-avmta-1.central.sun.com>; Mon, 20 Apr 2009 14:37:54 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIF00DV52N56H50@brm-avmta-1.central.sun.com>; Mon, 20 Apr 2009 14:37:54 -0600 (MDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3KKbqH1044265; Mon, 20 Apr 2009 16:37:52 -0400 (EDT) Date: Mon, 20 Apr 2009 16:37:47 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49E8D9A1.3090001@sun.com> To: "Garrett D'Amore" Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49ECDD1B.8070308@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BC22.3090405@sun.com> <49E8D5FC.5040305@sun.com> <49E8D9A1.3090001@sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 1871 Garrett D'Amore wrote: > Ok, so I don't know what this means. Will the audio clock use OSS or > Sun audio? The Sun audio probably has a *lot* more jitter (perhaps > unacceptably large?) than the OSS API does. Since ntp *must* support > the OSS audio device (if it wants to work with FreeBSD at least, which I > believe it does), I'd like supporting Boomer to be a requirement for > this case going forward. (Put another way, I don't want to have to deal > with bugs from this project using the legacy Sun audio interfaces...) What would you find acceptable? I can see that there are in fact three refclock drivers that read audio data and decode it. All three use /dev/audio as the default device. All three have the ability to override this. I installed RC3 of boomer and /dev/audio is a symlink to /dev/sound/0, so it would appear that things that open /dev/audio should still work anyway, no? Do you want these drivers to do something different for Boomer? As a NTP committer, I can pretty much guarantee that we will not treat any issues with audio post-Boomer integration as a Sun bug unless it is also a bug in Boomer. That is, if these drivers fail using Boomer when they worked on Sun Audio, then we will treat that as a NTP bug until we can all agree that it is correctly using the Boomer API. To the point, we can commit that we will not ask you to support legacy Sun Audio interfaces usage in NTP on platforms with OSS installed. Is that good enough? -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From gdamore@sun.com Mon Apr 20 13:48:28 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KKmRKo027705 for ; Mon, 20 Apr 2009 13:48:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3KKmIIf028006 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 21 Apr 2009 04:48:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIF00E0134QFC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 13:48:26 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIF00A9S34PXX40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 13:48:25 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KKmPDS004495 for ; Mon, 20 Apr 2009 13:48:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIF00E0030EL400@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 20 Apr 2009 13:48:25 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIF00EBJ34O9WE0@fe-sfbay-09.sun.com>; Mon, 20 Apr 2009 13:48:24 -0700 (PDT) Date: Mon, 20 Apr 2009 13:48:24 -0700 From: "Garrett D'Amore" Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49ECDD1B.8070308@sun.com> Sender: Garrett.Damore@sun.com To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49ECDF98.1080505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BC22.3090405@sun.com> <49E8D5FC.5040305@sun.com> <49E8D9A1.3090001@sun.com> <49ECDD1B.8070308@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1811 Brian Utterback wrote: > > > Garrett D'Amore wrote: > >> Ok, so I don't know what this means. Will the audio clock use OSS or >> Sun audio? The Sun audio probably has a *lot* more jitter (perhaps >> unacceptably large?) than the OSS API does. Since ntp *must* support >> the OSS audio device (if it wants to work with FreeBSD at least, >> which I believe it does), I'd like supporting Boomer to be a >> requirement for this case going forward. (Put another way, I don't >> want to have to deal with bugs from this project using the legacy Sun >> audio interfaces...) > > What would you find acceptable? I can see that there are in fact three > refclock drivers that read audio data and decode it. All three use > /dev/audio as the default device. All three have the ability to > override this. I installed RC3 of boomer and /dev/audio is a symlink > to /dev/sound/0, so it would appear that things that open /dev/audio > should still work anyway, no? Yes, although I don't necessarily guarantee that you'll still get these as low latency items. > > Do you want these drivers to do something different for Boomer? As a > NTP committer, I can pretty much guarantee that we will not treat any > issues with audio post-Boomer integration as a Sun bug unless it is > also a bug in Boomer. That is, if these drivers fail using Boomer when > they worked on Sun Audio, then we will treat that as a NTP bug until > we can all agree that it is correctly using the Boomer API. Ok. > > To the point, we can commit that we will not ask you to support legacy > Sun Audio interfaces usage in NTP on platforms with OSS installed. Is > that good enough? Yes. :-) Thanks. (I'd recommend building/delivering with OSS API enabled by default, to get the best latency/jitter possible.) - Garrett From brian.utterback@sun.com Tue Apr 21 09:16:16 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LGGFfr002744 for ; Tue, 21 Apr 2009 09:16:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3LGG6Mu008790 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Apr 2009 00:16:13 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIG00157L6Z8400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Apr 2009 10:16:11 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIG000N9L6XO000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Apr 2009 10:16:09 -0600 (MDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LGG7mm020672; Tue, 21 Apr 2009 12:16:07 -0400 (EDT) Date: Tue, 21 Apr 2009 12:16:02 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <20090417192223.GR1500@Sun.COM> To: Nicolas Williams Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49EDF142.4090406@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <20090417174055.GN1500@Sun.COM> <49E8CF0B.4000505@sun.com> <20090417192223.GR1500@Sun.COM> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 2072 Nicolas Williams wrote: > On Fri, Apr 17, 2009 at 02:48:43PM -0400, Brian Utterback wrote: >> Nicolas Williams wrote: >>> you >>> mentioned some incompatible changes. Can you list them all? >> To answer this, please find enclosed a list of all the >> incompatibilities I know of. > > How is upgrade handled? Are old configs re-written to the new style on > service start? No. Because of the fact that the ntp.conf file is almost completely backwards compatible, we will not attempt to re-write the files. At your request, I have added a check for the obsolete "authentication no" configuration line, and if found will disable the authentication requirement. The only reason to use "disable pll" was to get the slewalways option to work. Since the --slew option now automatically sets the kernel loop to disable, the "disable pll" option can safely be ignored. The "enable/disable pps" option is really never used, since it implies that a hardware refclock is in use (which cuts the percentage down to a very small number right there) and that the PPS signal is wired (still smaller) and that the customer has gone to that trouble and now does not want to use it (I'd be surprised if we hear from even one). To answer your questions in another leaf of this thread, I would prefer "Uncommitted Obsolete" for ntpdc and ntpdate rather than "Committed Obsolete". I would like the possibility of removing them someday, when the NTP distro drops them. It would be most difficult to upgrade later if we needed to deliver something that isn't in the distro. If you really want a link from xntpdc to ntpdc, I am okay with that. Does anybody besides Nico like that idea? -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Nicolas.Williams@sun.com Tue Apr 21 09:24:19 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LGOI4N003035 for ; Tue, 21 Apr 2009 09:24:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LGO5ka023606; Tue, 21 Apr 2009 17:24:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIG00H17LKGK500@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Apr 2009 09:24:16 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIG00902LKFETF0@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Apr 2009 09:24:15 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3LGMF0D015199; Tue, 21 Apr 2009 11:22:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3LGMFpL015198; Tue, 21 Apr 2009 11:22:15 -0500 (CDT) Date: Tue, 21 Apr 2009 11:22:15 -0500 From: Nicolas Williams Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49EDF142.4090406@sun.com> To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <20090421162215.GM1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <20090417174055.GN1500@Sun.COM> <49E8CF0B.4000505@sun.com> <20090417192223.GR1500@Sun.COM> <49EDF142.4090406@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1921 On Tue, Apr 21, 2009 at 12:16:02PM -0400, Brian Utterback wrote: > >How is upgrade handled? Are old configs re-written to the new style on > >service start? > > No. Because of the fact that the ntp.conf file is almost completely > backwards compatible, we will not attempt to re-write the files. At > your request, I have added a check for the obsolete "authentication > no" configuration line, and if found will disable the authentication > requirement. On re-review that seems reasonable. What happens if a user's ntp.conf uses removed keywords? Will the service end up in maintenance mode? Or will there be but a warning in the service log file (and/or syslog)? > The "enable/disable pps" option is really never used, since it implies > that a hardware refclock is in use (which cuts the percentage down to > a very small number right there) and that the PPS signal is wired > (still smaller) and that the customer has gone to that trouble and now > does not want to use it (I'd be surprised if we hear from even one). I can certainly imagine "enable pps" being used because I've seen it... But it's almost certainly exceedingly rare too (the rig I saw using it required some homemade circuitry). > To answer your questions in another leaf of this thread, I would > prefer "Uncommitted Obsolete" for ntpdc and ntpdate rather than > "Committed Obsolete". I would like the possibility of removing them > someday, when the NTP distro drops them. It would be most difficult to > upgrade later if we needed to deliver something that isn't in the distro. Sure. Obsolete is fine for these, and Uncommitted is fine too AFAIAC (but IANAAM). > If you really want a link from xntpdc to ntpdc, I am okay with that. > Does anybody besides Nico like that idea? IMO the link costs nothing, but I don't care that much. Might anyone have written scripts based on xntpdc? I might have in my sysadmin past... From brian.utterback@sun.com Tue Apr 21 12:42:43 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LJghOG006197 for ; Tue, 21 Apr 2009 12:42:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3LJggwh017201 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 21 Apr 2009 12:42:43 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIG0050HUR7H400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Apr 2009 12:42:43 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIG00IQ7UR6T5E0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Apr 2009 12:42:43 -0700 (PDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LJgfel000510; Tue, 21 Apr 2009 15:42:41 -0400 (EDT) Date: Tue, 21 Apr 2009 15:42:37 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <20090421162215.GM1500@Sun.COM> To: Nicolas Williams Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49EE21AD.4070807@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <20090417174055.GN1500@Sun.COM> <49E8CF0B.4000505@sun.com> <20090417192223.GR1500@Sun.COM> <49EDF142.4090406@sun.com> <20090421162215.GM1500@Sun.COM> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 1134 Nicolas Williams wrote: > On re-review that seems reasonable. What happens if a user's ntp.conf > uses removed keywords? Will the service end up in maintenance mode? Or > will there be but a warning in the service log file (and/or syslog)? In all cases the ntpd will complain about the invalid keywords with an entry in the messages file, but it just ignores the line and goes on, so no maintenance mode. And for the slewalways and authentication keywords it will obey them anyway via the checking in the startup method we have been discussing. > IMO the link costs nothing, but I don't care that much. Might anyone > have written scripts based on xntpdc? I might have in my sysadmin > past... Distinctly possible. I'll put in the link. -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From glenn.skinner@sun.com Tue Apr 21 12:57:44 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LJvitR007085 for ; Tue, 21 Apr 2009 12:57:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3LJveFh025138 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Apr 2009 03:57:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIG00307VG6PL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Apr 2009 12:57:42 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIG00A7ZVG5NPF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Apr 2009 12:57:41 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id n3LJvflT016864; Tue, 21 Apr 2009 12:57:41 -0700 (PDT) Date: Tue, 21 Apr 2009 12:57:41 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/244 [Upgrade NTP to Version 4] To: PSARC-ext@sun.com, blu@sac.sfbay.sun.com Reply-to: Glenn Skinner Message-id: <200904211957.n3LJvflT016864@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: lyLxEawOwc/ZrvzN0EUuAw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 397 Date: Fri, 17 Apr 2009 10:19:00 -0700 (PDT) From: Brian Utterback Subject: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] ... This project supercedes PSARC 2001/162, which should considered withdrawn. I went looking for this case and couldn't find it. Is there a typo in the case number mentioned above? -- Glenn From brian.utterback@sun.com Tue Apr 21 16:27:16 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LNRFsQ009478 for ; Tue, 21 Apr 2009 16:27:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LNRApe023238 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Apr 2009 00:27:15 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIH00I0L55DGK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Apr 2009 16:27:13 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIH0062655CGJC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 21 Apr 2009 16:27:12 -0700 (PDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3LNRAfA041239; Tue, 21 Apr 2009 19:27:10 -0400 (EDT) Date: Tue, 21 Apr 2009 19:27:05 -0400 From: Brian Utterback Subject: Re: 2009/244 [Upgrade NTP to Version 4] In-reply-to: <200904211957.n3LJvflT016864@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: PSARC-ext@sun.com, blu@sac.sfbay.sun.com Message-id: <49EE5649.5060402@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904211957.n3LJvflT016864@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 966 No, that's not a typo. That case is apparently in the DB but does not have a case directory. I have absolutely no idea how to update it. Glenn Skinner wrote: > Date: Fri, 17 Apr 2009 10:19:00 -0700 (PDT) > From: Brian Utterback > Subject: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack > timeout 04/23/2009] > > ... > This project supercedes PSARC 2001/162, which should considered > withdrawn. > > I went looking for this case and couldn't find it. Is there a typo in > the case number mentioned above? > > -- Glenn > -- blu "You would think that spies would have to be light sleepers, but that isn't true. For instance, James Bond once slept through an earthquake. That's right, he was shaken but not stirred." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From glenn.skinner@sun.com Wed Apr 22 11:45:41 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3MIjfpn023169 for ; Wed, 22 Apr 2009 11:45:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3MIjcUP023765; Wed, 22 Apr 2009 11:45:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KII00M1ZMS3KI00@brm-avmta-1.central.sun.com>; Wed, 22 Apr 2009 12:45:39 -0600 (MDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KII006Q7MS2N9E0@brm-avmta-1.central.sun.com>; Wed, 22 Apr 2009 12:45:39 -0600 (MDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id n3MIjcmn018485; Wed, 22 Apr 2009 11:45:38 -0700 (PDT) Date: Wed, 22 Apr 2009 11:45:38 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/244 [Upgrade NTP to Version 4] To: brian.utterback@sun.com Cc: PSARC-ext@sun.com Reply-to: Glenn Skinner Message-id: <200904221845.n3MIjcmn018485@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: sI51qnoZJ/IhyN5WJrILtw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 950 Date: Tue, 21 Apr 2009 19:27:05 -0400 From: Brian Utterback Subject: Re: 2009/244 [Upgrade NTP to Version 4] No, that's not a typo. That case is apparently in the DB but does not have a case directory. I have absolutely no idea how to update it. Glenn Skinner wrote: > Date: Fri, 17 Apr 2009 10:19:00 -0700 (PDT) > From: Brian Utterback > Subject: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack > timeout 04/23/2009] > > ... > This project supercedes PSARC 2001/162, which should considered > withdrawn. > > I went looking for this case and couldn't find it. Is there a typo in > the case number mentioned above? I've created a skeleton case directory for 2001/162 [Upgrade Solaris to NTPv4] and marked the status field in its IAM file to note that this case supercedes it. -- Glenn From brian.utterback@sun.com Wed Apr 22 12:06:28 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3MJ6RCh016245 for ; Wed, 22 Apr 2009 12:06:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3MJ6QF8042428 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 22 Apr 2009 13:06:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KII00K05NQQ0900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 12:06:26 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KII00JZONQOKD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 22 Apr 2009 12:06:25 -0700 (PDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3MJ6Nuc034911; Wed, 22 Apr 2009 15:06:23 -0400 (EDT) Date: Wed, 22 Apr 2009 15:06:23 -0400 From: Brian Utterback Subject: Re: 2009/244 [Upgrade NTP to Version 4] In-reply-to: <200904221845.n3MIjcmn018485@ivrel.sfbay.sun.com> To: Glenn Skinner Cc: PSARC-ext@sun.com Message-id: <49EF6AAF.8040902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904221845.n3MIjcmn018485@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090304) Status: RO Content-Length: 1288 Thanks, Glenn. Glenn Skinner wrote: > Date: Tue, 21 Apr 2009 19:27:05 -0400 > From: Brian Utterback > Subject: Re: 2009/244 [Upgrade NTP to Version 4] > > No, that's not a typo. That case is apparently in the DB but does > not have a case directory. I have absolutely no idea how to > update it. > > Glenn Skinner wrote: > > Date: Fri, 17 Apr 2009 10:19:00 -0700 (PDT) > > From: Brian Utterback > > Subject: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack > > timeout 04/23/2009] > > > > ... > > This project supercedes PSARC 2001/162, which should considered > > withdrawn. > > > > I went looking for this case and couldn't find it. Is there a typo in > > the case number mentioned above? > > I've created a skeleton case directory for 2001/162 [Upgrade Solaris to > NTPv4] and marked the status field in its IAM file to note that this > case supercedes it. > > -- Glenn > -- blu "Mark my words, nanotechnology is going to be huge!" ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Nicolas.Williams@sun.com Wed Apr 22 13:55:42 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3MKtfRo022588 for ; Wed, 22 Apr 2009 13:55:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3MKtVXC023719; Thu, 23 Apr 2009 04:55:38 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KII0030BSSP5D00@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Apr 2009 13:55:37 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KII00JYFSSOK980@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Apr 2009 13:55:36 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3MKra8D016401; Wed, 22 Apr 2009 15:53:36 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3MKras2016400; Wed, 22 Apr 2009 15:53:36 -0500 (CDT) Date: Wed, 22 Apr 2009 15:53:36 -0500 From: Nicolas Williams Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49E8D380.8050500@sun.com> To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <20090422205336.GY1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <20090417174055.GN1500@Sun.COM> <49E8D380.8050500@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1161 On Fri, Apr 17, 2009 at 03:07:44PM -0400, Brian Utterback wrote: > Nicolas Williams wrote: > >I wonder if it wouldn't be better to have a separate SMF service for > >doing an ntpdate early at boot time (say, svc:/network/ntpdate:default), > >with svc:/network/ntp:default having an optional dependency on the > >former. > > As I explained above, that is no longer necessary. In addition, the > ntpd program now has a feature to retry hostname look-ups that fail > during initialization, so the need to wait for the naming service is > also no longer a problem. So, ntp can now start very early without > difficulty. This will make interaction with Secure DNS easy. Looking at the NTP docs, I see that there's a pair of ntpd options that can be used to do what ntpdate does: -g and -q. I think it would be useful to have a property to cause the clock to be set quickly at startup time -- separately from the option to wait for time to synchronize. Also, during the code review I noticed that you set the start method timeout to 1800 seconds. Clearly that's too large if time will be set quickly (ntpd -gq ...) first, but just right otherwise. Nico -- From brian.utterback@sun.com Fri Apr 24 07:43:19 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OEhJ9t027557 for ; Fri, 24 Apr 2009 07:43:19 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3OEhI97020999 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Apr 2009 07:43:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM00K010W6Y200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Apr 2009 08:43:18 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00BD50W52F60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Apr 2009 08:43:18 -0600 (MDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3OEhGuR014884; Fri, 24 Apr 2009 10:43:16 -0400 (EDT) Date: Fri, 24 Apr 2009 10:43:11 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> To: Brian Utterback Cc: PSARC-ext@sun.com Message-id: <49F1CFFF.2020801@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090422) Status: RO Content-Length: 2990 The timer is expired. I have marked this as closed approved. Thanks to everyone that looked at this. I appreciate the effort. Brian Utterback wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Upgrade NTP to Version 4 > 1.2. Name of Document Author/Supplier: > Author: Brian Utterback > 1.3 Date of This Document: > 17 April, 2009 > 4. Technical Description > Upgrade NTP to version 4. > > > This project proposes to remove the current version 3.4 NTP > deliverables and replace them with version 4.2.5. The current > version in Solaris was released 11 years ago. The NTP project > has continued to advance the code base for the entire time. > > This will be done by removing the current SUNWntpr and SUNWntpu > packages from the ON consolidation and move them to the more > appropriate SFW consolidation. In addition to the replacements > for the current deliverables, the packages will include man pages > and HTML documentation. > > While not 100% backwards compatible, the incompatibilities in the > configuration file are mostly semantic in nature rather than > syntatic, with the only major exceptions being in Sun added features, > which we will not be adding. However, because of the popularity of > the "slewalways" feature, the startup method will detect the > presence of this Sun added keyword and configure the NTP daemon to > use the NTP version 4 equivalent. > > The NTP community project, while not having an explicit requirement > for backwards compatibility, in 11 years > of development, including a full re-write of the configuration > code, has had no major incompatibilities were introduced. > > The NTP community is very receptive to contributed code and > integration of features needed by Solaris. I am a committer on > the NTP project and I expect to work with the community to > push all fixes and changes back into the community codebase. > > While the man pages are derived from the HTML documentation, they > are specific to these deliverables and as far as possible complete and > accurate regarding them. The HTML documenation, is delivered "as is" > and may or may not reflect the deliverables. A notice to this effect is > included in the man pages. > > This work is being sponsored by chris.armes@sun.com. > > This project seeks a minor release binding. > > This project supercedes PSARC 2001/162, which should considered > withdrawn. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > -- blu "Mark my words, nanotechnology is going to be huge!" ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From ro@techfak.uni-bielefeld.de Fri Apr 24 09:30:05 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OGU43L026183 for ; Fri, 24 Apr 2009 09:30:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3OGTxxg021346; Sat, 25 Apr 2009 00:30:01 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM007015U0ZC00@brm-avmta-1.central.sun.com>; Fri, 24 Apr 2009 10:30:00 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00BFO5TZ2CD0@brm-avmta-1.central.sun.com>; Fri, 24 Apr 2009 10:29:59 -0600 (MDT) Received: from relay12i.sun.com (ip122.net129179-4.block1.us.syntegra.com [129.179.4.122]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3OGNwL2026374; Fri, 24 Apr 2009 16:29:59 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay12i.sun.com with ESMTP id BT-MMP-83110; Fri, 24 Apr 2009 16:29:58 +0000 (Z) Received: from relay12i.sun.com (relay12i.sun.com [129.179.4.122]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-28756158; Fri, 24 Apr 2009 16:29:56 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay1i.sun.com with ESMTP id BT-MMP-2336591; Fri, 24 Apr 2009 16:29:55 +0000 (Z) Received: from manam.TechFak.Uni-Bielefeld.DE (manam.TechFak.Uni-Bielefeld.DE [129.70.137.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 37C3948291; Fri, 24 Apr 2009 18:29:55 +0200 (CEST) Date: Fri, 24 Apr 2009 18:29:53 +0200 From: Rainer Orth Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: Brian Utterback's message of "Fri, 17 Apr 2009 13:26:36 -0400" Sender: ro@techfak.uni-bielefeld.de To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Gnus v5.6.44/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 2.015sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 119 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> Status: RO Content-Length: 4655 Brian Utterback writes: I'm sorry for chiming in so late (even after the case was closed), but I've been terribly busy all week. There are a couple of issues I noticed when we founded the ntp project back in 2006 and that I'd like to see addressed by this case: > 3.3 Services and the /etc Directory [...] > Does the service manifests method context grant rights above that > of the noaccess user and basic privilege set? > [ ] Yes - ARC review required > [x] No This is wrong: the ntp.xml file in the case materials has Since ntp is a network facing service, I suggest to handle this differently: don't use root here, but a special ntp user and group. I don't think daemon can be used since the ntpd potentially needs to read ntp keying material in /etc/inet (or whereever ntp.conf says) which must not be readable by other daemon processes and needs to write to ntp.drift and ntpstats in /var/ntp. root (as suggested here) has read and write access to too many files, so I strongly prefer the special uid/gid instead. If /var/ntp needs to be writable by ntp:ntp after the upgrade, this needs to handled there. I'm not sure how to best handle the privilege set: use basic,!file_link_any,!proc_info,!proc_session,... or just list the necessary privileges? That may be a code review issue, though. One should even consider those privileges which are only needed at startup, but this is something to pursue within the NTP project, not in this ARC case. > 3.4 Security > 3.4.1 Secure By Default [...] > Are inbound network communications denied by default? > [x] Yes > [ ] No - ARC review required > [ ] N/A This is only true if the ntp service is completely disabled. > Are passwords stored within the file system for the component? > [x] Yes > [ ] No - continue to next section (section 3.4.6) > > If yes are the permissions on the file such to protect exposing the password(s)? > [x] Yes > [ ] No - ARC review required > The passwords are stored in the /etc/inet/ntp.keys file, which is not delivered. This > file is administrator created. The passwords in question authenticate NTP servers and > clients to one another and not individual users. It is up to the administrator to > set permissions appropriately when the file is created. I think we should provide some guidelines for that, especially if ntpd is run as ntp:ntp. > 4.0 Interfaces > (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) > 4.1 Exported Interfaces > > Interface Name Classification Comments > --------------------------- ------------------- --------------------------- > SUNWntpr Uncomitted Root package > SUNWntpu Uncomitted /usr package > /etc/inet/ntp.conf Uncomitted Configuration file > /usr/lib/inet/ntpd Uncomitted NTP daemon > /usr/lib/inet/ntp-wait Project Private > /usr/sbin/ntpdate Volatile > /usr/sbin/ntptrace Volatile > /usr/sbin/ntpq Uncomitted > /usr/sbin/ntpdc Volatile > /usr/sbin/ntp-keygen Uncomitted Crypto key gen utility. > /usr/sbin/ntptime Volatile Kernel NTP state utility. > /usr/share/doc/ntp Uncommitted Location for html docs > /usr/share/doc/ntp/* Volatile Contents of HTML docs. I think the FMRI should be listed here as well. > 4.2 Imported Interfaces > Interface Name Classification Comments > ----------------------------------- ----------- -------------------------- [...] > ntp_adjtime,ntp_gettime syscalls Project Private Seems unlikely given that there are ntp_adjtime(2) and ntp_gettime(2) man pages available. I don't know which case introduced them, and the man pages don's state interface stability. I don't see this in the FOSS checklist, but perhaps the use of RBAC authorizations should be explicitly part of this case. The ntp.xml manifest currently has Perhaps we need separate authorizations for changing service properties compared to starting and stopping the service? Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From brian.utterback@sun.com Fri Apr 24 10:51:31 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OHpVvd028180 for ; Fri, 24 Apr 2009 10:51:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3OHpTA0023441 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 24 Apr 2009 11:51:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM00F019LU8X00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Apr 2009 10:51:30 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00HCI9LTK7D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 24 Apr 2009 10:51:29 -0700 (PDT) Received: from [129.148.9.36] (sr1-ubur-12.East.Sun.COM [129.148.9.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3OHpRFa047944; Fri, 24 Apr 2009 13:51:27 -0400 (EDT) Date: Fri, 24 Apr 2009 13:51:22 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: To: Rainer Orth Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <49F1FC1A.6090502@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090422) Status: RO Content-Length: 6566 Rainer Orth wrote: > Brian Utterback writes: > > I'm sorry for chiming in so late (even after the case was closed), but I've > been terribly busy all week. > > There are a couple of issues I noticed when we founded the ntp project back > in 2006 and that I'd like to see addressed by this case: > >> 3.3 Services and the /etc Directory > [...] >> Does the service manifests method context grant rights above that >> of the noaccess user and basic privilege set? >> [ ] Yes - ARC review required >> [x] No > > This is wrong: the ntp.xml file in the case materials has > > > user='root' > group='root' > privileges='proc_fork,proc_exec,net_privaddr,proc_lock_memory,sys_time' > /> > Okay. Fair enough. It should have been Yes. But this is more restrictive than the current implementation, since xntpd currently runs as root with all privs. > > Since ntp is a network facing service, I suggest to handle this > differently: don't use root here, but a special ntp user and group. I > don't think daemon can be used since the ntpd potentially needs to read > ntp keying material in /etc/inet (or whereever ntp.conf says) which must > not be readable by other daemon processes and needs to write to ntp.drift > and ntpstats in /var/ntp. root (as suggested here) has read and write > access to too many files, so I strongly prefer the special uid/gid instead. > > If /var/ntp needs to be writable by ntp:ntp after the upgrade, this needs > to handled there. While I am not adverse to having an ntp user and group, I have discussed this with a few people off and on, and there doesn't seem to be a consensus as to whether or not it is worth it. It will definitely make administration more difficult, because of the requirements placed on the key files. Also, in discussion with Nico just now, we agreed to have the pid for ntp written to /var/run, which will be more complicated if the daemon runs as anything other than root or daemon. Having a ntp user will definitely break the reading of existing keyfiles. > > I'm not sure how to best handle the privilege set: use > basic,!file_link_any,!proc_info,!proc_session,... or just list the > necessary privileges? That may be a code review issue, though. > > One should even consider those privileges which are only needed at startup, > but this is something to pursue within the NTP project, not in this ARC > case. > Correct. I would prefer to deal with restricting the privs and making NTP priv aware as a follow-on project in concert with the NTP community. It is clear that the privs in the proposed NTPv4 are an improvement on the current xntpd service. I would like to take this one step at a time. >> 3.4 Security >> 3.4.1 Secure By Default > [...] >> Are inbound network communications denied by default? >> [x] Yes >> [ ] No - ARC review required >> [ ] N/A > > This is only true if the ntp service is completely disabled. That was my interpretation, i.e. that this attribute was met by the fact that the service is off by default. > >> Are passwords stored within the file system for the component? >> [x] Yes >> [ ] No - continue to next section (section 3.4.6) >> >> If yes are the permissions on the file such to protect exposing the password(s)? >> [x] Yes >> [ ] No - ARC review required >> The passwords are stored in the /etc/inet/ntp.keys file, which is not delivered. This >> file is administrator created. The passwords in question authenticate NTP servers and >> clients to one another and not individual users. It is up to the administrator to >> set permissions appropriately when the file is created. > > I think we should provide some guidelines for that, especially if ntpd is > run as ntp:ntp. Perhaps. Again, this is no worse than the current implementation, and I think it is much better. The docs are all delivered in /usr/share/doc/ntp. > >> 4.0 Interfaces >> (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) >> 4.1 Exported Interfaces >> >> Interface Name Classification Comments >> --------------------------- ------------------- --------------------------- >> SUNWntpr Uncomitted Root package >> SUNWntpu Uncomitted /usr package >> /etc/inet/ntp.conf Uncomitted Configuration file >> /usr/lib/inet/ntpd Uncomitted NTP daemon >> /usr/lib/inet/ntp-wait Project Private >> /usr/sbin/ntpdate Volatile >> /usr/sbin/ntptrace Volatile >> /usr/sbin/ntpq Uncomitted >> /usr/sbin/ntpdc Volatile >> /usr/sbin/ntp-keygen Uncomitted Crypto key gen utility. >> /usr/sbin/ntptime Volatile Kernel NTP state utility. >> /usr/share/doc/ntp Uncommitted Location for html docs >> /usr/share/doc/ntp/* Volatile Contents of HTML docs. > > I think the FMRI should be listed here as well. Okay, happy to. > >> 4.2 Imported Interfaces >> Interface Name Classification Comments >> ----------------------------------- ----------- -------------------------- > [...] >> ntp_adjtime,ntp_gettime syscalls Project Private > > Seems unlikely given that there are ntp_adjtime(2) and ntp_gettime(2) man > pages available. I don't know which case introduced them, and the man > pages don's state interface stability. True. The original implementation was done by Jan Brittenson, and he stated to me that he intended these interfaces to be project private. I also expressed a bit of dismay. But I am not changing them anyway. On the other hand, I know of no other consumers than NTP. > > I don't see this in the FOSS checklist, but perhaps the use of RBAC > authorizations should be explicitly part of this case. The ntp.xml > manifest currently has > > > > value='solaris.system.date' /> > > > Perhaps we need separate authorizations for changing service properties > compared to starting and stopping the service? I am not sure that I see an advantage. -- blu "Mark my words, nanotechnology is going to be huge!" ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Nicolas.Williams@sun.com Fri Apr 24 12:00:13 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OJ0CFx001336 for ; Fri, 24 Apr 2009 12:00:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3OJ08vZ019756; Sat, 25 Apr 2009 03:00:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM0000NCS7QR00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Apr 2009 12:00:07 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00NORCS60710@nwk-avmta-1.sfbay.Sun.COM>; Fri, 24 Apr 2009 12:00:06 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3OIw06L017928; Fri, 24 Apr 2009 13:58:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3OIw0ao017927; Fri, 24 Apr 2009 13:58:00 -0500 (CDT) Date: Fri, 24 Apr 2009 13:57:59 -0500 From: Nicolas Williams Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49F1FC1A.6090502@sun.com> To: Brian Utterback Cc: Rainer Orth , Brian Utterback , PSARC-ext@sun.com Message-id: <20090424185759.GX1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <49F1FC1A.6090502@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 992 On Fri, Apr 24, 2009 at 01:51:22PM -0400, Brian Utterback wrote: > While I am not adverse to having an ntp user and group, I have > discussed this with a few people off and on, and there doesn't seem to > be a consensus as to whether or not it is worth it. It will definitely > make administration more difficult, because of the requirements placed > on the key files. Also, in discussion with Nico just now, we agreed to > have the pid for ntp written to /var/run, which will be more > complicated if the daemon runs as anything other than root or daemon. > Having a ntp user will definitely break the reading of existing keyfiles. I'd be happier if there were no ntp pid file though... In the world of SMF PID files should generally be unnecessary (if signals are used as IPC then pid files are tolerable). Also, since ntpd is aware of Linux capabilities, surely making it aware of Solaris privileges should be acceptable (either as part of this case or a folow-on CR). Nico -- From brian.utterback@Sun.COM Mon Apr 27 06:47:59 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3RDlwbe021026 for ; Mon, 27 Apr 2009 06:47:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3RDlvEv017466 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Apr 2009 07:47:58 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIR00707IBYPK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Apr 2009 06:47:58 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIR00J8WIBXARC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Apr 2009 06:47:57 -0700 (PDT) Received: from [129.148.9.87] (sr1-ubur-08.East.Sun.COM [129.148.9.87]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3RDlrE9020142; Mon, 27 Apr 2009 09:47:54 -0400 (EDT) Date: Mon, 27 Apr 2009 09:47:53 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <20090424185759.GX1500@Sun.COM> To: Nicolas Williams Cc: Rainer Orth , Brian Utterback , PSARC-ext@Sun.COM Message-id: <49F5B789.3090109@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <49F1FC1A.6090502@sun.com> <20090424185759.GX1500@Sun.COM> User-Agent: Thunderbird 2.0.0.22pre (X11/20090422) Status: RO Content-Length: 1291 Nicolas Williams wrote: > On Fri, Apr 24, 2009 at 01:51:22PM -0400, Brian Utterback wrote: >> While I am not adverse to having an ntp user and group, I have >> discussed this with a few people off and on, and there doesn't seem to >> be a consensus as to whether or not it is worth it. It will definitely >> make administration more difficult, because of the requirements placed >> on the key files. Also, in discussion with Nico just now, we agreed to >> have the pid for ntp written to /var/run, which will be more >> complicated if the daemon runs as anything other than root or daemon. >> Having a ntp user will definitely break the reading of existing keyfiles. > > I'd be happier if there were no ntp pid file though... In the world of > SMF PID files should generally be unnecessary (if signals are used as > IPC then pid files are tolerable). In this case, I am just using the pid file as an indicator in /var/run that ntpd has already run. Nothing reads its contents, just its existence is tested in the startup method. -- blu "Mark my words, nanotechnology is going to be huge!" ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From ro@techfak.uni-bielefeld.de Tue Apr 28 11:25:43 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3SIPhIw013310 for ; Tue, 28 Apr 2009 11:25:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3SIPUFW020086; Tue, 28 Apr 2009 11:25:42 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIT00K3FPUT6A00@brm-avmta-1.central.sun.com>; Tue, 28 Apr 2009 12:25:41 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIT00C8IPURDX60@brm-avmta-1.central.sun.com>; Tue, 28 Apr 2009 12:25:39 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3SIHVXV027418; Tue, 28 Apr 2009 18:25:39 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay44i.sun.com with ESMTP id BT-MMP-142551; Tue, 28 Apr 2009 18:25:26 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-32921799; Tue, 28 Apr 2009 18:25:24 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-31922879; Tue, 28 Apr 2009 18:20:43 +0000 (Z) Received: from manam.TechFak.Uni-Bielefeld.DE (manam.TechFak.Uni-Bielefeld.DE [129.70.137.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 92882481F1; Tue, 28 Apr 2009 20:20:26 +0200 (CEST) Date: Tue, 28 Apr 2009 20:20:24 +0200 (MEST) From: Rainer Orth Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49F1FC1A.6090502@sun.com> To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <18935.18664.401812.718860@manam.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.444sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49E8BBCC.2090005@sun.com> <49F1FC1A.6090502@sun.com> Status: RO Content-Length: 7965 Brian Utterback writes: > >> 3.3 Services and the /etc Directory > > [...] > >> Does the service manifests method context grant rights above that > >> of the noaccess user and basic privilege set? > >> [ ] Yes - ARC review required > >> [x] No > > > > This is wrong: the ntp.xml file in the case materials has > > > > > > > user='root' > > group='root' > > privileges='proc_fork,proc_exec,net_privaddr,proc_lock_memory,sys_time' > > /> > > > > Okay. Fair enough. It should have been Yes. But this is more > restrictive than the current implementation, since xntpd currently > runs as root with all privs. True enough, but probably only because nobody did the necessary analysis to restrict the privilege set. > > Since ntp is a network facing service, I suggest to handle this > > differently: don't use root here, but a special ntp user and group. I > > don't think daemon can be used since the ntpd potentially needs to read > > ntp keying material in /etc/inet (or whereever ntp.conf says) which must > > not be readable by other daemon processes and needs to write to ntp.drift > > and ntpstats in /var/ntp. root (as suggested here) has read and write > > access to too many files, so I strongly prefer the special uid/gid instead. > > > > If /var/ntp needs to be writable by ntp:ntp after the upgrade, this needs > > to handled there. > > While I am not adverse to having an ntp user and group, I have > discussed this with a few people off and on, and there doesn't seem to > be a consensus as to whether or not it is worth it. It will definitely > make administration more difficult, because of the requirements placed > on the key files. Also, in discussion with Nico just now, we agreed to > have the pid for ntp written to /var/run, which will be more > complicated if the daemon runs as anything other than root or daemon. > Having a ntp user will definitely break the reading of existing keyfiles. Right, but given that ntpd is a network facing daemon which needs to be able to read and write files, I'd opt to make it as secure as possible, which means not running as root if at all possible (which it is: I tried this back in 2006 when I made a first cut at an SMF service for ntp4). Since the pid file is not really necessary at in the presence of SMF, I'd either omit it completely or have it in /var/ntp which needs to be writable by the ntpd daemon user (ntp in my proposal) anyway. I think it is important to get this right at first shot: forcing users to deal with two migrations (xntpd -> ntpd both run as root and later ntpd run as root -> ntpd run as ntp:ntp) should be avoided. I don't think we really are in a hurry to integrate as quickly as possible. > > I'm not sure how to best handle the privilege set: use > > basic,!file_link_any,!proc_info,!proc_session,... or just list the > > necessary privileges? That may be a code review issue, though. > > > > One should even consider those privileges which are only needed at startup, > > but this is something to pursue within the NTP project, not in this ARC > > case. > > > > Correct. I would prefer to deal with restricting the privs and making > NTP priv aware as a follow-on project in concert with the NTP > community. It is clear that the privs in the proposed NTPv4 are an > improvement on the current xntpd service. I would like to take this > one step at a time. Agreed: this is certainly only a refinement (and probably not an issue for PSARC anyway since the daemon needs to start off with the larger privilege set). > >> 3.4 Security > >> 3.4.1 Secure By Default > > [...] > >> Are inbound network communications denied by default? > >> [x] Yes > >> [ ] No - ARC review required > >> [ ] N/A > > > > This is only true if the ntp service is completely disabled. > > That was my interpretation, i.e. that this attribute was met by the > fact that the service is off by default. Ok. Maybe we can get a clarification from the authors of the FOSS checklist? > >> Are passwords stored within the file system for the component? > >> [x] Yes > >> [ ] No - continue to next section (section 3.4.6) > >> > >> If yes are the permissions on the file such to protect exposing the password(s)? > >> [x] Yes > >> [ ] No - ARC review required > >> The passwords are stored in the /etc/inet/ntp.keys file, which is not delivered. This > >> file is administrator created. The passwords in question authenticate NTP servers and > >> clients to one another and not individual users. It is up to the administrator to > >> set permissions appropriately when the file is created. > > > > I think we should provide some guidelines for that, especially if ntpd is > > run as ntp:ntp. > > Perhaps. Again, this is no worse than the current implementation, and > I think it is much better. The docs are all delivered in > /usr/share/doc/ntp. Fine. ntp4 is certainly a strict improvement over xntp, but if we can improve the Solaris integration at integration, we should. > >> 4.2 Imported Interfaces > >> Interface Name Classification Comments > >> ----------------------------------- ----------- -------------------------- > > [...] > >> ntp_adjtime,ntp_gettime syscalls Project Private > > > > Seems unlikely given that there are ntp_adjtime(2) and ntp_gettime(2) man > > pages available. I don't know which case introduced them, and the man > > pages don's state interface stability. > > True. The original implementation was done by Jan Brittenson, and he > stated to me that he intended these interfaces to be project private. > I also expressed a bit of dismay. But I am not changing them anyway. > On the other hand, I know of no other consumers than NTP. Probably not, but we should check this. Perhaps you can dig up the original PSARC case which proposed those? This might become important in the future if the nanokernel code is ported to Solaris: such a port would break interface compatiblity, and would be much easier if they really were Project Private. > > I don't see this in the FOSS checklist, but perhaps the use of RBAC > > authorizations should be explicitly part of this case. The ntp.xml > > manifest currently has > > > > > > > > > value='solaris.system.date' /> > > > > > > Perhaps we need separate authorizations for changing service properties > > compared to starting and stopping the service? > > I am not sure that I see an advantage. My take here is that it should be possible for an operator to stop and restart the ntp service without being able to reconfigure it at the same time. /etc/security/auth_attr regularly has separate solaris.smf.manage.* and solaris.smf.value.* authorizations. I think it would be wise to follow this lead. In fact, the `Service Management Facility (SMF) usage' policy http://www.opensolaris.org/os/community/arc/policies/SMF-policy/ states Guidance For Delivery of SMF Services [...] * Services must provide service related RBAC authorizations, as appropriate, by providing service specific values for the action_authorization, modify_authorization, value_authorization, and read_authorization of property groups. See smf_security(5). These authorizations must follow the form of "solaris.smf.{manage, modify, value, read}.service" respectively. These authorizations must be delivered into an appropriate Rights profile, either new or existing. Note that I won't be able to follow up on any replies since I'll be away until Monday. Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University From brian.utterback@sun.com Tue May 5 08:55:40 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n45FtdAc005524 for ; Tue, 5 May 2009 08:55:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n45FtRkD003259 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 5 May 2009 08:55:39 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ600G0BHKQCX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 05 May 2009 09:55:38 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ6003JJHKP68A0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 05 May 2009 09:55:38 -0600 (MDT) Received: from [129.148.9.87] (sr1-ubur-08.East.Sun.COM [129.148.9.87]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n45FtaSp017206; Tue, 05 May 2009 11:55:37 -0400 (EDT) Date: Tue, 05 May 2009 11:55:36 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49F1CFFF.2020801@sun.com> To: Brian Utterback Cc: psarc-ext@sun.com Message-id: <4A006178.3030508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49F1CFFF.2020801@sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090422) Status: RO Content-Length: 3633 I am sending this as an amendment to the already approved case. During the code review, it was suggested to have two authorizations for control of the NTP service. The version 3 code does not have a authorization defined. In the new code, I originally had the authorization of "solaris.system.date" to control the NTP service. The new plan is to add two authorizations, "solaris.smf.manage.ntp" and "solaris.smf.value.ntp" as per the SMF best practices. I believe this qualifies for automatic approval. If any one disagrees, please let me know. Brian Utterback wrote: > The timer is expired. I have marked this as closed approved. > > Thanks to everyone that looked at this. I appreciate the effort. > > Brian Utterback wrote: >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Upgrade NTP to Version 4 >> 1.2. Name of Document Author/Supplier: >> Author: Brian Utterback >> 1.3 Date of This Document: >> 17 April, 2009 >> 4. Technical Description >> Upgrade NTP to version 4. >> >> >> This project proposes to remove the current version 3.4 NTP >> deliverables and replace them with version 4.2.5. The current >> version in Solaris was released 11 years ago. The NTP project >> has continued to advance the code base for the entire time. >> This will be done by removing the current SUNWntpr and SUNWntpu >> packages from the ON consolidation and move them to the more >> appropriate SFW consolidation. In addition to the replacements >> for the current deliverables, the packages will include man pages >> and HTML documentation. >> >> While not 100% backwards compatible, the incompatibilities in the >> configuration file are mostly semantic in nature rather than syntatic, >> with the only major exceptions being in Sun added features, which we >> will not be adding. However, because of the popularity of >> the "slewalways" feature, the startup method will detect the presence >> of this Sun added keyword and configure the NTP daemon to use the NTP >> version 4 equivalent. >> The NTP community project, while not having an explicit requirement >> for backwards compatibility, in 11 years of development, including a >> full re-write of the configuration >> code, has had no major incompatibilities were introduced. >> The NTP community is very receptive to contributed code and >> integration of features needed by Solaris. I am a committer on >> the NTP project and I expect to work with the community to push all >> fixes and changes back into the community codebase. >> >> While the man pages are derived from the HTML documentation, they >> are specific to these deliverables and as far as possible complete and >> accurate regarding them. The HTML documenation, is delivered "as is" >> and may or may not reflect the deliverables. A notice to this effect is >> included in the man pages. >> >> This work is being sponsored by chris.armes@sun.com. >> >> This project seeks a minor release binding. >> This project supercedes PSARC 2001/162, which should considered >> withdrawn. >> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> SFW >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> > -- blu "Mark my words, nanotechnology is going to be huge!" ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From brian.utterback@sun.com Wed Jun 17 07:36:50 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5HEaoKW010989 for ; Wed, 17 Jun 2009 07:36:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5HEae73012643 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Jun 2009 07:36:50 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLE0094F0LD4400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 08:36:49 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLE003KN0LACO60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 08:36:46 -0600 (MDT) Received: from [129.148.9.87] (sr1-ubur-08.East.Sun.COM [129.148.9.87]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5HEajWw062550; Wed, 17 Jun 2009 10:36:45 -0400 (EDT) Date: Wed, 17 Jun 2009 10:36:45 -0400 From: Brian Utterback Subject: Re: Upgrade NTP to Version 4 [PSARC/2009/244 FastTrack timeout 04/23/2009] In-reply-to: <49F1CFFF.2020801@sun.com> To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <4A38FF7D.40500@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_k2NLTjtO7nN0xNNFf7CJYg)" X-PMX-Version: 5.4.1.325704 References: <200904171719.n3HHJ002011453@sac.sfbay.sun.com> <49F1CFFF.2020801@sun.com> User-Agent: Thunderbird 2.0.0.22pre (X11/20090603) Status: RO Content-Length: 12381 This is a multi-part message in MIME format. --Boundary_(ID_k2NLTjtO7nN0xNNFf7CJYg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Just a little house keeping. This is to record that the contract for NTP V4 to use OpenSSL is recorded as contract 2003/500/contract-37. -- blu "The advertising giveth and the EULA taketh away." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom --Boundary_(ID_k2NLTjtO7nN0xNNFf7CJYg) Content-type: text/plain; name=contract-37 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=contract-37 @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] #ident "@(#)contract.txt 1.3 03/11/04 SMI" CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2003/500-37 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris WOS Consolidation: ON Department or Group: Solaris Security Technology Group (SSTG) Bugtraq Category/SubCategory: solaris/solaris-crypto/openssl Responsible Manager: Anup Sekhar Contact: contract-2003-500@sun.com 3. The CONSUMER is identified by the following: Product or Bundle: Solaris WOS Consolidation: SFW Department or Group: Solaris RPE Bugtraq Category/SubCategory: solaris/network/ntp Responsible Manager: Satish Murugesan Packages: SUNWntpu Contact: ntp-interest@sun.com 4. The INTERFACES are: The interfaces covered by this contract are limited to a subset of the C programming APIs that the OpenSSL communittee has choosen to document in man pages. It is the subset that the SUPPLIER beleives to be reasonably stable. That subset covers the following major subsystems: ASN1, BN, CRYPTO, EVP, HMAC, OpenSSL, PEM, PKCS7, PKCS12, RAND, SMIME, SSL, BIO, X509 In particular it does NOT cover "direct use" of encryption algorithm APIs outside of the EVP_ interfaces, eg do not call DES or AES except via EVP_Encrypt*() This contract does NOT cover the use of the openssl(1) command as an interface to be consumed. This contract does NOT cover any API or implementation artifact that does not have an OpenSSL delivered man page. OpenSSL Package names SUNWopenssl-include Unstable SUNWopenssl-libraries Unstable OpenSSL Library Location /usr/sfw/lib/libcrypto.so Unstable /usr/sfw/lib/libssl.so Unstable OpenSSL Headers Location /usr/sfw/include/openssl/*.h UnStable ASN1_ External BN_ External BIO_ External CRYPTO_ External EVP_ External HMAC External OpenSSL_ External OBJ_ External PEM_ External PKCS7 External PKCS12_ External RAND_ External SMIME_ External SSL_ External X509_ External 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing these INTERFACES is: PSARC/2003/500 Note: this contract is not about a specific version of OpenSSL. It covers version 0.9.7d from PSARC/2003/500 and all subsequent versions. If a change in the OpenSSL interfaces requires an update of the contract then OpenSSL iteam will contact the consumer. 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _Y_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: The SUPPLIER will modify the interfaces as needed by the evolution of OpenSSL releases shipped by on the www.openssl.org site. _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: Name of Company: Name of Department or Group within Company: Responsible Manager: _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. This contract is only avaliable for CONSUMERS who deliver directly to the Solaris WOS. If a contract for a CONSUMER who is not part of the Solaris WOS is requested it will be dealt with by ARC and the SUPPLIER as a new contract. _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they will have simultaneous conversion to the new interfaces. The SUPPLIER will make a best effort to do most of the work, but the CONSUMER must be willing to supply resources to assist with modification/testing of their consuming code if necessary. Only a single version of the INTERFACES will be available at any one time. 8. If CONSUMER requires changes in INTERFACES, they must work with the OpenSSL communittee. The SUPPLIER is willing to assist with this process on a best effort to accommodate such changes. In general INTERFACE changes will not be made unless they come from the OpenSSL communittee. 9. N/A 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: The SUPPLIER will update the OpenSSL code base in the ON consolidation on an as needed basis. The trigger for these events is based on the externally defined schedule of the OpenSSL communittee. The SUPPLIER will inform the CONSUMER(S) of this change via the contract alias before filing the RTI for integration into ON. Note that it may be necessary to update INTERFACES (or more likely the implementations of them) with less than 5 working days notice. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: The SUPPLIER will NOT provide any assistance for use of the interfaces they are Externally defined and the SUPPLIER is not necessarily an expert in their use. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: The only documentation will be that provided by the OpenSSL communittee, it will be shipped in the SUNWopenssl-man package in the form of Solaris nroff man pages. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: Before each intergration the OpenSSL test suites will be run. The standard for "PASS" is that the version in the ON gate should produce the same functionality as binaries built using the OpenSSL makefiles for the same processor architecture. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: The CONSUMER may choose to terminate this contract at any time by sending email to the contract-2003-500@sun.com alias. The SUPPLIER may terminate this contract only after giving suffient notice to the CONSUMER. Sufficient notice in the case of CONSUMERS that are external to the ON consolidation must take into account the Solaris WOS build schedule and its restrictions for change. The SUPPLIER will terminate this contract if the interfaces are ever reclassified to something other than External. 15. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Anup Sekhar Date: 05/13/2009 For CONSUMER: Satish Murugesan Date: 05/15/2009 For ARC: Brian Utterback Date: 05/15/2009 A copy of this contract shall be deposited in the CASE directory as "contract-" or in a "contracts" subdirectory. 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: --Boundary_(ID_k2NLTjtO7nN0xNNFf7CJYg) Content-type: message/rfc822; name="Attached Message" Content-disposition: inline; filename="Attached Message" Return-path: Received: from fe-amer-09.sun.com ([unknown] [192.18.109.79]) by amer3-mail1.central.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTP id <0KJM00GLJ76ZJP80@amer3-mail1.central.sun.com> for Brian.Utterback@Sun.COM; Wed, 13 May 2009 21:32:59 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJM00C0073V2900@mail-amer.sun.com> for Brian.Utterback@Sun.COM (ORCPT Brian.Utterback@Sun.COM); Wed, 13 May 2009 21:32:59 -0600 (MDT) Received: from spartacus.local ([unknown] [129.150.32.116]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJM0051X76Y9320@mail-amer.sun.com>; Wed, 13 May 2009 21:32:59 -0600 (MDT) Date: Wed, 13 May 2009 20:32:58 -0700 From: Anup Sekhar Subject: Re: Contract for NTPv4 to consume interfaces from libcrypto.so. In-reply-to: <4A046D88.2020808@sun.com> Sender: Anup.Sekhar@Sun.COM To: Brian Utterback Cc: contract-2003-500@sun.com, Satish Murugesan Message-id: <4A0B90EA.4010903@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <4A046D88.2020808@sun.com> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Original-recipient: rfc822;Brian.Utterback@Sun.COM On 5/8/09 10:36 AM Brian Utterback wrote: > I am enclosing the interface contract for NTP to use libcrypto. Please > read the contract and email me with your acceptance. Thank you. > Sorry for the delay. I approve this contract. Anup --Boundary_(ID_k2NLTjtO7nN0xNNFf7CJYg) Content-type: message/rfc822; name="Attached Message" Content-disposition: inline; filename="Attached Message" Return-path: Received: from fe-sfbay-09.sun.com ([unknown] [192.18.34.119]) by amer3-mail1.central.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTP id <0KJO003QXVQH2A40@amer3-mail1.central.sun.com> for Brian.Utterback@Sun.COM; Fri, 15 May 2009 08:18:17 -0600 (MDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJO00H00VJF4Y00@fe-sfbay-09.sun.com> for Brian.Utterback@Sun.COM (ORCPT Brian.Utterback@Sun.COM); Fri, 15 May 2009 07:18:17 -0700 (PDT) Received: from satish-murugesans-macbook-pro.local ([unknown] [129.150.17.153]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJO00AYMVQF3Y30@fe-sfbay-09.sun.com>; Fri, 15 May 2009 07:18:16 -0700 (PDT) Date: Fri, 15 May 2009 07:18:17 -0700 From: Satish Murugesan Subject: Re: Contract for NTPv4 to consume interfaces from libcrypto.so. In-reply-to: <4A0B90EA.4010903@sun.com> Sender: Satish.Murugesan@Sun.COM To: Anup Sekhar Cc: Brian Utterback , contract-2003-500@sun.com Message-id: <4A0D79A9.6080903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <4A046D88.2020808@sun.com> <4A0B90EA.4010903@sun.com> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Original-recipient: rfc822;Brian.Utterback@Sun.COM Thanks Anup. I accept this contract as well. Satish Anup Sekhar wrote: > On 5/8/09 10:36 AM Brian Utterback wrote: >> I am enclosing the interface contract for NTP to use libcrypto. >> Please read the contract and email me with your acceptance. Thank you. >> > > Sorry for the delay. I approve this contract. > > Anup --Boundary_(ID_k2NLTjtO7nN0xNNFf7CJYg)--