Re: fnmatch(3C) enhancement [PSARC/2010/318 FastTrack timeout 08/18/2010]
On 08/11/10 08:57 PM, Ienup Sung wrote: This case extends fnmatch(3C) to have the support for FNM_CASEFOLD, FNM_FILE_NAME, FNM_IGNORECASE, and FNM_LEADING_DIR flags as specified in [2]. This is to be more compatible with other platforms such as Linux distros and BSD variants including MacOS X and FreeBSD. +1 -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Extensions for LDC transport API [PSARC/2010/308 FastTrack timeout 08/10/10]
On 08/ 3/10 04:03 PM, Govinda Tatti wrote: 4.3 Changes From the Previous Case This project is an extension to the approved case, PSARC/2006/152 - "Logical Domain Channels Transport API". The existing APIs are not changed. But a new API is added, which extends the capabilities of the existing interfaces. The change includes: - A new API function (ldc_info()) to return the amount of direct map space available on a given LDC handle to the client. +1 -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Input Method Framework selector and IMF default change [PSARC/2010/302 FastTrack timeout 08/05/2010]
On 08/ 5/10 01:21 AM, Fuyuki Hasegawa wrote: Hi Sebastien, Agreed. I've moved out the default change from the material and also updated the IAM file. /shared/sac/Archives/Projects/2010/20100729_kazuhiko.maekawa If no more objection for this case, could you vote your +1? Yes, +1. Could you also change the title of the case to reflect the change? I believe there's a script on sac.sfbay that will allow you to do this. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: GNU/Linux/BSD compatibility functions [PSARC/2010/299 FastTrack timeout, 08/04/2010]
On 08/ 2/10 09:19 PM, Roger A. Faulkner wrote: As a result of suggestions made in the email for this case, I am sending this revised, final version of the proposal (with additional bugids included and with the description of getprogname(), setprogname() and __progname included): This case was approved during today's PSARC meeting. I know Garrett gave the case a +1 before the spec was updated, and I've just reviewed the updated spec and give it a +1 as well. I assume that Garrett has no issues with the updated spec... -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zonestat [PSARC/2010/291 FastTrack timeout 08/02/2010]
On 08/ 4/10 01:07 PM, Jerry Jelinek wrote: This case was approved at todays PSARC meeting. I've marked it closed approved. I gave the case a +1 during the meeting, and am doing so here as well. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Input Method Framework selector and IMF default change [PSARC/2010/302 FastTrack timeout 08/05/2010]
On 07/29/10 09:49 AM, Fuyuki Hasegawa wrote: This case is also to change system default IMF from IIIMF to IBus which becomes de-facto standard in recent major Linux distributions. Locales that IMF is invoked by default is also changed from all UTF-8 locales to only Asian locales since EMEA users most likely prefer Gnome Keyboard Switcher GUI (PSARC/2009/558) which is popular in Linux. Note - the IMF default change is planned in later build after imf-selector integration. Integrating a single case piecemeal is undesirable, as it causes confusion in the integration logs. I'd suggest leaving this default change out of this case and filing a separate fast-track for that. It can be reviewed independently. RELEASE BINDING The project team asks for Micro/Path release binding Changing the default would typically not be appropriate in a Patch as it constitutes an incompatible change. Again, I'd suggest reviewing that separately, as the selector is likely appropriate for patch binding. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Remove binary symlinks from /etc [PSARC/2010/289 FastTrack timeout 07/30/2010]
On 07/26/10 04:49 PM, Sebastien Roy wrote: I think at this point, we've identified that this is at least not uncontroversial, and thus fails the fast-track test. As a result, I'm derailing this case. Also, as is customary, I'll own the full case and have placed it in "waiting need meeting" state. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Remove binary symlinks from /etc [PSARC/2010/289 FastTrack timeout 07/30/2010]
On 07/26/10 01:35 PM, Peter Dennis wrote: The case will be updated so as _not_ to include /etc/rmt. The change to the /etc/skel profiles will be documented as well. The other changes within ON are internal to the commands used and are small changes. As mentioned by others now is the time to remove this stuff (what purpose does it serve ? The purpose for the existence of the symbolic links is for backward compatibility, as the commands have been in that location for decades. why is the zfs command not there?) I don't see this question as being relevant. The zfs command was never there, so it would follow that no-one would have written scripts to call it directly from there. These links form no part of a standard (the project team verified this). I don't think anyone has brought up standards conformance as a contentious issue. The original request from Gary was for a justification for making such an incompatible change. I share Gary's original sentiment, and am concerned that the risk (much of which is unknown) associated with such a change outweighs the reward (which AFAIK no-one has identified yet). I think at this point, we've identified that this is at least not uncontroversial, and thus fails the fast-track test. As a result, I'm derailing this case. Since the scope of this case is so small, I don't think the project team should be required to submit any materials in addition to what is already available in the fast-track, and would request that we simply schedule an inception review meeting where we can discuss the outstanding issue(s) and potentially request a vote. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: FMA/SMF integration: instance state transitions [PSARC/2010/278 FastTrack timeout 07/26/2010]
On 07/21/10 01:56 PM, Cynthia McGuire wrote: This case seeks patch binding. The timer is shorter than the standard 1-week to accomodate a tight integration schedule. If anyone needs additional time to review this, let us know. Is there a reason why the localized contents of the "reason-long" member are an interface at all (with Volatile stability) rather than simply "Not An Interface"? Otherwise, +1. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/283 SMF service for in.mpathd
On 07/22/10 11:13 PM, Mark Haywood wrote: Nicolas Williams wrote: On Thu, Jul 22, 2010 at 09:43:37AM -0400, Mark Haywood wrote: What is the console message ? As mentioned in the case: "Similarly, if the IPMP service is disabled while IPMP groups are configured, the service stop method will display warning messages to the console." This is useless: the user doing the stopping won't be on the console, and the message will be useless noise at shutdown time (since the service can't tell if a stop method invocation is for shutdown or some other purpose; see aside below). Besides, there are plenty of services that should be running when some feature is enabled, and which don't output such messages. For example, in.iked (if the output of ipsecconf -l shows protect rules then chances are you need in.iked running, and if you don't it's because you're using manually-keyed SAs, which is not a good idea). There are other examples (NFS? check. idmap? check. etcetera). Agreed. And after looking at other services and investigating transitioning into maintenance mode when the service is disabled, I believe that the best course of action is simply to get rid of the message. Switching into maintenance mode would require the user to unconfigure all IPMP groups to get back out of maintenance mode. This is not acceptable. That sounds fine to me. +1 on the case. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: FMA/SMF integration: instance state transitions [PSARC/2010/278 FastTrack timeout 07/26/2010]
On 07/21/10 02:19 PM, Sebastien Roy wrote: On 07/21/10 01:56 PM, Cynthia McGuire wrote: This case seeks patch binding. The timer is shorter than the standard 1-week to accomodate a tight integration schedule. If anyone needs additional time to review this, let us know. We already went through this litany during the PSARC meeting (it's the standard fast-track litany) this morning. No-one requested more time and the case was approved. Hmm, I mistook this with 2010/265. Sorry about that, please disregard. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: FMA/SMF integration: instance state transitions [PSARC/2010/278 FastTrack timeout 07/26/2010]
On 07/21/10 01:56 PM, Cynthia McGuire wrote: This case seeks patch binding. The timer is shorter than the standard 1-week to accomodate a tight integration schedule. If anyone needs additional time to review this, let us know. We already went through this litany during the PSARC meeting (it's the standard fast-track litany) this morning. No-one requested more time and the case was approved. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: sysevent_evc_setpropnvl and sysevent_evc_getpropnvl [PSARC/2010/257 Self Review]
This case needs a release binding. Since it's simply adding functionality to an existing Consolidation Private API, I'd suggest Patch. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Kerberos Keytab Management API [PSARC/2010/229 FastTrack timeout 06/28/2010]
On 07/ 4/10 02:08 AM, Shawn Emery wrote: I've made updates based on Sebastien and Nico comments: +1 -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: OFUV Userland Interface [PSARC/2010/239 FastTrack timeout 07/09/2010]
I'm happy with the updated spec. +1 -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: sysevent_evc_setpropnvl and sysevent_evc_getpropnvl [PSARC/2010/257 Self Review]
Gavin, On 07/ 6/10 05:20 PM, Gavin Maltby wrote: On 07/07/10 02:26, Sebastien Roy wrote: Cynthia, I've placed this case in waiting need spec since the spec was never sent to the case log. Please do so. It's there - once you click the case from something like the New listing on sac.sfbay you'll get an error from the usage of sac.eng in the link instead of sac.sfbay - part of the weekends system moves that still needs to be cleaned up. By "log", I'm referring to the mail log. For fast-tracks and self-reviewed cases, the spec needs to be sent via email to the case log when the case is submitted in order to maintain a light-weight email review process. The case owner does this when submitting such cases. In this instance, that wasn't done, and still needs to be done. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: sysevent_evc_setpropnvl and sysevent_evc_getpropnvl [PSARC/2010/257 Self Review]
Cynthia, I've placed this case in waiting need spec since the spec was never sent to the case log. Please do so. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Next Generation BMC Driver [PSARC/2010/252 FastTrack timeout 07/07/2010]
On 07/ 1/10 01:58 PM, Kevin Song wrote: Jim, Please derail PSARC 2009/467 with a note of PSARC 2010/252. Two things: 1. 2009/467 was already approved, and so it cannot be derailed. 2. 2009/467 was a full case, and so it cannot be derailed (derailing is only for fast-tracks that need a full review). I believe what you want is to close 2009/467 as "superceded" by 2010/252. Please work with this case owner (Phi Tran) to get the right thing done (I'm not sure who Jim is). -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Next Generation BMC Driver [PSARC/2010/252 FastTrack timeout 07/07/2010]
On 07/ 1/10 02:43 PM, Kevin Song wrote: On 07/01/10 11:31 AM, Sebastien Roy wrote: On 07/ 1/10 01:58 PM, Kevin Song wrote: Jim, Please derail PSARC 2009/467 with a note of PSARC 2010/252. Two things: 1. 2009/467 was already approved, and so it cannot be derailed. 2. 2009/467 was a full case, and so it cannot be derailed (derailing is only for fast-tracks that need a full review). I believe what you want is to close 2009/467 as "superceded" by 2010/252. Please work with this case owner (Phi Tran) to get the right thing done (I'm not sure who Jim is). Name: Solaris ATCA IPMI Driver Submitter: Kevin Song Owner: Garrett D'Amore Intern: Jim Walker Interest: kevin.s...@sun.com Status: waiting need draft opinion 11/25/2009 Exposure: open Comment: OK, PSARC 2009/467 is not approved yet. I see that now; indeed, an email vote was to take place once spec updates were provided and a draft opinion was written. According to the case log, that hasn't taken place, and so 2009/467 can simply be withdrawn. Perhaps you could send a note to 2009/467 (by including the case number in the subject line) stating that you're withdrawing the case in favor of 2010/252. I'll update the IAM file to reflect that. Jim Walker is the case owner being an intern and I am the submitter. Got it. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Next Generation BMC Driver [PSARC/2010/252 FastTrack timeout 07/07/2010]
On 06/30/10 08:33 PM, Barry Harding wrote: Since our new project will support the functionality covered by the other case (PSARC 2009/467), I think it does obsolete that other case and that it could/should get withdrawn... You cannot withdraw an approved case, but it can be superseded. Please work with the case owner for this case to get the right thing done. Thanks, -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Kerberos Keytab Management API [PSARC/2010/229 FastTrack timeout 06/28/2010]
On 06/30/10 06:29 PM, Shawn Emery wrote: On Jun 30, 2010, at 12:19 PM, Sebastien Roy wrote: A couple of quick questions: 1. What is the release binding? It follows the CIFS project, which I don't know off the top of my head. I don't see how CIFS is relevant to the release binding of this case, it's just a potential consumer of the interfaces introduced. The release binding simply indicates the kind of release the case would hypothetically be applicable to given the level of change introduced. Since this case introduces no incompatible changes, then Patch binding would theoretically be appropriate (hint). 2. I assume that this is a C API. What library does it live Yes, it resides in the preexisting usr/lib/gss/mech_krb5.so.1. Okay. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: IBTF 2010.Q2 Enhancements [PSARC/2010/234 FastTrack timeout 06/30/2010]
+1 -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Kerberos Keytab Management API [PSARC/2010/229 FastTrack timeout 06/28/2010]
A couple of quick questions: 1. What is the release binding? 2. I assume that this is a C API. What library does it live in? If it's a new library, where does it live and as part of what package? Thanks, -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer email vote...
On 06/17/10 09:17 PM, John Fischer wrote: Please review these new materials and the draft opinion. Either provide feedback or vote on the case by COB Wednesday, June 30th, 2010. My vote is "approve". -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: layer-3 net properties for exclusive-IP zones [PSARC/2010/166 FastTrack timeout 05/19/2010]
This case was approved during last week's meeting. Note that the final spec is enclosed in the materials directory. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010]
On 05/12/10 12:01 PM, Sebastien Roy wrote: I'm submitting this fast-track for Mark Haywood. The release binding is Minor. Note that this case has a dependency on PSARC 2010/157. This case was approved at last week's PSARC meeting. Note that the install-specific SMF services and their properties are Uncommitted (spec.txt in the materials directory has been updated), and not Committed as originally proposed. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: TCP receive buffer auto-sizing [PSARC/2010/209 FastTrack timeout 06/14/2010]
On 06/17/10 10:18 AM, Michael Kearney wrote: *+1 *I too was going to request the pfiles change. (I'm just a little slow) Thanks.* * Thanks for the review. The timer having expired, this case is approved. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010]
On 06/17/10 11:21 AM, Garrett D'Amore wrote: On Thu, 2010-06-17 at 10:54 +0100, Darren J Moffat wrote: My only concern is this paragraph: The project team reserves the right to revise the exact list of certificates and/or choose an entirely different source of certifcates at anytime without requiring further ARC review. While ARC may or may not be the best place to review changes to the certificate list (it probably isn't), I think we should like to know how revisions will be made -- i.e. who decides when a change is appropriate and what the change will be? The project team? You? C-Team? P-Team? I think there should be at least *some* review by some group of people when something so important to the security of the underlying system is changed. So I'd like to know more about what is intended here. And I think understanding what this review would be is part of the fundamental architecture of the case, so I think its appropriate to discuss here. It seems to me like this is something that the security team should be able to handle this within the team (i.e. during code-review), and verified during the RTI process. I don't think that this is an architectural issue, much like the specific list of certificates bundled with firefox has never been an architectural issue. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Performance Improvements for libmtmalloc [PSARC/2010/212 FastTrack timeout 06/15/2010]
+1, I have no issues. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: ejabberd instant messaging server [PSARC/2008/340 FastTrack timeout 05/29/2008]
On 06/16/10 11:26 AM, Hillel Lubman wrote: I'm trying to configure ejabberd ... This is off-topic for this mailing list. This purpose of this list is to hold architectural reviews of projects under development. Try desktop-disc...@opensolaris.org. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: 2010/169 EOF lx brand
Hello Nils, On 06/11/10 05:03 PM, Nils Goroll wrote: I just noticed the commit msg for this case. I understand the ARC case is unpublished, but would it be possible to get some basic background information about it? The case synopsis (EOF lx brand) captures most of what is architecturally relevant about this case. As you can also see from the changeset that was just integrated (http://mail.opensolaris.org/pipermail/onnv-notify/2010-June/012350.html), the lx brand has been removed from the current ON consolidation repository under development. If you need any more details, I'd suggest querying the project team, presumably reachable on zones-disc...@opensolaris.org. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer
Neal, On 06/ 9/10 04:45 PM, Neal Pollack wrote: Off Topic Yes indeed. Please ask such questions directly to the appropriate project team members or to a more appropriate mailing list. This external mailing list is for open architecture reviews of specific PSARC cases, and mail sent here is expected to be part of the record of a case's architecture review. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/165 - OpenSolaris Text Installer
On 06/ 9/10 04:38 PM, Alan Coopersmith wrote: It appears the Network Configuration is IPv4 only. Shouldn't we be prepared for IPv6 at this point? The common case for IPv6 will likely be stateless address autoconfiguration, which doesn't require specifying a static IPv6 address. As a result, I would say no question need be asked about IPv6 addresses during an interactive install. The old interactive installer asked a "do you want IPv6 enabled?" question, but at this point, IPv6 should always be "enabled", and the system should automatically get a global address if there is an IPv6 router advertising an IPv6 prefix on the network. This is already true with NWAM today, so perhaps we need to discuss what the installer needs to do to make that happen if it disables network/physical:nwam and enables network/physical:default... Alan, can you add this question to the issues file so that we can remember to cover it in more detail during the review please? Thanks, -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Removal of pwgen from SFW [PSARC/2010/206 FastTrack timeout 06/11/2010]
On 06/ 8/10 01:50 PM, Suhasini Peddada wrote: Hi James, On 06/08/10 10:35 AM, James Carlson wrote: I'm not opposed to the project, but I do think it'd be much simpler if we had a higher-level (say, "architectural") review of the delivery mechanisms themselves. In reviewing the Brownian motion of little open source packages from one repository to another, I think we're really missing the big picture of what the repository inclusion rules are, what things depend on what other things, and ultimately what bits constitute "the system." With that part sorted out, I suspect that we won't need any of these confusing 's/SFW/contrib/' project reviews, because the answers become quite obvious self-reviews (with zero paperwork). Without the big picture, we're down to repeating the same discussion over and over, and producing uneven results when some things fall through without substantial review and others get nit-picked. We went through this trouble once before, back when we larded up SFW with random bits. And when (not "if" but "when") there's another realignment of repositories, we'll have another flurry of confusing and disjoint little projects that really have very little architectural content in themselves. Are you suggesting that we should make it as a project review? Having an umbrella case that covers the overall architectural issues associated with the entire SFW cleanup effort is something that I suggested to this team back in April: http://mail.opensolaris.org/pipermail/opensolaris-arc/2010-April/021083.html The umbrella case review would be a full review (in a meeting), and that would, hopefully, clear the air for the underlying individual cases such as this one (fast-track or self-review). Is there any reason that all of these "FOSS" projects need to be done piecemeal? The only reason I can think of is that not all the pieces involved are owned by one project team member. I don't believe that the composition of the project team nor the schedule of the integrations for these removals is a factor here. There are architectural issues associated with the greater goal associated with these individual projects, and we're not utilizing our time effectively by rehashing these same issues repeatedly. Things like: * Why is /contrib relevant at all to these cases (it's not part of the system's architecture at this moment...)? * Is there a greater goal to integrate /contrib somehow with the system that is relevant to this overall project? * What are the key common criteria for removing things from SFW as part of this greater effort? Let's establish those once and not discuss it again. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: TCP receive buffer auto-sizing [PSARC/2010/209 FastTrack timeout 06/14/2010]
On 06/ 7/10 11:17 AM, Sebastien Roy wrote: I'm submitting this fast-track for Cathy Zhou, timing out on 06/14/2010. The design document referenced below is contained in the materials directory. The project team requests a Minor release binding. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
TCP receive buffer auto-sizing [PSARC/2010/209 FastTrack timeout 06/14/2010]
I'm submitting this fast-track for Cathy Zhou, timing out on 06/14/2010. The design document referenced below is contained in the materials directory. Problem Area TCP, as a protocol widely used for reliable end-to-end network communication, the users must often perform tedious manual optimizations simply to achieve acceptable performance. Among those tasks, one important aspect is to determine and set appropriate socket buffer size to achieve better performance with the limitation of the memory resources. This specific manual task usually requires very experienced administrator or application developers. Also, the dynamic characteristic of the networking environment makes the task even more complicated. Therefore, we identify the needs for an automatically-sizing algorithm in our TCP/IP stack, which can automatically adjust the buffer size based on the current state of each specific connection. The goal is to achieve the preferable transfer rates on each connection out-of-box without manual intervention. Details === After investigating several existing algorithms and doing some experiments with the prototypes, we decided to deploy the DRS (Dynamic Right-Sizing)[1] receive buffer auto-sizing algorithm in Solaris. Basically, DRS tries to let the receiver estimate the sender's congestion window size (cwnd) by measuring the amount of data received over a period of time that is a round-trip time (BDP measurement), and then uses that measurement to dynamically change the size of the receiver's receive buffer. Specifically in Solaris, there are several aspect of the DRS algorithm: - RTT measurement * High-resolution time In today's Solaris, the TCP timestamps option is filled in with low-resolution time unit (llbolt) which has precision of 10ms. This would result in the imprecision of the RTT measurement, which will ultimately results in the over-estimation of the receive buffer size. Therefore, the high-resolution time (I.e., the gethrtime() function) will be used instead to get the current timestamps in our TCP/IP stack. Since gethrtime() returns 64 bits result which is expressed as nanoseconds, the high-resolution time will be right-shifted 20 bits and fit into the 32 bits timestamps option. This assures the time precision of 1ms (1ms is the fastest precision that is required by PAWS[2]), hence prevents overbooking of the receive buffer. * Send-side RTT measurement Solaris today already has the send-side RTT measurement either based on the timestamps option or by observing the time between a packet and its acknowledgment. Note that the send-side averaged RTT will only be used as one source of the RTT measurement when there are more than tcp_tx_rtt_updates (a new TCP property, default is set to 20) RTT samples - when it is statistically useful. * Receive-side RTT measurement Besides the existing send-side RTT measurement, we will add the receive-side RTT measurement as well. We will get the receive-side RTT samples by observing: - the time difference when a timestamps is reflected back from the peer if the timestamps option is enabled; - the time between the acknowledgment of sequence number S which announces receive window W and the receipt of data segment that contains sequence number which is at least S + W + 1. Since the above receive-side RTT sampling acts only as an upper-bound on the RTT, each time we get a sample, the receive-side RTT will be updated to be the minimum of the old receive-side RTT value and the current RTT measurement. Both receive-side RTT and the send-side RTT will be considered as the source of the RTT estimate when they are available. The final RTT will be set as the average of both values. - Receive buffer auto-sizing At the start of the connection, if the receive buffer auto-sizing is enabled for this connection, the receive buffer will be initialized to be tcp_recv_autosize_initmss * MSS (tcp_recv_autosize_initmss is another new TCP property, default is set to 15). This is an attempt to assure the sender to not be receive-window limited during the first RTT. Then each time a packet is received, the current time will be compared to the last measurement time for that connection. If more than the current estimated RTT has passed, the highest sequence number seen is compared to the next sequence number expected at the beginning of the measurement (BDP measurement). The receive buffer size for this connection is then updated, to advertise the receive window (rwnd) that is 3.5 times of the sequence number difference. - Window S
Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 06/14/2010]
On 06/ 7/10 10:23 AM, James Carlson wrote: Sebastien Roy wrote: On 06/ 4/10 09:44 AM, Sebastien Roy wrote: I'll send a note once we have an updated spec. An updated spec (with '+' change marks in the left column) has been placed in the materials directory. Note that the materials update constitutes clarifications and not a change in the architecture as originally proposed. It looks quite a bit clearer, though I do wonder now about the rationale for making these interfaces Committed given the exceptions carved out for future projects. It's a good question, and Mark and I hmm'ed and haa'ed about this a bit prior to submission. As you know, the long term expectation is that parts of this configuration can be supplied using a profile that applies directly to a networking service, and not an intermediary install-specific service. The idea would then be that the installer software (and customers who write profiles directly) would transition away from supplying properties to this install service. At the same time, being that this is currently the only proposed way for administrators to supply such networking configuration, the service and its properties have to be Public and relatively stable. Perhaps Uncommitted would more accurately reflect the project team's intentions.(?) -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 06/14/2010]
On 06/ 4/10 09:44 AM, Sebastien Roy wrote: I'll send a note once we have an updated spec. An updated spec (with '+' change marks in the left column) has been placed in the materials directory. Note that the materials update constitutes clarifications and not a change in the architecture as originally proposed. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: interfaces for basic install network configuration [PSARC/2010/164, FastTrack timeout 05/19/2010]
On 06/ 2/10 01:43 PM, James Carlson wrote: James Carlson wrote: That's the part that still confuses me. I'd expected that, just as installation was "based on" NWAM in OpenSolaris, this would be the pattern for the future as well. And, now, I understand Mark's last reply, where he said: I and the folks working on install don't believe that NWAM is yet functionally complete enough to be the default service for our Enterprise customers. And therefore, we chose to provide install with a mechanism for configuring an initial physical:default configuration. OK; that's the missing bit. It *is* intentionally physical:default, not just for install, but also (potentially) for the running system. The original proposal provided that hint in the XML-encoded profile, but never came out and said it directly. It was a long drive to figure out that this was intentional and not a "bug." Could something to the effect of "for AI, and for the time being, we're expecting to disable NWAM and use physical:default on the installed system" be added to the spec? Yes, I think it would be informative to add this to the spec in order to better understand how these interfaces will be effectively used, along with a note that the upcoming cases that define the specific installers' architectures will be the authoritative reference for how users will directly or indirectly interact with this functionality in the context of solaris install. I'll send a note once we have an updated spec. Thanks, -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: ZFS backup options [PSARC/2010/193 FastTrack timeout 06/02/2010]
On 06/ 2/10 04:08 PM, Tom Erickson wrote: Sebastien Roy wrote: I only have one comment regarding the zfs pool version handling: C.2. Version Compatibility To get the full benefit of the options described in this case, the ZFS pool needs to be at version 22 (received properties) or later. Before that, the following options behave differently: receive -o If the specified property is present in the send stream, it is replaced by the value specified after the -o option, since the sent value cannot be overridden locally. receive -x If the specified property is present in the send stream, it is simply ignored, since it cannot be overridden locally. send -b This option is ignored. Received properties cannot be sent in favor of local settings because the two cannot be distinguished. All datasets appear to have never been received and their settings are sent as original properties. Is there not a concern that the handling of the latter two usages will lead to surprising results if the administrator is not immediately aware of the version of the appropriate pool? Would failing these operations be a viable option? In the 'receive -x' case, the behavior is not surprising. On all pool versions, -x says treat the specified property as if it had been excluded from the send stream. The only difference is that before version 22, the received property value is not saved, but it would not have affected the behavior of the dataset anyway. The effective behavior resulting from receive -x is the same on all pool versions. Since -x is useful on all pool versions, I don't think it makes sense to fail the command before version 22 (that would be more surprising). Okay. In the 'send -b' case, the -b doesn't do anything useful before version 22. The option assumes that we can distinguish received properties, so I think it makes sense to fail the command before version 22. If no one objects, I'll go with Sebastian's suggestion and fail 'send -b' with an error message before version 22. Yes, that makes sense to me. +1 on the case given this clarification. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: ZFS backup options [PSARC/2010/193 FastTrack timeout 06/02/2010]
I only have one comment regarding the zfs pool version handling: C.2. Version Compatibility To get the full benefit of the options described in this case, the ZFS pool needs to be at version 22 (received properties) or later. Before that, the following options behave differently: receive -o If the specified property is present in the send stream, it is replaced by the value specified after the -o option, since the sent value cannot be overridden locally. receive -x If the specified property is present in the send stream, it is simply ignored, since it cannot be overridden locally. send -b This option is ignored. Received properties cannot be sent in favor of local settings because the two cannot be distinguished. All datasets appear to have never been received and their settings are sent as original properties. Is there not a concern that the handling of the latter two usages will lead to surprising results if the administrator is not immediately aware of the version of the appropriate pool? Would failing these operations be a viable option? -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Kernel Keyboard Configuration in SMF [PSARC/2010/183 FastTrack timeout 05/27/2010]
On 05/28/10 03:19 AM, Frank Che wrote: The project team has updated the case material based on the feedback from reviewers. The new material is available as 'spec.txt' in the case material. Changes in the new spec include: 1. use lower case property names. 2. use specific types instead of astring for the new properties. I have extended the timer of this case to 5/31. Please continue your review. To be clear on the disposition of /etc/default/kbd, this file will be made Obsolete in a Patch release and removed in the subsequent Minor+ release, correct? Aside from this minor clarification, +1 on the case given the updated materials. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2009/629 Pluggable TCP Congestion Control
On 05/26/10 01:55 PM, Artem Kachitchkine wrote: I am sponsoring this fasttrack for myself. Timer is set to 06/02/2010. Design document: materials/cong-design.pdf (This case was initially filed as a full case, but at the inception meeting is was decided to convert it to a fasttrack, once the design has been reviewed by the networking group). +1 -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: layer-3 net properties for exclusive-IP zones [PSARC/2010/166 FastTrack timeout 05/19/2010]
Sowmini, On 05/25/10 11:09 AM, sowmini.varad...@oracle.com wrote: here are updates to the documentation that include the RTF_ZONE related changes, as well as those based on Erik's comments about allowing persistent interface configuration management in the non-global zone. Thanks for the update, I've set a new timer on the case to expire on 06/02/2010. One nit below: --- zonecfg.txt 2010/05/19 19:28:37 1.2 +++ zonecfg.txt 2010/05/25 15:08:12 @@ -79,10 +79,20 @@ other zonecfg(1m) resources such as the "physical" datalink. At the same time, the zone boot process will also ensure 'ip-nospoof' protection for the datalink with the specified addresses used as input to the -'allowed-ips' property. The stored nvlist information for 'address' -and 'defrouter' will be retrieved and re-applied in the non-global zone -by the daemon associated with the ip-interface-management service -before any other IP configuration is applied. +'allowed-ips' property. On the first boot of an installed non-global +zone, the stored nvlist information for 'address' will be retrieved by +the ipmgmtd daemon which will create the interface persistently, and +apply the IP addresses non-persistently before any other IP +configuration is applied. On subsequent boots, any IP interface with +persistent configuration in the ipadm data-store will be recreated using +IP address information from the kernel's nvlists set up by zoneadmd. The above semantics will be slightly different in solaris10 branded zones since there are no persistent interface objects in such zones. In such zones, I believe it would be sufficient for ipmgmtd to configure everything non-persistently and let the administrator's hostname. files customize interface parameters appropriately (I believe this should "just work"). -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2010/192 FMLI EOF
On 05/25/10 04:51 PM, Dan Price wrote: On Tue 25 May 2010 at 04:17PM, Sebastien Roy wrote: On 05/25/10 04:01 PM, Dan Price wrote: I am filing this case on behalf of myself. This case completes work begun half a decade ago in PSARC/2005/592, by EOFing the FMLI facility. Given the context of lu going away, this is rather straightforward. +1 Is it sufficiently straightforward that you think I could accelerate the timeout? I'd be happy to not wait a whole week :) We typically require cases to at least stay open for 48hrs to allow the general engineering community to see it before it's approved. I don't have a problem with shortening the timer to at least accomodate that 48hr window. Would that suit you? -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2010/192 FMLI EOF
On 05/25/10 04:01 PM, Dan Price wrote: I am filing this case on behalf of myself. This case completes work begun half a decade ago in PSARC/2005/592, by EOFing the FMLI facility. Given the context of lu going away, this is rather straightforward. +1 -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010]
This case was approved during last week's meeting. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: layer-3 net properties for exclusive-IP zones [PSARC/2010/166 FastTrack timeout 05/19/2010]
On 05/20/10 05:43 AM, Darren Reed wrote: Sebastien Roy wrote: Note to PSARC members: This case times out today. It has received adequate review from members of both the networking and the zones teams, but has yet to receive a +1 from a PSARC member. There's still parallel discussion going on internally (about issues that have not surfaced here and that will result in spec changes), how can anyone +1 it? As we discussed during the meeting yesterday, this case is in waiting-need-spec... -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: layer-3 net properties for exclusive-IP zones [PSARC/2010/166 FastTrack timeout 05/19/2010]
Note to PSARC members: This case times out today. It has received adequate review from members of both the networking and the zones teams, but has yet to receive a +1 from a PSARC member. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: layer-3 net properties for exclusive-IP zones [PSARC/2010/166 FastTrack timeout 05/19/2010]
On 05/13/10 07:32 PM, Edward Pilatowicz wrote: On Thu, May 13, 2010 at 04:10:05PM -0700, Darren Reed wrote: On 13/05/10 01:29 PM, sowmini.varad...@oracle.com wrote: Rishi Srivatsavai is looking into the work entailed to have mac-nospoof enabled for NGZ by default.. just talked to Rishi, and I think it makes sense, as part of that work, to also ensure that the mac address cannot be changed by ifconfig. It really doesn't matter what controls you put on changing any address via ifconfig if hostile behaviour is your concern. As long as I can open a raw socket for a NIC, I can pump whatever I like down the wire. To that end, the "allowed-ips" and "mac-nospoof" filtering in mac are required to prevent hostile behaviour from the local zone because they both actively filter all packets transmitted out of the NIC. This is why I earlier asked about whether or not net-rawaccess could be revoked for such zones. as far as i can tell, if "allowed-ips" and "mac-nospoof" are used to restrict the ip and mac addresses that a zone can use then that's good enough. removing net-rawaccess would be unnecessary because it wouldn't buy us any more protection else. removing net-rawaccess would actually reduce the available functionality in the zone unnecessarily. (for example, the zone could no longer run snoop.) Yes, and I also look at this from a resource management perspective. If I explicitly assign an IP address and a MAC address to a zone, then it implies that I don't want processes in that zone to steal (intentionally or not) the resources of another zone or system and "spoof" another zone or system by using a different address. At least then, if anything does happen on a network as a result of packets transmitted from the zone, it will be accountable. I don't see this as a "hostile behaviour" prevention mechanism, as that problem isn't solvable; it's not a bounded problem at all if you allow any bits to flow out of the confines of the zone's environment. Generally, the scope of the allowed-ips and mac-nospoof protection settings is indeed simply to prevent spoofing, and not to prevent all possible network-based malicious attacks, so those are appropriate mechanisms to accomplish the above goal. This case (and the future case that will propose to enable mac-nospoof for links assigned to non-global zones) is partly about automating the configuration of these settings in a way that they were originally intended (and providing appropriate administrative error semantics). -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010]
On 05/12/10 11:26 AM, Kacheong Poon wrote: Attached please find the updated specification of this case. I've incorporated the comments suggested in the discussion. Note that this case timed out a few days ago and it has not yet received a +1. This is a reminder to members that this spec needs to be reviewed. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010]
I'm changing the status of this case to "waiting need spec" while the project team and other interested parties hold offline discussions on the specifics of this case and its greater context. Thanks to those who reviewed this case and provided constructive input. Please hold further comments until an updated spec is provided, or in the meantime, send your feedback directly to Mark or the install team at caiman-disc...@opensolaris.org (Cc me please). -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010]
On 05/12/10 05:17 PM, Darren Reed wrote: There seems to be a lot of questions about the details on this case, as one of the few remaining PSARC members, There are fifteen PSARC members, twelve of which are currently active (meaning not on sabbatical), but that's beside the point. does this really fall into the "obvious" category that is usually for fast tracks? To me this would seem meaty enough to be a full case... I viewed it as a fast-track when I filed it and still feel that way, but I think there is missing install context. There is also some discussion that needs to occur offline between a few of the interested parties before we can move forward with this case. I'll send a separate note to that effect. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
layer-3 net properties for exclusive-IP zones [PSARC/2010/166 FastTrack timeout 05/19/2010]
I'm submitting this fast-track for Sowmini Varadhan. The release binding is Minor and new zonecfg(1M) properties are Committed. Summary: --- This case proposes a solution for 6944327 need to support address and defrouter resources for exclusive-IP zones Problem Description Typical zone deployments that exist today use shared-IP zones to run applications and services like Apache or Weblogic in the contained environment provided by the shared-IP zone. In these use-cases, the Administrator in the global zone has full control over the networking resources used by the non-global zone. In the common case, networking is simply configured by specifying the IP interface, IP addresses and, optionally, the default routers from zonecfg(1m). The configuration resources thus supplied are then applied for the non-global zone when it is booted, and the non-global zone itself may not modify any of these configuration parameters. However, there is no such simple configuration mechanism for the simple networking use-case in place for exclusive IP zones, which must be configured through sysidcfg, ifconfig, and an assortment of other methods, all of which are not controllable from the global zone, and may not be managed through zonecfg(1m). The addition of many new virtualization and resource management features to Solaris (PSARC 2006/357, PSARC 2005/132 and associated cases) makes Exclusive-IP zones a cleaner and more powerful Zone model than shared-IP zones. Thus, bridging any gaps in the configuration methods for the simple use cases between shared- and exlusive-IP zones is important to ease the transition of shared-IP customer configurations to exclusive-IP. In addition, there are many ongoing projects in the "Zones Networking" effort [ZONES-NET] to facilitate the consolidation of existing Solaris 10 host installations as Solaris 10 Containers. These efforts would leverage from the ability to specify networking resource values for address and default router uniformly for zones using zonecfg(1m). This case proposes support in zonecfg(1m) for 'address' and 'defrouter' properties in the 'net' resource for exclusive-IP zones. The semantics of the values will be the same as with the shared-IP zone definitions that exist today ([PSARC/2002/174], [PSARC/2003/621], [PSARC/2008/057]) When the global-zone specifies the 'address' for an interface via zonecfg(1m), the non-global zone may not use any other addresses for the specified IP Version on that interface. The address information provided via zonecfg(1m) will be used to set up Layer-3 protection [PSARC/2009/436] for the non-global zone during zone-boot to filter out all other addresses for the selected interface. For instance, when zonecfg(1m) has been used in the global-zone to set one or more IPv4 addresses on an interface, an attempt to set an IPv4 address on the interface that is outside the globally defined set will encounter the EPERM failure. Thus ifconfig(1m), ipadm(1m), and associated ioctls will receive this error if they are used within the non-global zone to set addresses that are not in the set that is permitted from the global-zone, and attempts by the non-global zone to turn on forwarding on the interface will also encounter EPERM. Note that IPv4 and IPv6 are considered as independent resources, so that specification of an IPv4 address via zonecfg(1m) does not place any constraints on permissible IPv6 addresses, and vice-versa. Attempts to boot a zone that has already been configured for IP, or has previously customized values for Layer-3 protection [PSARC/2009/436] will fail. Implementation Overview: A brief overview of the implementation is provided here. Note that all interfaces between zoneadmd(1m) and the kernel/zonecfg(1m), are Private interfaces, subject to change in the future. When the non-global zone is booted, zoneadmd(1m) will store the information specified by the 'address' and 'defrouter' properties as nvlists in the kernel following a mechanism similar to that in use today for other zonecfg(1m) resources such as the "physical" datalink. At the same time, the zone boot process will also ensure 'ip-nospoof' protection for the datalink with the specified addresses used as input to the 'allowed-ips' property. The stored nvlist information for 'address' and 'defrouter' will be retrieved and re-applied in the non-global zone by the daemon associated with the ip-interface-management service before any other IP configuration is applied. The GLDv3 layer communicates the set of "allowed-ips" to the IP layer through DLPI notifications. The notification sent is a DL_NOTIFY_IND message of (Project Private) type DL_NOTE_ALLOWED_IPS, sent to the IP clients that have registered for this notification. The payload of the DL_NOTE_ALLOWED_IPS message is the mac_protect_t data-structure introduced by PSARC 2009/436. Receipt of this notification enables the IP layer to track the current set
interfaces for basic install network configuration [PSARC/2010/164 FastTrack timeout 05/19/2010]
I'm submitting this fast-track for Mark Haywood. The release binding is Minor. Note that this case has a dependency on PSARC 2010/157. Background == The Solaris Next installers intend to use SMF properties, and install derived, SMF profiles to customize system configurations. This is driving the requirement that Solaris provide public interfaces, in the form of of SMF properties, which, when consumed, will provide an initial physical network interface configuration and an initial DNS client configuration for the installed system. This case proposes a set of SMF properties that will satisfy the following requirements: 1 - the ability to plumb and assign an IPv4 and/or IPv6 address to a physical interface. 2 - the ability to assign a default route to an IPv4 and/or IPv6 physical interface. 3 - the ability to configure a DNS client with a nameserver list, a search list and a domain. A subsequent ARC case will explain how the installers intend to consume the interfaces during install. Proposal Two new SMF services will be created, svc:/network/install and svc:/network/dns/install. Each of these services will contain properties that will be used by the services to configure an initial physical network interface and/or an initial DNS client configuration. The services will initially be disabled with property values that will not result in any system configuration. As part of install, an SMF profile, enabling the services and containing the appropriate configuration property values for the services, will be applied to the system. On the first reboot following the install, the service start methods will check the properties to see if property values have been assigned. If so, then the services will use these property values to configure the system. The service start methods will terminate after deleting their service properties and disabling the services themselves. The svc:/network/install service will support configuring one IPv4 interface and/or one IPv6 interface and, optionally, a default route reachable by these interfaces. The service will define two property groups, one for an IPv4 interface and one for an IPv6 interface. The service will use its properties and ipadm(1M) to configure the network interfaces. And similarly, the service will use its properties and route(1M) to define a default route. The install_ipv4_interface property group will contain the following properties: name a required property of the property group and will contain the value that will be used as the value of when adding an IPv4 interface address. It has an SMF property type of 'astring'. address_type a required property and will contain the value that will be used to construct the -T option for the ipadm(1M) create-addr sub-command. Therefore, the valid values are “static” or “dhcp”. It has an SMF property type of 'astring'. static_addressonly required with an 'address_type' of “static” and will be used to construct the “local” address for the ipadm(1M) create-addr sub-command. It has an SMF property type of 'net_address_v4'. dhcp_wait optional property that only applies with an 'address_type' of “dhcp”. If defined, then the property value will be used to construct the “-w | forever” portion of the ipadm(1M) create-addr sub-command. It has an SMF property type of 'astring'. default_route an optional property whose value will be used to define a default route using route(1M). In other words, “/usr/sbin/route -p add default default-route -ifp ifname” (where ifname is the interface name portion of the 'name' property). It has an SMF property type of 'net_address_v4'. The install_ipv6_interface property group will contain the following properties: name a required property of the property group and will contain the value that will be used as the value of when adding an IPv6 interface address. It has an SMF property type of 'astring'. address_type a required property and will contain the value that will be used to construct the -T option for the ipadm(1M) create-addr sub-command. Therefore, the valid values are “static” or “addrconf”. It has an SMF property type of 'astring'. static_addressonly required with an 'address_type' of “static” and will be used to construct the “local” address for the ipadm(1M) create-addr sub-command. It has an SMF property type of 'net_address_v6'. interface_id an op
Re: Unified sharing system call [PSARC/2010/154 FastTrack timeout 05/11/2010]
On 05/ 4/10 06:25 PM, Tim Haley wrote: Currently, two system calls and a door are used to publish shares: the nfsys multi-purpose system call to export NFS shares, the sharefs system call to update sharetab and an smbd door to publish SMB shares. libshare has to call the NFS or SMB service once per file system and then it has to call sharefs once per share, which results in 1000's of system calls to publish 1000's of shares. This is a proposal to unify all file sharing via a single system call: sharefs. It is also to support of PSARC 2010/124 (libshare V2), which requires changes to NFS, SMB and ZFS. +1 I think it may be worthwhile to explicitly state that the solaris10 brand won't be impacted by this change (and why not). -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010]
(I'm resending this mail due to evidence that it was not received the first time) I'm submitting this fast-track for Kacheong Poon, timing out on 05/10/2010. The release binding is Patch, and the stability level of new socket options is Committed. This case introduces four TCP level socket options, TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX, and TCP_LINGER2. This case also documents the existing options TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD. TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX - An application can use these three options to change/retrieve respectively the initial, minimum and maximum retransmission timeout values of a TCP connection. The option value is an uint32_t and the unit is millisecond (actual value is rounded up to the nearest clock tick interval). The lower bound of the options is 1ms. The upper bound of TCP_RTO_INITIAL is 20s. And the upper bound of TCP_RTO_MIN and TCP_RTO_MAX is 2 hours. 0 means no change on the timeout value. These options correspond to the private TCP parameters tcp_rexmit_interval_initial, tcp_rexmit_interval_min and tcp_rexmit_interval_max, which control the default values used in an IP stack. The lower and upper bounds of the options are the same as that of the private TCP parameters. Note that these socket options do not change TCP's dynamic RTO calculation. They only set the boundaries and initial value. For example, the default initial RTO is 3s because of "conservative" (meaning it seems to work) reason. It is really not correct since there is no estimation. If an app knows what it is, it is good to let it set the value. There must be a maximum value when TCP exponentially backs off RTO in doing retransmission. It does not make sense to back off without bound. If an app will abort the connection after a fixed time with no response from its peer, it makes sense to allow the app to control the maximum RTO. Otherwise, it may happen that there is no retransmission at all before the app terminates the connection. Similarly, there must be a minimum. RTO calculation may not converge quickly or the algorithm may not work well for certain type of network (*) and may cause false timeout. If an app knows better, it makes sense to let it set the value. TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD - An application can use these two options to change/retrieve the total time a TCP connection spent doing retransmission without getting back an acknowledgment. TCP_CONN_ABORT_THRESHOLD controls this interval before a connection is established. TCP_ABORT_THRESHOLD controls the interval after a connection is established. The option value is an uint32_t and the unit is millisecond (actual value is rounded up to the nearest clock tick interval). The lower bound of TCP_CONN_ABORT_THRESHOLD is 1000ms and the upper bound is UINT32_MAX ms. The lower bound of TCP_ABORT_THRESHOLD is 500ms and the upper bound is UINT32_MAX ms. These options correspond to the private TCP parameters tcp_ip_abort_cinterval and tcp_ip_abort_interval, which control the default values used in an IP stack. The lower and upper bound of the options are the same as that of the private parameters. TCP_LINGER2 --- An application can use this option to change/retrieve the amount of time a closed TCP connection stays in FIN-WAIT-2 state. The option value is an int and the unit is second. The lower bound is 1s and the upper bound is 4294967s (UINT32_MAX/1000). 0 means no change on the value. Negative value is not allowed. This option is introduced to ease porting Linux applications using this option to Solaris. It corresponds to the private TCP parameters tcp_fin_wait_2_flush_interval, which controls the default value used in an IP stack. The unit of this parameter is millisecond, which is different from that of the socket option because the option value unit needs to be the same as in Linux. The lower and upper bound of the option are the same (after unit conversion) as the private TCP parameter. The default value of tcp_fin_wait_2_flush_interval is also changed to 60s. Diff of tcp(7P) *** *** 216,222 --- 216,237 If the local TCP receives no acknowledgements from its peer for a period of time, (for example, if the remote machine crashes), the connection is closed and an error is returned. + The TCP level socket options, TCP_CONN_ABORT_THRESHOLD and + TCP_ABORT_THRESHOLD can be used to change and retrieve this + period of time. The option value is uint32_t and the unit is + millisecond. TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD + control respectively this period before and after a connection + is established. + During this period, TCP tries to retransmit the unacknowledged + data multiple times, each after a timeout. And the timeout + interval is exponentially backed o
Re: PSARC 2010/151 new socket options for TCP timers
(I've Cc'ed Kacheong so that he can reply to the specific questions) On 05/ 5/10 12:42 PM, Garrett D'Amore wrote: I didn't see the mail for this, but I've reviewed the case history on sac.sfbay. I sent it to psarc-...@sun.com on Monday and it indeed seems to have made it to the case log. Perhaps a transient mail problem prevented it from reaching all eventual recipients... I'll let Kacheong reply to the rest. -Seb It seems reasonable, but I do have some questions: 1) Can an ill-behaved application cause bad things to happen to the TCP stack by setting RTO or abort timers too high? I'm specifically thinking that by setting these timers to a large value, that it might be possible to cause out of control consumption of resources or exhaustion of TCP port numbers 2) Perhaps setting some of these values should require a privilege? 3) Ultimately, have the implications of these changes been reviewed from a security standpoint? ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: updated spec for DTrace TCP and UDP providers [PSARC/2010/106]
On 05/ 2/10 05:32 AM, Alan Maguire wrote: As per the subject line, the updated spec is attached for the above fasttrack. In the interim, the project team have worked offline with Kacheong and Darren to address their concerns. We have also incorporated SACK, PMTU and congestion window info into the tcpsinfo_t at Nico's suggestion. Thanks! This update looks good, +1 on the case. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010]
The timer on this case having expired, and the case having received adequate review, I'm marking it as closed approved. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
new socket options for TCP timers [PSARC/2010/151 FastTrack timeout 05/10/2010]
I'm submitting this fast-track for Kacheong Poon, timing out on 05/10/2010. The release binding is Patch, and the stability level of new socket options is Committed. This case introduces four TCP level socket options, TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX, and TCP_LINGER2. This case also documents the existing options TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD. TCP_RTO_INITIAL, TCP_RTO_MIN, TCP_RTO_MAX - An application can use these three options to change/retrieve respectively the initial, minimum and maximum retransmission timeout values of a TCP connection. The option value is an uint32_t and the unit is millisecond (actual value is rounded up to the nearest clock tick interval). The lower bound of the options is 1ms. The upper bound of TCP_RTO_INITIAL is 20s. And the upper bound of TCP_RTO_MIN and TCP_RTO_MAX is 2 hours. 0 means no change on the timeout value. These options correspond to the private TCP parameters tcp_rexmit_interval_initial, tcp_rexmit_interval_min and tcp_rexmit_interval_max, which control the default values used in an IP stack. The lower and upper bounds of the options are the same as that of the private TCP parameters. Note that these socket options do not change TCP's dynamic RTO calculation. They only set the boundaries and initial value. For example, the default initial RTO is 3s because of "conservative" (meaning it seems to work) reason. It is really not correct since there is no estimation. If an app knows what it is, it is good to let it set the value. There must be a maximum value when TCP exponentially backs off RTO in doing retransmission. It does not make sense to back off without bound. If an app will abort the connection after a fixed time with no response from its peer, it makes sense to allow the app to control the maximum RTO. Otherwise, it may happen that there is no retransmission at all before the app terminates the connection. Similarly, there must be a minimum. RTO calculation may not converge quickly or the algorithm may not work well for certain type of network (*) and may cause false timeout. If an app knows better, it makes sense to let it set the value. TCP_CONN_ABORT_THRESHOLD, TCP_ABORT_THRESHOLD - An application can use these two options to change/retrieve the total time a TCP connection spent doing retransmission without getting back an acknowledgment. TCP_CONN_ABORT_THRESHOLD controls this interval before a connection is established. TCP_ABORT_THRESHOLD controls the interval after a connection is established. The option value is an uint32_t and the unit is millisecond (actual value is rounded up to the nearest clock tick interval). The lower bound of TCP_CONN_ABORT_THRESHOLD is 1000ms and the upper bound is UINT32_MAX ms. The lower bound of TCP_ABORT_THRESHOLD is 500ms and the upper bound is UINT32_MAX ms. These options correspond to the private TCP parameters tcp_ip_abort_cinterval and tcp_ip_abort_interval, which control the default values used in an IP stack. The lower and upper bound of the options are the same as that of the private parameters. TCP_LINGER2 --- An application can use this option to change/retrieve the amount of time a closed TCP connection stays in FIN-WAIT-2 state. The option value is an int and the unit is second. The lower bound is 1s and the upper bound is 4294967s (UINT32_MAX/1000). 0 means no change on the value. Negative value is not allowed. This option is introduced to ease porting Linux applications using this option to Solaris. It corresponds to the private TCP parameters tcp_fin_wait_2_flush_interval, which controls the default value used in an IP stack. The unit of this parameter is millisecond, which is different from that of the socket option because the option value unit needs to be the same as in Linux. The lower and upper bound of the option are the same (after unit conversion) as the private TCP parameter. The default value of tcp_fin_wait_2_flush_interval is also changed to 60s. Diff of tcp(7P) *** *** 216,222 --- 216,237 If the local TCP receives no acknowledgements from its peer for a period of time, (for example, if the remote machine crashes), the connection is closed and an error is returned. + The TCP level socket options, TCP_CONN_ABORT_THRESHOLD and + TCP_ABORT_THRESHOLD can be used to change and retrieve this + period of time. The option value is uint32_t and the unit is + millisecond. TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD + control respectively this period before and after a connection + is established. + During this period, TCP tries to retransmit the unacknowledged + data multiple times, each after a timeout. And the timeout + interval is exponentially backed off. The TCP level socket + options, TCP_RTO_INITIAL, TCP_RTO_MIN, and TCP_RT
Re: PSARC/2010/138 - pkgbuild build engine
On 05/ 1/10 08:14 AM, Laszlo (Laca) Peter wrote: Thanks Albert for answering the questions for me :) Agreed on all counts. On Fri, 2010-04-30 at 20:48 -0400, Albert Lee wrote: The initial request in my original comment was for the stability level of the spec file syntax. I would guess that it's relatively stable since you mention below that it has no concept of versioning, and presumably the format has been used for rpm's for Linux for a very long time. Is it Committed, Uncommitted, ...? I have to defer to laca on this one since it's his case. Uncommitted is probably not unreasonable since packages are already forced to stay in lock-step with external changes anyway. Uncommitted sounds good to me. Okay. As I hinted in a prior message, I'm not entirely comfortable with a case exporting an Uncommitted interface without including its specification it in the case materials. If you can include at least the portions that are specific to Solaris as part of the materials (with the knowlege that the remainder is externally specified by Linux RPM) to nail down what the case is actually delivering, that would be welcome. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/138 - pkgbuild build engine
On 04/30/10 08:48 PM, Albert Lee wrote: On Fri, 30 Apr 2010 17:31:44 -0400, Sebastien Roy wrote: What kinds of source URLs are supported (e.g., http://, https://, file://, ftp://, all of the above?)? Does this deal with HTTP proxies? How? pkgtool invokes external wget for missing sources, so this is probably specified by wget. That answers the question, yes. It occurs to me that the command line for pkgsend and wget (and possibly pkgadd) should be in the list of imported interfaces. pkg wget was left Volatile by PSARC/2007/681 (http://arc.opensolaris.org/caselog/PSARC/2007/681/mail has the discussion). Agreed; they are imported interfaces. I think reality has caught up with wget's initial stability level of Volatile (as John Plocher states in 2007/681). I don't think there's much we can do about that here, as I don't think contracts for wget would be productive at all given that it has extensive embedded use elsewhere. PSARC/2008/190 didn't seem to specify a commitment for pkgsend? That can be fixed; the case has only undergone a pre-inception, and so it is to be expected that some pieces are still under-specified. I would assume that it could be no less than Uncommitted, as I believe the IPS project team fully expects that the command would be used by scripts. It indeed needs to be called out as an imported interface for this case. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/138 - pkgbuild build engine
On 04/30/10 04:04 PM, Albert Lee wrote: On Fri, 30 Apr 2010 15:34:19 -0400, Sebastien Roy wrote: On 04/30/10 03:29 PM, Sebastien Roy wrote: A couple of minor questions: The spec file syntax is also conceptually an exported interface, and it needs a stability level. It would be nice if the spec file syntax were part of the materials (I'm guessing it's documented somewhere anyway). The basic syntax is the same as rpmbuild spec files, and pkgbuild includes a set of predefined macros and supports some additional tags (attributes/keywords): http://pkgbuild.sourceforge.net/man.php The initial request in my original comment was for the stability level of the spec file syntax. I would guess that it's relatively stable since you mention below that it has no concept of versioning, and presumably the format has been used for rpm's for Linux for a very long time. Is it Committed, Uncommitted, ...? How will the tools handle a hypothetical syntactic change in the spec file format? Is there versioning built-in to the format? I don't believe a versioning mechanism exists, but one could be constructed based on tags or macros. So the absence of such a hypothetical future tag or macro would indicate an older version. What kinds of source URLs are supported (e.g., http://, https://, file://, ftp://, all of the above?)? Does this deal with HTTP proxies? How? pkgtool invokes external wget for missing sources, so this is probably specified by wget. That answers the question, yes. One more: Can a regular user with basic privileges use these commands to create and publish packages? pkgbuild doesn't need additional privileges to create SVR4 packages or use pkgsend (where restrictions would be dependent on the server). pkgtool is also aware of how to invoke pkgadd for SVR4 packages, and for that pkgadd assumes the "Software Installation" profile. Excellent, thanks. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/138 - pkgbuild build engine
On 04/30/10 03:29 PM, Sebastien Roy wrote: A couple of minor questions: The spec file syntax is also conceptually an exported interface, and it needs a stability level. It would be nice if the spec file syntax were part of the materials (I'm guessing it's documented somewhere anyway). How will the tools handle a hypothetical syntactic change in the spec file format? Is there versioning built-in to the format? What kinds of source URLs are supported (e.g., http://, https://, file://, ftp://, all of the above?)? Does this deal with HTTP proxies? How? One more: Can a regular user with basic privileges use these commands to create and publish packages? -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/138 - pkgbuild build engine
A couple of minor questions: The spec file syntax is also conceptually an exported interface, and it needs a stability level. It would be nice if the spec file syntax were part of the materials (I'm guessing it's documented somewhere anyway). How will the tools handle a hypothetical syntactic change in the spec file format? Is there versioning built-in to the format? What kinds of source URLs are supported (e.g., http://, https://, file://, ftp://, all of the above?)? Does this deal with HTTP proxies? How? -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: lofi(7D) in non global zones [PSARC/2010/144 FastTrack timeout 04/30/2010]
On 04/23/10 10:09 AM, Darren J Moffat wrote: 2. Device visibility ... Within each zone, lofiadm(1m) is only allowed to see, or modify, the nodes it has created. The global zone can access all nodes, however, for example: # lofiadm Block Device File Options /dev/lofi/1 /rpool/zones/ozone/root/var/lofi/lofi_file_736429_44 - ... If the path cannot be resolved from the global zone (for example, it may reside on an NGZ-mounted NFS path), the File column displays "?". When a zone is shut down, all its lofi devices (and any mounts on top) are unmapped and destroyed. As today, only root users may access and modify lofi devices. It wasn't made explicit above, so I'll ask: Can the global zone modify non-global zone nodes in addition to being able to see them via lofiadm? 3. Resource limits Currently, lofi has a limit of 128 devices. Out of curiosity, why does it currently have this limit? This case removes this limit as it is not extendable to the multi-zone case. Instead, the number of lofi devices is restricted by each device's associated taskq: the lofi taskq is created as zsched thread, and the zone resource control max-lwps applies. Are there resources other than threads consumed? More specifically, would there be a need for one to limit the number of lofi devices while not limiting the number of lwps for other purposes? -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
libinetcfg removal [PSARC/2010/142 FastTrack timeout 04/29/2010]
I'm submitting this fast-track for Anurag Maskey. It times out on 04/29/2010. The release binding is Minor. Libinetcfg library removal -- This case removes the libinetcfg library introduced into ON by PSARC/2001/544 as a Consolidation Private library and modified in subsequent PSARC cases. The Brussels II project aka ipadm (PSARC/2009/306) and the updates to it added by PSARC/2010/080 introduced the libipadm library interfaces that are Consolidate Private, and these interfaces supersede the interfaces defined in libinetcfg. The aim was to simplify the library API for managing network interfaces. Currently, there are two consumers of libinetcfg in ON - the nwamd and vrrpd daemons. This project has modified both nwamd and vrrpd to use the libipadm API rather than the libinetcfg API. The libinetcfg library was also used by the NWAM GUI. The contract for this was overlooked by the NWAM Phase 1 (PSARC/2008/532) project and does not exist in the libinetcfg case directory. The GUI used libinetcfg to retrieve addresses and flags for the network interfaces that NWAM was configuring. A bug has been filed for the GUI (http://defect.opensolaris.org/bz/show_bug.cgi?id=15544) to use the getifaddrs(3SOCKET) API (which was also introduced by the Brussels II project) to obtain the interface addresses and flags. This project and the GUI fixes will be coordinated to integrate into the respective gates in the same build. ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 03:07 PM, Norm Jacobs wrote: On 04/21/10 12:37 PM, Sebastien Roy wrote: On 04/21/10 01:19 PM, Bart Smaalders wrote: It seems that someone actually needs to own and maintain contrib for this plan to go forward; right now contrib is not well maintained, and maintainers are not responsive to bugs. Indeed. This case is obviously not unique; there are a significant number of cases coming through the process with the shared goal of vacating the SFW consolidation of software that the project team has identified as being better suited for the /contrib repository. Perhaps it would be productive to have a discussion about this greater goal and the type of infrastructure that is needed to accomplish it. An umbrella case would be a good medium to have such a discussion. -Seb While I agree that the /contrib repository is in need of some care and feeding, it doesn't contain software that is part of the Solaris architecture. As a result, this isn't really the right forum for a discussion of /contrib. Call me confused, but the project team initially brought it up by including this in the case materials: 2. Technical Issues 2.1.Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Areca Backup to interested consumers. A separate and independent project will provide Areca Backup availability through the OpenSolaris /contrib repository. I think there is perhaps general confusion about the relationship between the /contrib repository and the product. Regardless of the /contrib issue, there seems to be some overarching driver for these cases, and I'm suggesting that communicating the overall goal and plan to accomplish it separate would save every individual case from having the same kind of discussion, and would give greater context to these cases. You should be looking at each of these cases on the merit of it's architectural significance to Solaris. The intention of this case and similiar cases is to remove interfaces from the Solaris architecture that don't address a specific architectural need or where it might make sense to address a user requirement outside of the Solaris architecture. The fact that they are being added to /contrib should have little or no bearing on any recommendation you make. Perhaps that's true, but my general point is that this is something that could have been discussed in an umbrella case in order to facilitate the formulation and review of each of these piece-meal removal cases. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Fwd: PSARC/2010/139 - Removing Areca Backup
On 04/21/10 01:19 PM, Bart Smaalders wrote: On 04/21/10 09:14, John Fischer wrote: 2.1. Availability through OpenSolaris /contrib repository The OpenSolaris /contrib repository [1] is a more appropriate mechanism for delivering Areca Backup to interested consumers. A separate and independent project will provide Areca Backup availability through the OpenSolaris /contrib repository. It seems that someone actually needs to own and maintain contrib for this plan to go forward; right now contrib is not well maintained, and maintainers are not responsive to bugs. Indeed. This case is obviously not unique; there are a significant number of cases coming through the process with the shared goal of vacating the SFW consolidation of software that the project team has identified as being better suited for the /contrib repository. Perhaps it would be productive to have a discussion about this greater goal and the type of infrastructure that is needed to accomplish it. An umbrella case would be a good medium to have such a discussion. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: SNAP BE Management [PSARC/2010/059 opinion for review by 04/23/2010]
On 04/21/10 01:27 PM, Jim Walker wrote: (reminder - I extended this until Friday) Here is the opinion for PSARC/2010/059 SNAP BE Management. http://arc.opensolaris.org/caselog/PSARC/2010/059/opinion_draft.txt I request a commitment email vote. Suggestion: Perhaps a subject line starting with "NEED VOTE" would draw more attention. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2010/095 More ksh93 builtins
On 03/31/10 12:19 PM, Garrett D'Amore wrote: The project team has decided to change the proposal to remove the contentious builtins for /usr/gnu. Instead, only /usr/bin and /usr/xpg4,xpg6 utilities are being provided as builtins. As these utilities will hopefully one day be converted to use the same underlying libcmd interface, this should not be contentious. I'm restarting the timeout for one week from today (timeout expires April 7). The revised spec follows. Given that this case is building upon pre-existing built-in architecture, I don't have any issues specific to this case that should hold it up. +1 That said, I think one thread of substance from the lengthy discussion this case spawned relates to the duplicity of code between the commands and their built-in equivalents. This is more a commentary of the implementation of built-ins in general, and not of the specific built-ins introduced by this case. Having architecture introduced to allow a shared implementation (as Garrett hopes will be the case with libcmd above) would be a good thing. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Business use of OpenSolaris: enough to support commercial software?
Ken, This is off-topic for opensolaris-...@opensolaris.org. This mailing list is used by the ARC community to conduct architecture reviews of specific software projects as they go through the development process. It looks like you might have meant to send this to opensolaris-disc...@opensolaris.org. -Seb On 04/20/10 09:26 AM, Ken Mays wrote: Mike, For business, commercial, and 'some' government projects - the answer is YES. Originally, I was working with someone to review Pro/ENGINEER Wildfire 5.0 and CATIA on OpenSolaris. We starting porting over CAD/CAM/CAE and game development/rendering tools to OpenSolaris due to the Nvidia driver support and migrating from older platforms. For daily production usage, those workstations and servers are the most reliable systems to date - all using a officially tested binary release of OpenSolaris. I've used OpenSolaris for various open source and commercial software projects migrated and deploying from Solaris 2.5.1-8/9/10 as well as migrating software from CDE to GNOME/KDE/XFCE/Enlightenment. I can admit that those systems are still considered 'rock solid' and stable for what they were designed for and I can say that knowing that those solutions have 'OpenSolaris inside' to borrow that terminology. As for IHVs/ISVs supporting andusing OpenSolaris for software development projects, it gets down to a HCL/HCTS (http://www.sun.com/bigadmin/hcl/hcts/index.jsp) certification type program in which you have a 'somewhat' stable or tested OS release on various hardware/software test results. So, the 'officially tested binary releases' of OpenSolaris would be the first start - currently meaning OpenSolaris 2009.06 (snv_111b). From there, you'd test your software products in this somewhat tested environment and go from there for your own certification testing. Talk to Oracle about partner programs for ISVs. There is also this website: http://www.oracleisv.com Hope that helps, Ken Mays - Atlanta, GA ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
ipadm hostmodel property [PSARC/2010/127 FastTrack timeout 04/19/2010]
I'm sponsoring this fast-track for Sowmini Varadhan, it times on on
04/19/2010.
ipadm(1m) tunables for setting End-System Model.
Requested release binding: Minor
Summary:
---
This case proposes a solution for
6938553 Support user-friendly ipadm tunables for configuring
end-system model
by adding a new 'hostmodel' property to ipadm(1m).
Details:
The fix for CR 4173841 ("Packet goes out with source IP address of
another interface") provides kernel support for the tunables that
control transmit/receive side behavior for IP packets as defined in
Section 3.3.4.5 of [RFC1122]. In addition to providing tunables for
supporting strong and weak end-system models, the tunables introduced
by CR 4173841 allow for a number of intermediate settings through six
separate permutations for source and destination multihoming tunables
in ndd.
These ndd tunables are low-level knobs that cover many more choices
than the anticipated common use-case, and while they allow for
possible feature additions in the future, the common use-cases should
be made accessible through Stable ipadm tunables.
This case proposes a new "hostmodel" property for the IP module that
can have 3 settings: strong, weak and src-priority. Some sample
incantations for setting the tunable are provided in the Examples
section.
The Stability of the 'hostmodel' property is "Committed".
The semantics for the value of the hostmodel property are
hostmodel semantics
-
strongstrong ES as defined in Section 3.3.4.2 of [RFC
1122]. In particular, this corresponds to the
setting of ip_strict_dst_multihoming = 1 through
ndd, with the additional requirement that packets
originated from the host will only be sent out on
interfaces where the IP source address of the
outgoing packet is an address configured on the
outgoing interface.
weak weak ES as defined in Section 3.3.4.2 of [RFC
1122]. In particular, this is equivalent to
setting ip_strict_dst_multihoming = 0 through ndd
on Solaris 10 and earlier releases.
src-priority Equivalent to the weak end-system model in
receive behavior, i.e., a packet will be accepted
on any interface, as long as the IP destination
of the packet is configured on one of the host's
interfaces. When transmitting a packet, if the
multiple routes for the IP destination in the
packet are available, the system will prefer
routes where the IP source address in the packet
is configured on the outgoing interface. If no
such route is available, the system will fall
back to selecting the "best" route as with the
weak ES case.
Examples
On a machine with addresses
# ipadm show-addr
ADDROBJ TYPE STATEADDR
lo0/v4static ok 127.0.0.1/8
ce0/_astatic ok 20.1.1.124/24
ce1/? dhcp ok 10.8.57.124/24
lo0/v6static ok ::1/128
ce1/? static ok fe80::203:baff:fe75:79a7/10
ce1/? addrconf ok
2002:a08:39f0:1:203:baff:fe75:79a7/64
ce1/? dhcp ok 2001:db8:1:2::4585/128
# ipadm show-prop ip
PROTO PROPERTY PERM CURRENT PERSISTENT DEFAULT POSSIBLE
ipv4 forwarding rw off -- off on,off
ipv4 ttlrw 255 -- 255 1-255
ipv6 forwarding rw off -- off on,off
ipv6 hoplimit rw 255 -- 255 1-255
ipv6 hostmodel rw weak -- weak strong,
src-priority,
weak
ipv4 hostmodel rw weak -- weak strong,
src-priority,
weak
The current settings for hostmodel for IPv4 packets is (default
setting) 'weak'. In this mode, if the currently available IPv4
default routes are:
# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use
Interface
- - --
-
:
default 20.1.1.1 UG1 0
default 10.8.57.248 UG2 8 ce1
:
A packet sent to an offlink destination could be sent to either
20.1.1.1 (through ce1) or to 10.8.57.248 (through ce0) in
Re: dumpadm -d none [PSARC/2010/122 FastTrack timeout 04/15/2010]
On 04/ 8/10 04:46 PM, Eric Taylor wrote: I am sponsoring the following fast-track on behalf of Robert Milkowski. This case introduces a new dumpadm(1m) option for disabling a dump device. This case addresses the RFE: 6910925 want to be able to release ZFS volume used as dump device [...] Currently there is no supported way to disable a dump device once it is configured on a system. An additional option to the dumpadm command is proposed as suggested in the RFE: dumpadm -d none You need to specify a release binding (I would propose Patch) and an interface stability (I would propose Committed). Aside from that, +1. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: exclusive IP for s10c [PSARC/2010/111 FastTrack timeout 04/09/2010]
This case was approved during yesterday's PSARC meeting. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: OpenSolaris ARC Minutes - 04/07/2010
Hello ольга, On 04/ 7/10 01:52 PM, ольга крыжановская wrote: Why was the timer for 2010/095 extended? Discussion has ceased and AFAIK we have consent. Garrett submitted an updated spec which needs to be reviewed (e.g. a +1 from a member is needed to move the case forward). -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC 2010/084 Crypt Bindings for Perl
Wyllys, On 04/ 7/10 02:17 PM, Wyllys Ingersoll wrote: I was unable to call in today, but I believe this case (PSARC 2010/084) has converged and can be approved. There have been no further comments since March 24 and I saw no outstanding issues in the mail logs. If there are no further comments, I will update the status. As was noted in the minutes, this case was approved during the meeting. I also noted during the meeting that we're still waiting for a package name from Hai-May, who stated that whatever it was would be Committed. Please follow-through on that, but indeed, there is no other outstanding issue. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/112 - MAC client API and VNIC API updates
On 04/ 7/10 12:20 PM, Krishna Yenduri wrote: On 04/ 7/10 08:36 AM, Sebastien Roy wrote: On 04/ 5/10 02:47 PM, Krishna Yenduri wrote: It was pointed out to me that this needs to be a fast track since there is a contract. So, I am making this a fast track case with the timer set to 4/9/2010. ... Header files: Consolidation Private Consolidation Private Consolidation Private Consolidation Private The latter three header files are not currently included in any package. I assume that this case delivers these header files as part of some package, presumably pkg:/system/header.(?) Yes. They are delivered in pkg/manifests/system-header.mf. Okay. I am generally concerned about the viability of long term use of these contracted interfaces by another consolidation given that the interfaces are not centralized in any part of the ON source (there's no easy way to place a big warning in the code concerning their consumption by another consolidation), and that these interfaces have recently undergone numerous and drastic changes. Assuming that interfaces remain volatile, this could lead to either unintentional breakage of VirtualBox, or complex version dependencies between VirtualBox and the underlying host OS. This is less of a concern if the interfaces contracted have sedimented somewhat and are more stable than they have been in the recent past. Agreed on the concern. It is for this reason that only a small subset of the interfaces in these header files are part of the contract. Also, we added new interfaces like mac_client_set_maxbw etc. to avoid exposing less stable (project private) interfaces. This could be mitigated in a number of ways in the longer term. Committing to a Public MAC client API and VNIC API would be one solution. Another might be to integrate the Solaris kernel specific portion of VirtualBox into ON. Has either project team considered such options? The longer term solution is a public MAC client API. But, we would like to get more experience with clients before making them public. Okay, +1 on the case. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: PSARC/2010/112 - MAC client API and VNIC API updates
On 04/ 5/10 02:47 PM, Krishna Yenduri wrote: It was pointed out to me that this needs to be a fast track since there is a contract. So, I am making this a fast track case with the timer set to 4/9/2010. ... Header files: Consolidation Private Consolidation Private Consolidation Private Consolidation Private The latter three header files are not currently included in any package. I assume that this case delivers these header files as part of some package, presumably pkg:/system/header.(?) I am generally concerned about the viability of long term use of these contracted interfaces by another consolidation given that the interfaces are not centralized in any part of the ON source (there's no easy way to place a big warning in the code concerning their consumption by another consolidation), and that these interfaces have recently undergone numerous and drastic changes. Assuming that interfaces remain volatile, this could lead to either unintentional breakage of VirtualBox, or complex version dependencies between VirtualBox and the underlying host OS. This is less of a concern if the interfaces contracted have sedimented somewhat and are more stable than they have been in the recent past. This could be mitigated in a number of ways in the longer term. Committing to a Public MAC client API and VNIC API would be one solution. Another might be to integrate the Solaris kernel specific portion of VirtualBox into ON. Has either project team considered such options? -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: Removal of Drools Interfaces [PSARC 2010/107 Fast track timeout 04/07/2010]
On 04/ 2/10 12:05 PM, Garrett D'Amore wrote: This case seeks to remove Uncommitted interfaces from Solaris. These interfaces were originally delivered in anticipation of supporting another project. There has been a change in direction, and these interfaces are no longer needed. The case needs a release binding. Assuming that it's Minor (please confirm), +1 from me. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
exclusive IP for s10c [PSARC/2010/111 FastTrack timeout 04/09/2010]
I'm submitting this fast-track for Baban Kenkre and Rishi Srivatsavai. The timer is set for 04/09/2010. The release binding is Minor. This case adds exclusive IP stack support to Solaris 10 containers. The initial Solaris 10 container case only added support for the shared IP stack model (see PSARC/2009/253). Adding exclusive IP stack support involves identifying which features use user/kernel interfaces that have changed incompatibly between Solaris 10 and now (preventing such features from working correctly in s10c), and implementing techniques described in the Solaris 10 Branded Zone Developer Guide[1] to make them work. Therefore, this case doesn't introduce any new interfaces, but simply describes the architecture introduced to make existing features work in a Solaris 10 container. The design document included in the materials directory [2] contains details of how each feature that comprises exclusive IP stack support is handled by this project. The document also enumerates features that traditionally work in exclusive IP stacks, but that will not be supported even after this project integrates. With the exception of those features, a Solaris 10 branded zone should behave the same way as a native Solaris 10 zone running on Solaris 10. [1] http://hub.opensolaris.org/bin/view/Community+Group+zones/s10brand_dev_guide [2] materials/s10ceval.txt (relative to the case directory) -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: DTrace TCP and UDP providers [PSARC/2010/106 Self Review]
Alan and Adam, On 04/ 2/10 06:53 AM, Alan Maguire wrote: Sorry to be following up again, but I think it would be helpful if I make a specific proposal wrt the additional probes required, especially the tcp close-related probes. I think adding the following set of probes to the original proposal should hopefully address shortcomings in this area in a manner consistent with the connect-* and accept-* probes: Given the discussion this case has generated and the fact that the materials are undergoing change that needs to be reviewed, I would suggest upgrading this to a fast-track. Thanks, -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zfs diff [PSARC/2010/105 FastTrack timeout 04/05/2010]
On 03/29/10 01:24 PM, Nicolas Williams wrote: On Mon, Mar 29, 2010 at 01:17:30PM -0400, Sebastien Roy wrote: Understood, and I see that now. It would indeed make sense to be consistent and have -H for this subcommand as well. Agreed. Do you agree re: backslash-escaping? Yes, but presumably the existing output syntax for -H has already taken that into account, no? The existing syntax appears to use a single tab as a separator. I would hope that a tab within a field would be escaped, and if it's not that should be a bug (otherwise it's not really parsable). I could have filenames with ' -> ' in them that would render the rename output ambiguous to the human eye. I could have filenames with '\n' in the name that would render the output ambiguous to the human eye. My intention wasn't to rathole into some absurd discussion over how to handle ridiculous filenames. My intention is to avoid security problems in consumers of zfs diff. I assert that zfs diff is mostly useful only in connection with scripting. I don't think it's reasonable to expect that zfs diff be useful only "by eye". It has got to be scriptable because for any sufficiently large and active dataset the output of zfs diff will generally be too large to handle "by eye" (sure, you could grep for specific things, but not much beyond that you're scripting). (If zfs diff is only useful for scripting then the -H option is actually unnecessary and zfs diff should always disambiguate pathnames in its output.) I don't think it's only useful for scripting. It makes perfect sense to me to incorporate -H as with other zfs subcommands. Tim, what is your plan regarding this suggestion? -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zfs diff [PSARC/2010/105 FastTrack timeout 04/05/2010]
On 03/29/10 12:33 PM, Nicolas Williams wrote:
On Mon, Mar 29, 2010 at 12:23:56PM -0400, Sebastien Roy wrote:
Is there any escaping of whitespace and non-printable characters in the
pathnames? If not then the above format is ambiguous and cannot be
safely scripted.
Taking a step back here, this subcommand is not the only zfs
subcommand whose output could be subject to parsing by scripts.
Many zfs sub-commands already have a -H option ("Display output in a
form more easily parsed by scripts").
Ah, indeed.
Adding parsable output should be something that is thought-through
for the entire suite of subcommands (and zfs-related commands) so
that there is a uniformly applicable solution. IMO, that's not this
case (although that's ultimately the project team's decision).
Therefore I don't think your argument carries water. My request is not
generalizable because ZFS already has parseable output support.
Understood, and I see that now. It would indeed make sense to be
consistent and have -H for this subcommand as well.
If
you think there is something that is ambiguous to the human eye,
then I think that's in scope.
I could have filenames with ' -> ' in them that would render the rename
output ambiguous to the human eye. I could have filenames with
'\n' in the name that would render the output ambiguous
to the human eye.
My intention wasn't to rathole into some absurd discussion over how to
handle ridiculous filenames.
-Seb
___
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
Re: zfs diff [PSARC/2010/105 FastTrack timeout 04/05/2010]
On 03/29/10 12:34 PM, Steve Mckinty wrote: Sebastien Roy wrote: Taking a step back here, this subcommand is not the only zfs subcommand whose output could be subject to parsing by scripts. Adding parsable output should be something that is thought-through for the entire suite of subcommands (and zfs-related commands) so that there is a uniformly applicable solution. IMO, that's not this case (although that's ultimately the project team's decision). If you think there is something that is ambiguous to the human eye, then I think that's in scope. It's not uncommon to have an additional option to a command (stty -g for example) which produces easily-parsable (and not necessarily easily readable :) ) output for this situation. That's right, but to reiterate, I think that such an option should theoretically apply to more then just the "diff" subcommand. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
Re: zfs diff [PSARC/2010/105 FastTrack timeout 04/05/2010]
On 03/29/10 12:14 PM, Nicolas Williams wrote: On Sun, Mar 28, 2010 at 01:12:16PM -0600, Tim Haley wrote: +If the modification involved a change in the link count of a +file, the change will be expressed as a delta within +parentheses on the modification line. Example outputs are +below: + + M /myfiles/ + M /myfiles/link_to_me (+1) + R /myfiles/rename_me -> /myfiles/renamed + - /myfiles/delete_me + + /myfiles/new_file Is there any escaping of whitespace and non-printable characters in the pathnames? If not then the above format is ambiguous and cannot be safely scripted. There are several ways that you could address that problem, such as escaping (HTML/XML entities? backslash escapes? pick your poison), adding a length field preceding either each path or each path that contains whitespace, or use a multi-line (for renames) format with paths being the last field such that you need only [backslash?-]escape newlines. Probably the simplest answer is backslash-escaping whitespace, since shells can handle that trivially. That is what I recommend. Taking a step back here, this subcommand is not the only zfs subcommand whose output could be subject to parsing by scripts. Adding parsable output should be something that is thought-through for the entire suite of subcommands (and zfs-related commands) so that there is a uniformly applicable solution. IMO, that's not this case (although that's ultimately the project team's decision). If you think there is something that is ambiguous to the human eye, then I think that's in scope. -Seb ___ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
