> On a related note, the materials don't explicitly state the case
> dependencies, but I believe this case has a dependency on PSARC
> 2007/429. Pulling on that case's string, the sweater that would need to
> get backported into a patch gets quickly unraveled. ;-)
An excellent point, and one
> Thanks for the answers. +1 on the case, with the added comment (for the
> record), that it might be a good idea to research the possibility of
> providing trunking/aggregation similar features over IB links. I'd also
> like to see snoop and statistic support on the phys link in the near
> > > It seems like this is a bug in Amber Road, best dealt with there.
> >
> > False.
>
> Can you please elaborate. Why is it OK for Amber road to make
> assumptions about interface naming?
Given that this is an open list, I cannot go into the details of the
Fishworks clustering arch
> It seems like this is a bug in Amber Road, best dealt with there.
False.
> Also, how does this respond in the presence of Clearview Vanity Naming?
Completely orthogonal.
--
meem
> > On 01/ 4/10 08:28 AM, Sebastien Roy wrote:
> >
> > > We have room on the agenda this week and we could simply have a verbal
> > > conversation to bring this fast-track to convergence without necessarily
> > > derailing it. I think such a discussion would be most productive if
> > > Cas
> Its unfortunate that applications use loopback to do their own local
> IPC. Such applications are inherently busted IMO (unless they are
> *intended* to operate over the network as well as locally), since they
> rely on a correct network configuration and wind up utilizing a lot of
> e
> I would love to see an example of current use of AF_INET loopback as an IPC
> mechanism.
Both in.mpathd and dhcpagent use this mechanism. Of course, they are both
networking daemons, but the IPC channel has nothing to do with them being
networking daemons.
--
meem
> I personally don't have any issue with the privilege as defined assuming
> that it's part of the basic privilege set. There would be a fundamental
> problem with the proposal if the problem that needed to be solved by the
> project teem included allowing local network access.
Regardless of
> Sure. But that's true of just about all of the LP bits, particularly
> those things (like this one) in the "basic" privilege set. Anything
> less than "basic" isn't really UNIX anymore.
Yes, but my concern isn't about whether it's UNIX, it's about whether it's
reasonable to expect that an
> > I could see doing this on a subset of well-controlled applications, but
> > what happens when a customer using this facility wants some Sun-supported
> > application that happens to use loopback inet IPC to "work"? Are we going
> > to change the code to accommodate their need, or tell the
> > should not having "network privileges" prevent applications from being
> > used for local purposes? Further, the set of impacted applications will
> > be essentially random based on the whim of the IPC mechanism used by its
> > implementors.
>
> I think what Casper is arguing is that t
> >They are inet sockets as an IPC mechanism that has nothing to do with
> >networking per se. Same with AF_UNIX sockets. That is, this privilege
> >will both prevent use of the network and prevent applications that happen
> >to use loopback and AF_UNIX sockets for IPC from working. We have
> >Further to what Seb said, in general, loopback sockets are treated as an
> >IPC mechanism and may be used by any random set of applications that have
> >no interest in actually using the network. That is, not having the
> >proposed NET_ACCESS privilege may cause random applications to fail
X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid
Reply-To: peter.memishian at sun.com
FCC: MAILED
Further to what Seb said, in general, loopback sockets are treated as an
IPC mechanism and may be used by any random set of applications that have
no interest in actually
There's also a reference to IFF_XRESOLV in if_tcp(7P) that will need to be
removed.
--
meem
ubject: Project Clearview: IPMP Rearchitecture
>
> Submitted by: Peter Memishian
>
> File: PSARC/2007/272/opinion.ms
>
> Date: November 19th, 2008
>
> Committee: Kais Belgaied, James Carlson, Glenn Skinner.
>Abstain:
> The addition of the RCM module is architecture
The existence of RCM and the RCM module framework is architecture; whether
we choose to implement a new RCM module to solve a given problem seems
like an implementation detail to me.
> misconfiguration of VNICs in use by VRRP. Weighing the cost
> Yes, once the VNIC is plumbed, it will not be renamed/deleted. But vrrpd
> cannot be assured that the VNIC is always plumbed when the VRRP router
> is created. Administrators can always unplumb the VNIC whenever they
> want, even the VRRP router that relies on the VNIC is already enabled.
> Not sure whether Meem is following up our discussion here. I will copy
> him on this email and give a summary as below:
>
> In the current VRRP design, once a VRRP router is enabled, we will hold
> the underlying data-link and the VRRP router associated VNIC open, to
> prevent them fro
> Okay, and I was evidently misled by Ted's acknowledgment of my previous
> mail message suggesting both show-linkprop and show-ib output. For the
> record, the proposal is for a show-ib subcommand only, and no link
> properties, right? Can the project team supply an updated proposal
> whic
Some background here: the original draft proposal for this case was for a
set of read-only link properties, which Sowmini and I (and perhaps others)
commented on. I asked Ted/Venki to instead build a show-ib subcommand
because (a) it follows what we've already done with other media and (b) it
see
> Put another way, if you want to change the way link management is done,
> make submit a new case with a specific proposal. Please don't penalize
> this submitter/case for following already established architecture when
> there is no clear alternative.
Again, no one is trying to punish t
> By "release taxonomy," I'm guessing that you're referring to the
> release binding for OpenSolaris. Do we actually have a release
> binding for it yet? Is it a major release? What does "uname -r" say?
This is a serious rathole, but it's obvious we are making some changes for
OpenSolaris t
> I guess some assessment needs to be made of how much scripting users are
> likely to have done based on the current set of linkprops. The current
> names were clearly chosen to be consistent with stats. and older
> drivers' ndd tunables. I think there is some merit in a newer scheme as
> > It seems a shame to clutter the dladm link property space (and thus dladm
> > show-linkprop output) with this sea of related knobs when we could instead
> > use the same syntax that dladm show-ether uses to report this information
> > and have a single "speed-duplex" link property that tak
It seems a shame to clutter the dladm link property space (and thus dladm
show-linkprop output) with this sea of related knobs when we could instead
use the same syntax that dladm show-ether uses to report this information
and have a single "speed-duplex" link property that takes a list -- e.g.:
> > vlink === virtual link
>
> That's right out. These are actual "physical" NIC instances, unlike
> VNICs.
>
> It would be horrible to have "vlinks" that actually behave like NICs
> and "vnics" that behave only like links!
Agreed; vlink would be highly problematic.
We seem to be doin
FWIW, I have to agree with Scott on this one (and I'd earlier made a
similar comment). Everyone seems to agree this is project is a great
idea, and I've little doubt it will be widely used -- so why saddle it
with a name that is a homonym of one of the most basic Unix concepts?
Even "simulink" wo
This case proposes to remove the libdlpi requirement that dlpi_bind(3DLPI)
be issued prior to dlpi_enabnotify(3DLPI). No other changes are proposed.
Since this is a simple change with no impact on backward compatibility and
an immediate need, I'm filing this as "closed approved automatic". Patc
> > So there is a unique pid for each program and thus it can still be pkill'd?
>
> If you start the command as seperate child job (e.g. $ sleep 12345 & #)
> it will always have a seperate pid. But that was not the problem which
> caused CR #6793120 - the process name changed from "sleep 123
> >>> It's fine to make use of the ksh builtin support for various
> >>> commands, but
> >>> can we please learn from the problems that occurred when we
> >>> changed sleep
> >>> to be a builtin recently (e.g. 6793120) and instead create trivial
> >>> wrapper
> >>> *programs* that acc
> > It's fine to make use of the ksh builtin support for various commands, but
> > can we please learn from the problems that occurred when we changed sleep
> > to be a builtin recently (e.g. 6793120) and instead create trivial wrapper
> > *programs* that access the builtin functionality throu
It's fine to make use of the ksh builtin support for various commands, but
can we please learn from the problems that occurred when we changed sleep
to be a builtin recently (e.g. 6793120) and instead create trivial wrapper
*programs* that access the builtin functionality through libshell?
--
me
Unlike many other Unix variants, Solaris draws a clear separation between
an IP interface and a datalink. Which is iftop providing information
about? Further, what APIs does it use to get this information? (I don't
see any mention in the Interfaces section.)
--
meem
I'm sponsoring the following self-review case for the Clearview team.
Requested release binding is minor.
Nevada currently has two paths for in.mpathd: a binary in /usr/lib/inet, and
a
/sbin/in.mpathd symlink. The reasons for this have roots in the bad old days
of static linking. F
> I'm sponsoring this case for myself, timing out 12/23.
This case has timed out without comment, so I'm marking it approved.
--
meem
In the interest of completeness, I have created a "final.materials"
directory which has the same materials as before plus a final High-Level
Design Document. Please note that there are *no* interface changes, only
editorial updates and minor wording corrections. I have also taken the
opportunity
> > ENOMEMInsufficient storage space is available.
>
> Roger-- does this errno of ENOMEM collapse the two malloc errnos
> (ENOMEM and EAGAIN) together? Or is EAGAIN still a possible
> errno return?
Given the ability to DR in memory, what is the practical distinction
between ENOMEM
I'm sponsoring this case for myself, timing out 12/23.
The requested release binding is minor.
The IPQoS ipgpc (IP generic packet classifier) module defines a number of
selectors that can be used to classify packets. Among those selectors is
"if_groupname", which selects all packets associ
> > The vote is to approve this case as described in the commitment
> > materials and for advice to management that the SNMP implementation
> > should be enhanced to support IPMP.
> >
> > Members, please record your vote by replying to this message by
> > 11/19/2008, or by voting in person
> >* Section 4.12: To improve security, the IP filter interaction has been
> > tweaked such that once an IP interface joins a group, it is subject
> > to any filtering rules for the associated IPMP group interface.
>
> and, conversely, when an IP interface leaves the group, it
> >* Section 3.17: To resolve a conflict with the new architecture, IPMP
> > Singleton no longer allows an IP data address to double as an IP test
> > address. More generally, this section has been expanded to cover
> > additional issues we (the Sun Cluster and Clearview te
ARC members,
As you may recall, when PSARC/2007/272 went through PSARC Inception, PSARC
felt the materials were complete enough to vote. However, some aspects of
the proposed architecture had not yet been implemented, and the project
team wanted more time gain experience with the proposed interf
> > > +PERMS
> > > +
> > > +The read/write permissions of the property. The
> > > +value shown is one of "ro" or "rw".
> >
> > A nit, but why "ro" rather than just "r"?
> >
>
> There was no specific reason for choosing "r". I can make it jus
> + PERMS
> +
> + The read/write permissions of the property. The
> + value shown is one of "ro" or "rw".
A nit, but why "ro" rather than just "r"?
--
meem
> I think it's overkill here since xesballoc() is only supposed to be
> consolidation private but I have no problem with the mblk_t being passed
> as an argument. I'll modify my prototype code accordingly.
"Supposed to be" being the key bit; STREAMS message allocation routines
have a track r
> Are you suggesting passing the mblk_t as an argument to free_func? The
> reason that the driver needs to use db_mblk at the moment is that the
> context argument to free_func is free_arg. In my driver code free_arg
> points to my own structure. In that structure I store the dblk_t pointer
> > That may guarantee that the mblk_t is valid, but it's unclear to me how
> > the information in that mblk_t can be safely used by the driver, given
> > that it reflects the processing state (via b_rptr and b_wptr) of some
> > random mblk_t pointing at the given dblk_t.
>
> That's really
> It should be noted that drivers using xesballoc() or desballoc(9F)
> must be careful not to assume references to the original mblk_t
> returned by function will be valid when frtn_t.free_func() is called
> since there is no guarantee that the STREAMS block has not been
> dupb()ed and the or
> >> How should scripts unescape escaped separators?
> >
> > The "read" command handles this for you if you set IFS correctly (and
> > the escape character is \).
>
> hmm ... relying on people to set IFS seems somewhat more error-prone than
> providing an option to specify the field sep
> My one sort of pseudo-general question here is, what are the consumers
> for this dladm output?
Numerous test suites need parseable dladm output. Also, VirtualBox,
virt-manager, and some GNOME utilities consume dladm output, among others.
This case has suffered enough; I'm praying we don'
> > > The bottom line is that we've written a few "kitchen sink" utilities.
> > > That's the first less than ideal thing that we did. Given where we
> > > are, I'm not inclined to approve this case as anything else than a
> > > "one off".
> >
> > As per the subject line, we're really on
> > To bring this back to where it started, the issues are (for PSARC):
> > - given that there will be future work that wants to generate
> > parsable output, do we need an opinion written up (for this case)
> > to serve as the notice of our decision about it or is it sufficient
> > to jus
> The question isn't about discouraging scripting, but rather, how far do
> we want to go to enable people to use a shell script to perform
> something that they really probably should have a better tool for?
Folks, people *are* scripting using our utilities. If someone wants to go
off and
Ack, my reply got kinda garbled by hasty revisions -- one more time:
> > You are right - expecting a common set of code is probably not
> > worthwhile, but having a common grammar/format (IMO) still is.
I think it's worthwhile too, but this case is considerably more modest
in its goals:
> What it sounds like to me, is that you're suggesting that rather than
> utilities automatically use a particular field separator, they should
> use white space (of some kind) unless they're told to use another
> character.
Which (again) doesn't work if you need to have empty fields, which i
> Hmm, this is dladm, so my parser needs to have IFS='|', whilea
> later in my script the one that uses zoneadm needs IFS=: and
> this other place needs eval (but has namespace issues) - except
> on Fridays when the user has a locale != "C" ...
>
> You are right - expecting
> As for the generation code: in my experience, this is harder than it seems
> because (among other things) the APIs one would need depend on the way the
> utility producing the output is structured -- many existing utilities are
> built to print the data a cell at a time, whereas others print
> For the choice of delimiter, if the "read" routines already handle
> the escape sequences AND you are generating all the output, you could
> as easily generate MAC addrs in an escaped form and the consuming
> shell wouldn't need to care. (yes, MAC addrs of the form xx\:yy\:zz
> would show
> > * Use of eval presents a significant security risk: any command
> > where a non-privileged user might gain control over any field's
> > value makes eval as root (say, in an admin script) unsafe.
>
> To avoid this do: a) quote '$', '`' and a few other unsafe ch
> > That works, just set IFS=|
>
> And would dladm quote '|' chars in ESSIDs?
Yes. Please see the original case materials.
--
meem
> > > My definition of parsable input means I can write a script like
> > > this in sh:
> > >
> > > dladm -o state,over | while read a b; do
> > > echo "a=$a,b=$b"
> > > done
> >
> > That works, just set IFS=|
>
> Yes, and maybe you'd like to provide a complete example so tha
> Please explain why using a whitespace character such as tab as the
> delimiter is unworkable.
Because most shells will consolidate multiple consecutive whitespace
fields into a single field. Blank fields become unworkable.
> My definition of parsable input means I can write a script like
This case was approved at this week's PSARC meeting.
--
meem
[ Jeremy forwarded this to me; I never received his original email. ]
> Peter Memishian wrote:
> > # pfiles `pgrep rpc`
> > 100395: /usr/sbin/rpcbind
> > [ ... ]
> > 19: S_IFCHR mode: dev:333,0 ino:44
> > > 20: S_IFCHR mode: dev:333,0 ino:65028 uid:0 gid:0
> rdev:42,35
> > > O_RDWR|O_NONBLOCK FD_CLOEXEC
> > > --> sockname: AF_INET 10.8.57.32 port: 111
> > > --> peername: AF_INET 10.8.57.11 port: 61404
> > > /devices
> > # pfiles `pgrep rpc`
> > 100395: /usr/sbin/rpcbind
> > [ ... ]
> > 19: S_IFCHR mode: dev:333,0 ino:44170 uid:0 gid:0 rdev:105,27
> > O_RDWR
> > /devices/pseudo/tl at 0:ticots
> > 20: S_IFCHR mode: dev:333,
I'm filing this case for myself. The timer expires Wednesday, April 23rd.
Patch binding is requested. Consolidation Private is requested for all
proposed interfaces except for the new pfiles output, which is unstable
(as per pfiles(1M)).
Overview
This cases proposes a new STREAMS i
> When considering what other names were available, all of them appeared to
> be just as bad, if not worse: if_event_t, nif_event_t,
> something_event_t.
What would be wrong with net_if_event_t? Seems in keeping with the rest
of the nomenclature.
My issue is one of consistency: we already co
> > This code is seperable and we will be happy to remove it when it is no
> > longer needed. However, until the GLDv3 API is public (which cannot
> > happen at least until Crossbow integrates), we need this to preserve
> > performance in Nevada.
>
> Once it goes in, it will essentially *n
I see this case has been marked approved without any response to my
comments. Why?
--
meem
> It's not just one driver -- until GLDv3 is published, other third-party
> drivers, such as the Fujitsu ones and the SysKonnect ones will need this
> fastpath to preserve performance.
Sorry, I meant to say "gigabit drivers" above.
--
meem
> > Far far better, IMO, is to "fix" the main driver this case is for
> > (cassini), which architecturally could easily be converted to GLDv3 and
> > bundled into Nevada, and then spend effort to wrap up GLDv3 enough to
> > publish it for 3rd parties.
>
> Completely agree. Adding complex
A nit of sorts, but while we're making naming changes, could we phase out
the "NIC" terminology in favor of "if" (for interface) throughout? For
instance, the following is currently proposed:
typedef enum nic_event {
NE_PLUMB = 1,
NE_UNPLUMB,
> Are dlmgmt upcalls and DLDIOCSETPROP part of GLDv3?
Not part of any to-be-committed API. Sorry, I misread your original
materials and thought this issue was visible to the mac_prop_() APIs.
So I think what you have is fine (though I'd still like to see some
gardening done here later on ;-)
> Then again, we're talking interfaces between dladm/dlmgmt and mac/dld,
> their exposure is so small they are practically project private. I mean,
> aunt Ruth's backyard flower bed is neat and well-kempt, but she's about
> the only person who appreciates it :)
I thought these interfaces w
> >> > This flag indicates that dld should use the provided MAC name
> >> > instead of link ID. Before a device is fully attached, using
> >> > vanity name services for mapping can be problematic.
> >>
> >> So why not always use the macname? Is it to handle VLAN link properties?
> >> If
> PSARC/2007/429 introduced network driver properties that persist across
> system reboot, but not across link plumb/unplumb. This case seeks to
> fix that deficiency.
A nit: plumb/unplumb terminology has generally been restricted to IP
interfaces rather than links (since IP interfaces actuall
[ Apologies for the late follow-up; I've been out. ]
> the latest copy of updated documents for PSARC 2008/171 can
> be found at
>http://opensolaris.org/os/project/brussels/files/nddcompat.txt
>
> This document contains updates from last week's discussion.
I'm a bit confused; the inte
> Why was it made into a hidden file?
We just followed the existing convention with /etc/.syslog_door, which I
think was done to keep grep from tripping over it.
--
meem
> nfs services use a number of files in /etc/svc/volatile.
> Couldn't dlmgmtd use that directory?
We are proposing to use that directory, but we're carving out a
subdirectory to keep things more organized.
--
meem
> My suggestion of using /etc/dladm/ was to avoid the need to start as
> root merely to create /var/run/dladm as a dir owned by the dladm user.
> Cathy has pointed out though that dlmgmtd needs to start as root for
> other reasons though. Given that I think /var/run is a better place
> t
> You end up packaging an empty type f file
That's what we do right now, but it causes problems, hence this fasttrack.
See the original fasttrack email for details.
--
meem
> If NIC capabilities aren't being propagated up so that TCP can
> see them, is there a long term design or plan to correct this?
They are propagated -- e.g. tcp_send_data() -> tcp_send_find_ire_ill() ->
ire_to_ill() will find the ill associated with the ire_stq for the
IRE_CACHE for the given
> Let me try again: If running with uid == 0 (and no privs) is
> what is needed to operate correctly, then running with uid == 0
> (and no privs) is what is needed. My preference would be running
> with uid == dladm (and no privs).
Got it. From the prototype that Cathy
> With respect to the implementation/documentation of this constant,
> I'd like to see talk (in either header comments or documentation)
> about either one of the above refer to the other so that someone
> who downloads opensolaris and goes hunting in for
> things to "tweak" has a clear unde
> > So, in short, is the use of uid 0 with minimal privileges for a
> > non-networked daemon a gating issue? Or could a change (if possible)
> > from uid 0 to the dladm user be done as part of a future case?
>
> If that's what's needed, then that's what's needed ;-)
Which "that" is be
> In most cases we run such daemons as "daemon" (doesn't imply networking or
> not) after it has initialized.
>
> $ ps -fu daemon
> UID PID PPID CSTIME TTY TIME CMD
> daemon 134 1 0 Dec 21 ? 0:10 /usr/lib/crypto/kcfd
> daemon 4701 1 0
> My concern here is simple: is there a hidden rule along the lines
> of MAXLINKNAMELEN must never be greater than LIFNAMSIZ? If there
> is, this should be stated somewhere.
I thought that went without saying -- things wouldn't work otherwise.
The values of these constants and the relationshi
> > 2.5 MAXLINKNAMELEN
> >
> > The MAXLINKNAMELEN constant has been added to , and it
> > defines the longest possible permitted datalink name (including the
> > terminating NULL character.) Its stability level is Committed.
> >
> > Note that the existing DLPI_LINKNAME_MAX constant
> Thanks. And you're aware that this still leaves dlmgmtd
> vulnerable to attack. Running with uid 0 and no effective
> or permitted privileges still means it has read access to
> all root owned files.
Yes, and based on a discussion Cathy and I had yesterday, we think it
This case was approved a this week's PSARC meeting.
--
meem
> > > Why not patch/micro?
> >
> > It's conceivable (though unlikely) that there are customer scripts that
> > parse the contents of the ypservers file and would choke on IP addresses.
>
> But the obvious answer to that is "don't use IP addresses then" -- as
> long as the default behavio
> On Wed, Dec 05, 2007 at 01:22:58PM -0500, Peter Memishian wrote:
> >Release binding is minor.
>
> Why not patch/micro?
It's conceivable (though unlikely) that there are customer scripts that
parse the contents of the ypservers file a
> > I'm sponsoring this change for Paul Wernau; the timer is set for next
> > Wednesday, December 12th.
>
> Ah the content ;-). Interface stability? Release binding?
Doh, I knew I forgot something ;-)
Interface stability is Committed. Release binding is minor.
--
meem
I'm sponsoring this change for Paul Wernau; the timer is set for next
Wednesday, December 12th.
Today, ypinit -c and the /var/yp/binding/`domainname`/ypservers file
that is created by the command require the use of hostnames that are
listed in the local /etc/inet/hosts file. IP addresses a
Since I believe all remaining concerns have now been addressed, and the
revised timeout for this case (set at the PSARC meeting) was yesterday,
I'm marking this case approved.
--
meem
> I would like to have seen being able to issue an
> IP_BROADCAST_TTL require that SO_BROADCAST had been
> issued first. While there is established behaviour
> in our deployed code base that requires SO_BROADCAST
> to be ignored for sending broadcast packets, this
> case introduces a new so
> But I can't help but wonder, with seeing this case and the code
> changes required in ip_input, if the change to DHCP's architecture
> that requires this was actually a good one.
I think the problem is actually the opposite -- too many vendors implement
special-case code to handle DHCP, and
> > > >We do have it for setsockopt(). It affects unicast traffic.
> > >
> > > Is there any dependency between IP_BROADCAST_TTL and
> > > SO_BROADCAST?
> >
> >Given that SO_BROADCAST doesn't actually seem to do anything on Solaris
> >(other than retrieve the value it was set to), there's
1 - 100 of 132 matches
Mail list logo
