From blu@sac.sfbay.sun.com Thu Sep 4 05:03:19 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84C3IkP005340 for ; Thu, 4 Sep 2008 05:03:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84C3Hfc018609; Thu, 4 Sep 2008 05:03:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00C076TIQ400@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Sep 2008 05:03:18 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O002C36THAOC0@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Sep 2008 05:03:17 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84C3Hq7035783; Thu, 04 Sep 2008 05:03:17 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84C3GjB005335; Thu, 04 Sep 2008 05:03:16 -0700 (PDT) Received: (from blu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m84C3GjB005331; Thu, 04 Sep 2008 05:03:16 -0700 (PDT) Date: Thu, 04 Sep 2008 05:03:16 -0700 (PDT) From: Brian Utterback Subject: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] To: PSARC-ext@sun.com Message-id: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 20531 I am sponsoring the following fast-track for Martina Tomisova. This case proposes to integrate the ngrep open-source utility into the ON consolidation. A patch binding is requested. Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Integrate ngrep into Solaris 1.2. Name of Document Author/Supplier: Author: Martina Tomisova 1.3 Date of This Document: 04 September, 2008 4. Technical Description Proposal: Integrate ngrep into Solaris. Detail: ngrep is a tool for ?grepping? specific information in network packets. ngrep strives to provide most of GNU grep's common features, applying them to the network layer. ngrep is a pcap-aware tool that will allow you to specify extended regular or hexadecimal expressions to match against data payloads of packets. It currently recognizes IPv4, TCP, UDP, ICMPv4, IGMP and Raw across Ethernet, PPP, SLIP, FDDI, Token Ring and null interfaces, and understands BPF filter logic in the same fashion as more common packet sniffing tools, such as tcpdump and snoop. The current version of ngrep is 1.45 at the time of this case. Exported Interfaces: SUNWngrep Uncommitted Package name /usr/sbin/ngrep Committed Executable location ngrep Uncommitted Commandline syntax Imported Interfaces: SUNWlibpcap Libraries (libpcap.so) Security: RBAC - Anyone who has a role which contains the Network Management privileges can execute the ngrep as a root. (no SUID bit for all, just line added to /etc/security/exec_attr as for other sniffing tools like snoop). There was an '-R' option that prevents ngrep from dropping the root privileges after it starts the capturing. It could be dangerous (one never knows what will be received from the network). This option has been removed. References: [1] http://ngrep.sourceforge.net/ Author(s) of ngrep: Jordan Ritter [2] 6721123 - Integrate ngrep into Solaris. List of new files: usr/sbin/ngrep usr/share/man/man1m/ngrep.1m 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: on 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open Proposes man page: User Manuals NGREP(1M) NAME ngrep - network grep SYNOPSIS ngrep <-hNXViwqpevxlDtTRM> <-IO pcap_dump > < -n num > < -d dev > < -A num > < -s snaplen > < -S limitlen > < -W normal|byline|single|none > < -c cols > < -P char > < -F file > < match expression > < bpf filter > DESCRIPTION ngrep strives to provide most of GNU grep's common features, applying them to the network layer. ngrep is a pcap-aware tool that will allow you to specify extended regular expres- sions to match against data payloads of packets. It currently recognizes TCP, UDP and ICMP across Ethernet, PPP, SLIP, FDDI and null interfaces, and understands bpf filter logic in the same fashion as more common packet sniffing tools, such as tcpdump(1M) and snoop(1). Ngrep makes no effort to validate input from live or offline sources as it is focused more on performance and handling large amounts of data than protocol correctness, which is most often a fair assumption to make. However, sometimes it matters and thus as a rule ngrep will try to be defensive and drop any root privileges it might have after started catching of packets. OPTIONS -h Display help/usage information. -N Show sub-protocol number along with single-character identifier (useful when observing raw or unknown proto- cols). -X Treat the match expression as a hexadecimal string. See the explanation of match expression below. -V Display version information. -i Ignore case for the regex expression. -w Match the regex expression as a word. *nux Last change: November 2006 1 User Manuals NGREP(1M) -q Be quiet; don't output any information other than packet headers and their payloads (if relevant). -p Don't put the interface into promiscuous mode. -e Show empty packets. Normally empty packets are dis- carded because they have no payload to search. If specified, empty packets will be shown, regardless of the specified regex expression. -v Invert the match; only display packets that don't match. -x Dump packet contents as hexadecimal as well as ASCII. -l Make stdout line buffered. -D When reading pcap_dump files, replay them at their recorded time intervals (mimic realtime). -t Print a timestamp in the form of YYYY/MM/DD HH:MM:SS.UUUUUU everytime a packet is matched. -T Print a timestamp in the form of +S.UUUUUU, indicating the delta between packet matches. -c cols Explicitly set the console width to ``cols''. Note that this is the console width, and not the full width of what ngrep prints out as payloads; depending on the output mode ngrep may print less than ``cols'' bytes per line (indentation). -F file Read in the bpf filter from the specified filename. This is a compatibility option for users familiar with tcpdump. Please note that specifying ``-F'' will over- ride any bpf filter specified on the command-line. *nux Last change: November 2006 2 User Manuals NGREP(1M) -P char Specify an alternate character to signify non-printable characters when displayed. The default is ``.''. -W normal|byline|single|none Specify an alternate manner for displaying packets, when not in hexadecimal mode. The ``byline'' mode honors embedded linefeeds, wrapping text only when a linefeed is encountered. The ``none'' mode doesn't wrap under any circumstance (entire payload is displayed on one line). The ``single'' mode is concep- tually the same as ``none'', except that everything including IP and source/destination header information is all on one line. ``normal'' is the default mode and is only included for completeness. This option is incompatible with ``-x''. -s snaplen Set the bpf caplen to snaplen (default 65536). -S limitlen Set the upper limit on the size of packets that ngrep will look at. Useful for looking at only the first N bytes of packets without changing the BPF snaplen. -I pcap_dump Input file pcap_dump into ngrep. Works with any pcap- compatible dump file format. This option is useful for searching for a wide range of different patterns over the same packet stream. -O pcap_dump Output matched packets to a pcap-compatible dump file. This feature does not interfere with normal output to stdout. -n num Match only num packets total, then exit. -d dev By default ngrep will select a default interface to listen on. Use this option to force ngrep to listen on interface dev. *nux Last change: November 2006 3 User Manuals NGREP(1M) -A num Dump num packets of trailing context after matching a packet. -W normal|byline|none Alter the method by which ngrep displays packet pay- load. ``normal'' mode represents the standard behaviour, ``byline'' instructs ngrep to respect embed- ded linefeeds (useful for observing HTTP transactions, for instance), and ``none'' results in the payload on one single line (useful for scripted processing of ngrep output). -c cols Ignore the detected terminal width and force the column width to the specified size. -P char Change the non-printable character from the default ``.'' to the character specified. match expression A match expression is either an extended regular expression, or if the -X option is specified, a string signifying a hexadecimal value. An extended regular expression follows the rules as implemented by the GNU regex library. Hexadecimal expressions can optionally be preceded by `0x'. E.g., `DEADBEEF', `0xDEADBEEF'. bpf filter Selects a filter that specifies what packets will be dumped. If no bpf filter is given, all IP packets seen on the selected interface will be dumped. Otherwise, only packets for which bpf filter is `true' will be dumped. The bpf filter consists of one or more primitives. Primi- tives usually consist of an id (name or number) preceded by one or more qualifiers. There are three different kinds of qualifier: type qualifiers say what kind of thing the id name or number refers to. Possible types are host, net and port. E.g., `host blort', `net 1.2.3', `port 80'. If there is no type qualifier, host is assumed. dir qualifiers specify a particular transfer direction to *nux Last change: November 2006 4 User Manuals NGREP(1M) and/or from id. Possible directions are src, dst, src or dst and src and dst. E.g., `src foo', `dst net 1.2.3', `src or dst port ftp-data'. If there is no dir qualifier, src or dst is assumed. For `null' link layers (i.e. point to point protocols such as slip) the inbound and outbound qualifiers can be used to specify a desired direction. proto qualifiers are restricted to ip-only protocols. Possi- ble protos are: tcp , udp and icmp. e.g., `udp src foo' or `tcp port 21'. If there is no proto qualifier, all protocols consistent with the type are assumed. E.g., `src foo' means `ip and ((tcp or udp) src foo)', `net bar' means `ip and (net bar)', and `port 53' means `ip and ((tcp or udp) port 53)'. In addition to the above, there are some special `primitive' keywords that don't follow the pattern: gateway, broadcast, less, greater and arithmetic expressions. All of these are described below. More complex filter expressions are built up by using the words and, or and not to combine primitives. E.g., `host blort and not port ftp and not port ftp-data'. To save typ- ing, identical qualifier lists can be omitted. E.g., `tcp dst port ftp or ftp-data or domain' is exactly the same as `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'. dst net net True if the IP destination address of the packet has a network number of net. Net may be either a name from /etc/networks or a network number (see networks(4) for details). src net net True if the IP source address of the packet has a net- work number of net. net net True if either the IP source or destination address of the packet has a network number of net. net net mask mask True if the IP address matches net with the specific netmask. May be qualified with src or dst. net net/len True if the IP address matches net a netmask len bits wide. May be qualified with src or dst. dst port port *nux Last change: November 2006 6 User Manuals NGREP(1M) True if the packet is ip/tcp or ip/udp and has a desti- nation port value of port. The port can be a number or a name used in /etc/services (see tcp(4P) and udp(4P)). If a name is used, both the port number and protocol are checked. If a number or ambiguous name is used, only the port number is checked (e.g., dst port 513 will print both tcp/login traffic and udp/who traffic, and port domain will print both tcp/domain and udp/domain traffic). src port port True if the packet has a source port value of port. port port True if either the source or destination port of the packet is port. Any of the above port expressions can be prepended with the keywords, tcp or udp, as in: Allowable primitives are: dst host host True if the IP destination field of the packet is host, which may be either an address or a name. src host host True if the IP source field of the packet is host. host host True if either the IP source or destination of the packet is host. Any of the above host expressions can be prepended with the keywords, ip, arp, or rarp as in: ip host host which is equivalent to: ether dst ehost *nux Last change: November 2006 5 User Manuals NGREP(1M) True if the ethernet destination address is ehost. Ehost may be either a name from /etc/ethers or a number (see ethers(3N) for numeric format). ether src ehost True if the ethernet source address is ehost. ether host ehost True if either the ethernet source or destination address is ehost. gateway host True if the packet used host as a gateway. I.e., the ethernet source or destination address was host but neither the IP source nor the IP destination was host. Host must be a name and must be found in both /etc/hosts and /etc/ethers. (An equivalent expression is ether host ehost and not host host which can be used with either names or numbers for host / ehost.) tcp src port port which matches only tcp packets whose source port is port. less length True if the packet has a length less than or equal to length. This is equivalent to: len <= length. greater length True if the packet has a length greater than or equal to length. This is equivalent to: len >= length. ip proto protocol True if the packet is an ip packet (see ip(4P)) of pro- tocol type protocol. Protocol can be a number or one of the names tcp, udp or icmp. Note that the identif- iers tcp and udp are also keywords and must be escaped via backslash (\), which is \\ in the C-shell. ip broadcast True if the packet is an IP broadcast packet. It checks for both the all-zeroes and all-ones broadcast conventions, and looks up the local subnet mask. ip multicast True if the packet is an IP multicast packet. *nux Last change: November 2006 7 User Manuals NGREP(1M) ip Abbreviation for: ether proto ip tcp, udp, icmp Abbreviations for: ip proto p where p is one of the above protocols. expr relop expr True if the relation holds, where relop is one of >, <, >=, <=, =, !=, and expr is an arithmetic expression composed of integer constants (expressed in standard C syntax), the normal binary operators [+, -, *, /, &, |], a length operator, and special packet data acces- sors. To access data inside the packet, use the fol- lowing syntax: proto [ expr : size ] Proto is one of ip, tcp, udp or icmp, and indicates the protocol layer for the index operation. The byte offset, relative to the indicated protocol layer, is given by expr. Size is optional and indicates the number of bytes in the field of interest; it can be either one, two, or four, and defaults to one. The length operator, indicated by the keyword len, gives the length of the packet. For example, `ether[0] & 1 != 0' catches all multicast traffic. The expression `ip[0] & 0xf != 5' catches all IP packets with options. The expression `ip[6:2] & 0x1fff = 0' catches only unfragmented datagrams and frag zero of fragmented datagrams. This check is implicitly applied to the tcp and udp index operations. For instance, tcp[0] always means the first byte of the TCP header, and never means the first byte of an inter- vening fragment. Primitives may be combined using: A parenthesized group of primitives and operators (parentheses are special to the Shell and must be escaped). Negation (`!' or `not'). Concatenation (`&&' or `and'). Alternation (`||' or `or'). Negation has highest precedence. Alternation and concatena- tion have equal precedence and associate left to right. Note that explicit and tokens, not juxtaposition, are now required for concatenation. *nux Last change: November 2006 8 User Manuals NGREP(1M) If an identifier is given without a keyword, the most recent keyword is assumed. For example, not host vs and ace is short for not host vs and host ace which should not be confused with not ( host vs or ace ) Expression arguments can be passed to ngrep as either a sin- If an identifier is given without a keyword, the most recent keyword is assumed. For example, not host vs and ace is short for not host vs and host ace which should not be confused with not ( host vs or ace ) Expression arguments can be passed to ngrep as either a sin- gle argument or as multiple arguments, whichever is more convenient. Generally, if the expression contains Shell metacharacters, it is easier to pass it as a single, quoted argument. Multiple arguments are concatenated with spaces before being parsed. DIAGNOSTICS Errors from ngrep, libpcap, and the GNU regex library are all output to stderr. AUTHOR Written by Jordan Ritter . REPORTING BUGS Please report bugs to the ngrep's Sourceforge Bug Tracker, located at http://sourceforge.net/projects/ngrep/ Non-bug, non-feature-request general feedback should be sent to the author directly by email. NOTES ALL YOUR BASE ARE BELONG TO US. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: box; cbp-1 | cbp-1 l | l . ATTRIBUTE TYPE ATTRIBUTE VALUE = Availability SUNWngrep = Interface Stability Uncommitted NOTES Source for ngrep is available on http://opensolaris.org. *nux Last change: November 2006 9 From carlsonj@phorcys.east.sun.com Thu Sep 4 05:17:13 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84CHDxN005995 for ; Thu, 4 Sep 2008 05:17:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84CH9Q0062682 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Thu, 4 Sep 2008 06:17:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00D117GN9L00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 04 Sep 2008 05:17:11 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O002BK7GMAOD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 04 Sep 2008 05:17:11 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m84CH9B6011396; Thu, 04 Sep 2008 08:17:09 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m84CH9s4011393; Thu, 04 Sep 2008 08:17:09 -0400 (EDT) Date: Thu, 04 Sep 2008 08:17:09 -0400 From: James Carlson Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> To: Brian Utterback Cc: PSARC-ext@sun.com Message-id: <18623.53701.713110.298917@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> Status: RO Content-Length: 840 Brian Utterback writes: > Imported Interfaces: > > SUNWlibpcap Libraries (libpcap.so) "Libraries" isn't a stability level. Any idea where this is coming from or what stability it has? For those who haven't used ngrep (and for the larger picture), what's the difference between this utility and tshark or snoop? What does it do that those things don't do, or when might you choose to use one over the other? A quick read through the documentation makes it look mostly equivalent to tshark and snoop ... > NOTES > ALL YOUR BASE ARE BELONG TO US. Great. It comes free with stale gags. :-/ -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From brian.utterback@sun.com Thu Sep 4 06:06:04 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84D648r008388 for ; Thu, 4 Sep 2008 06:06:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84D5xIY003120 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 06:06:04 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00C0J9Q3AQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 07:06:03 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O005BS9Q2WQ50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 07:06:02 -0600 (MDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84D5x63032221; Thu, 04 Sep 2008 09:06:00 -0400 (EDT) Date: Thu, 04 Sep 2008 09:05:59 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <18623.53701.713110.298917@gargle.gargle.HOWL> To: James Carlson Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <48BFDD37.5060102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> <18623.53701.713110.298917@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 619 James Carlson wrote: > Brian Utterback writes: >> Imported Interfaces: >> >> SUNWlibpcap Libraries (libpcap.so) > > "Libraries" isn't a stability level. Any idea where this is coming > from or what stability it has? This was delivered into sfwnv_93 via PSARC 2008/288. Stability level is uncommitted. Is a contract needed here? -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From carlsonj@phorcys.east.sun.com Thu Sep 4 06:20:28 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84DKSeP008681 for ; Thu, 4 Sep 2008 06:20:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84DKOhV012722; Thu, 4 Sep 2008 06:20:27 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00D0JAE29800@brm-avmta-1.central.sun.com>; Thu, 04 Sep 2008 07:20:26 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O005W1AE1WX50@brm-avmta-1.central.sun.com>; Thu, 04 Sep 2008 07:20:25 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m84DKOqr011726; Thu, 04 Sep 2008 09:20:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m84DKORV011723; Thu, 04 Sep 2008 09:20:24 -0400 (EDT) Date: Thu, 04 Sep 2008 09:20:24 -0400 From: James Carlson Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48BFDD37.5060102@sun.com> To: Brian Utterback Cc: PSARC-ext@sun.com, Brian Utterback Message-id: <18623.57496.256474.757804@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> <18623.53701.713110.298917@gargle.gargle.HOWL> <48BFDD37.5060102@sun.com> Status: RO Content-Length: 671 Brian Utterback writes: > > > James Carlson wrote: > > Brian Utterback writes: > >> Imported Interfaces: > >> > >> SUNWlibpcap Libraries (libpcap.so) > > > > "Libraries" isn't a stability level. Any idea where this is coming > > from or what stability it has? > > This was delivered into sfwnv_93 via PSARC 2008/288. Stability level > is uncommitted. > > Is a contract needed here? Possibly not; is this also going via SFW? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Martina.Tomisova@sun.com Thu Sep 4 07:24:36 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84EOZ6k010420 for ; Thu, 4 Sep 2008 07:24:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m84EOWNk022384 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 22:24:35 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00H1HDCWEG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 08:24:32 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O005GFDCUWOA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 08:24:31 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84EOUCj006163 for ; Thu, 04 Sep 2008 14:24:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00201BTPLH00@fe-emea-09.sun.com> (original mail from Martina.Tomisova@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 15:24:30 +0100 (BST) Received: from [129.157.16.195] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00KJ5DCIE970@fe-emea-09.sun.com>; Thu, 04 Sep 2008 15:24:19 +0100 (BST) Date: Thu, 04 Sep 2008 16:24:18 +0200 From: Martina Tomisova Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <18623.57496.256474.757804@gargle.gargle.HOWL> Sender: Martina.Tomisova@sun.com To: James Carlson Cc: Brian Utterback , PSARC-ext@sun.com, Brian Utterback Message-id: <48BFEF92.5020407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> <18623.53701.713110.298917@gargle.gargle.HOWL> <48BFDD37.5060102@sun.com> <18623.57496.256474.757804@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 531 I'm going to integrate it into the SFW. On 09/04/08 15:20, James Carlson wrote: > Brian Utterback writes: >> >> James Carlson wrote: >>> Brian Utterback writes: >>>> Imported Interfaces: >>>> >>>> SUNWlibpcap Libraries (libpcap.so) >>> "Libraries" isn't a stability level. Any idea where this is coming >>> from or what stability it has? >> This was delivered into sfwnv_93 via PSARC 2008/288. Stability level >> is uncommitted. >> >> Is a contract needed here? > > Possibly not; is this also going via SFW? > From brian.utterback@sun.com Thu Sep 4 07:42:16 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84EgG6a010880 for ; Thu, 4 Sep 2008 07:42:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84EgDh5051744 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 08:42:16 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00I1ZE6EHG00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 07:42:14 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00GVZE6BFI20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 07:42:11 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84Eg7lR064733; Thu, 04 Sep 2008 10:42:08 -0400 (EDT) Date: Thu, 04 Sep 2008 10:42:07 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48BFEF92.5020407@Sun.COM> To: Martina Tomisova Cc: James Carlson , PSARC-ext@sun.com, Brian Utterback Message-id: <48BFF3BF.2040404@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> <18623.53701.713110.298917@gargle.gargle.HOWL> <48BFDD37.5060102@sun.com> <18623.57496.256474.757804@gargle.gargle.HOWL> <48BFEF92.5020407@Sun.COM> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 935 My mistake. I wrote down ON in the proposal. I'll update the proposal in the case dir. Martina Tomisova wrote: > I'm going to integrate it into the SFW. > > On 09/04/08 15:20, James Carlson wrote: >> Brian Utterback writes: >>> >>> James Carlson wrote: >>>> Brian Utterback writes: >>>>> Imported Interfaces: >>>>> >>>>> SUNWlibpcap Libraries (libpcap.so) >>>> "Libraries" isn't a stability level. Any idea where this is coming >>>> from or what stability it has? >>> This was delivered into sfwnv_93 via PSARC 2008/288. Stability level >>> is uncommitted. >>> >>> Is a contract needed here? >> >> Possibly not; is this also going via SFW? >> > -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From dwc@spartan.eng.sun.com Thu Sep 4 07:44:18 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84EiHHZ010921 for ; Thu, 4 Sep 2008 07:44:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m84EiGrL000359 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 22:44:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00I0XE9RRX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 07:44:15 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00FIJE9P7O90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 07:44:13 -0700 (PDT) Received: from spartan.eng.sun.com (spartan.SFBay.Sun.COM [129.146.226.64]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84EiCNr058823; Thu, 04 Sep 2008 07:44:12 -0700 (PDT) Received: from spartan.eng.sun.com (localhost [127.0.0.1]) by spartan.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id m84EagkQ007311; Thu, 04 Sep 2008 07:36:42 -0700 (PDT) Received: (from dwc@localhost) by spartan.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id m84Eag2Q007310; Thu, 04 Sep 2008 07:36:42 -0700 (PDT) Date: Thu, 04 Sep 2008 07:36:42 -0700 (PDT) From: Don Cragun Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] To: Martina.Tomisova@sun.com, PSARC-ext@sun.com, blu@sac.sfbay.sun.com Message-id: <200809041436.m84Eag2Q007310@spartan.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 379 >From blu@sac.sfbay.sun.com Thu Sep 4 05:03:19 2008 > >I am sponsoring the following fast-track for Martina Tomisova. This case >proposes to integrate the ngrep open-source utility into the ON consolidation. >A patch binding is requested. > >From Martina.Tomisova@sun.com Thu Sep 4 07:24:36 2008 > >I'm going to integrate it into the SFW. So which is it, ON or SFW? - Don From Martina.Tomisova@sun.com Thu Sep 4 07:52:24 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84EqONf011304 for ; Thu, 4 Sep 2008 07:52:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84EqCeW018158 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 07:52:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00J0ZENA8100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 08:52:22 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O0052ZEN8WQD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 08:52:21 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84EqKN6010285 for ; Thu, 04 Sep 2008 14:52:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00F01DJNP500@fe-emea-09.sun.com> (original mail from Martina.Tomisova@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 15:52:20 +0100 (BST) Received: from [129.157.16.195] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00K9BEMVE990@fe-emea-09.sun.com>; Thu, 04 Sep 2008 15:52:08 +0100 (BST) Date: Thu, 04 Sep 2008 16:52:07 +0200 From: Martina Tomisova Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <18623.53701.713110.298917@gargle.gargle.HOWL> Sender: Martina.Tomisova@sun.com To: James Carlson Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <48BFF617.2060205@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> <18623.53701.713110.298917@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 539 > For those who haven't used ngrep (and for the larger picture), what's > the difference between this utility and tshark or snoop? What does it > do that those things don't do, or when might you choose to use one > over the other? > > A quick read through the documentation makes it look mostly equivalent > to tshark and snoop ... You can see more at this page: http://ngrep.sourceforge.net/usage.html The main advantage of ngrep is that you can easily define (using regular expressions) which packets do you want to catch. Martina From Martina.Tomisova@sun.com Thu Sep 4 07:53:49 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84ErnoX011325 for ; Thu, 4 Sep 2008 07:53:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84ErlvR019035; Thu, 4 Sep 2008 07:53:49 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00J0TEPMBA00@brm-avmta-1.central.sun.com>; Thu, 04 Sep 2008 08:53:46 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O005IBEPKWSC0@brm-avmta-1.central.sun.com>; Thu, 04 Sep 2008 08:53:44 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84Erh8U014246; Thu, 04 Sep 2008 14:53:43 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00801BFKVK00@fe-emea-09.sun.com> (original mail from Martina.Tomisova@Sun.COM); Thu, 04 Sep 2008 15:53:43 +0100 (BST) Received: from [129.157.16.195] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00KCGEP6E990@fe-emea-09.sun.com>; Thu, 04 Sep 2008 15:53:31 +0100 (BST) Date: Thu, 04 Sep 2008 16:53:30 +0200 From: Martina Tomisova Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <200809041436.m84Eag2Q007310@spartan.eng.sun.com> Sender: Martina.Tomisova@sun.com To: Don Cragun Cc: PSARC-ext@sun.com, blu@sac.sfbay.sun.com Message-id: <48BFF66A.2060409@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041436.m84Eag2Q007310@spartan.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 467 SFW, it was a misunderstanding. On 09/04/08 16:36, Don Cragun wrote: >>From blu@sac.sfbay.sun.com Thu Sep 4 05:03:19 2008 >> I am sponsoring the following fast-track for Martina Tomisova. This case >> proposes to integrate the ngrep open-source utility into the ON consolidation. >> A patch binding is requested. >> > >>From Martina.Tomisova@sun.com Thu Sep 4 07:24:36 2008 >> I'm going to integrate it into the SFW. > > So which is it, ON or SFW? > > - Don From Martina.Tomisova@sun.com Fri Sep 5 02:07:58 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8597viR005972 for ; Fri, 5 Sep 2008 02:07:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8597oW5026773 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 17:07:56 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6P00503TD65F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 03:07:54 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6P001U0TD4EJ20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 03:07:53 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8597qPY002482 for ; Fri, 05 Sep 2008 09:07:52 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6P00M01S3XCX00@fe-emea-09.sun.com> (original mail from Martina.Tomisova@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 10:07:52 +0100 (BST) Received: from [129.157.16.195] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6P000WNTCY6YA0@fe-emea-09.sun.com>; Fri, 05 Sep 2008 10:07:47 +0100 (BST) Date: Fri, 05 Sep 2008 11:07:45 +0200 From: Martina Tomisova Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> Sender: Martina.Tomisova@sun.com To: Brian Utterback Cc: PSARC-ext@sun.com Message-id: <48C0F6E1.6040202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 22619 Hi, I'm sorry for the late correction. I have to create the root package for the ngrep too (because of RBAC) so the exported interface has to change from: > Exported Interfaces: > > SUNWngrep Uncommitted Package name > /usr/sbin/ngrep Committed Executable location > ngrep Uncommitted Commandline syntax to: Exported Interfaces: SUNWngrepr Uncommitted Package name SUNWngrepu Uncommitted Package name /usr/sbin/ngrep Committed Executable location ngrep Uncommitted Commandline syntax Enjoy the day, Martina On 09/04/08 14:03, Brian Utterback wrote: > I am sponsoring the following fast-track for Martina Tomisova. This case > proposes to integrate the ngrep open-source utility into the ON consolidation. > A patch binding is requested. > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Integrate ngrep into Solaris > 1.2. Name of Document Author/Supplier: > Author: Martina Tomisova > 1.3 Date of This Document: > 04 September, 2008 > 4. Technical Description > Proposal: > > Integrate ngrep into Solaris. > > Detail: > > ngrep is a tool for ?grepping? specific information in network > packets. ngrep strives to provide most of GNU grep's common > features, applying them to the network layer. ngrep is a > pcap-aware tool that will allow you to specify extended regular > or hexadecimal expressions to match against data payloads of > packets. It currently recognizes IPv4, TCP, UDP, ICMPv4, IGMP > and Raw across Ethernet, PPP, SLIP, FDDI, Token Ring and null > interfaces, and understands BPF filter logic in the same fashion > as more common packet sniffing tools, such as tcpdump and snoop. > The current version of ngrep is 1.45 at the time of this case. > > > > Exported Interfaces: > > SUNWngrep Uncommitted Package name > /usr/sbin/ngrep Committed Executable location > ngrep Uncommitted Commandline syntax > > Imported Interfaces: > > SUNWlibpcap Libraries (libpcap.so) > > Security: > > RBAC - Anyone who has a role which contains the Network > Management privileges can execute the ngrep as a root. (no SUID > bit for all, just line added to /etc/security/exec_attr as for > other sniffing tools like snoop). > > There was an '-R' option that prevents ngrep from dropping the > root privileges after it starts the capturing. It could be > dangerous (one never knows what will be received from the > network). This option has been removed. > > References: > > [1] http://ngrep.sourceforge.net/ > Author(s) of ngrep: Jordan Ritter > [2] 6721123 - Integrate ngrep into Solaris. > > List of new files: > usr/sbin/ngrep > usr/share/man/man1m/ngrep.1m > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > on > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > Proposes man page: > > User Manuals NGREP(1M) > > > > NAME > ngrep - network grep > > > SYNOPSIS > ngrep <-hNXViwqpevxlDtTRM> <-IO pcap_dump > < -n num > < -d > dev > < -A num > < -s snaplen > < -S limitlen > < -W > normal|byline|single|none > < -c cols > < -P char > < -F > file > < match expression > < bpf filter > > > > DESCRIPTION > ngrep strives to provide most of GNU grep's common features, > applying them to the network layer. ngrep is a pcap-aware > tool that will allow you to specify extended regular expres- > sions to match against data payloads of packets. It > currently recognizes TCP, UDP and ICMP across Ethernet, PPP, > SLIP, FDDI and null interfaces, and understands bpf filter > logic in the same fashion as more common packet sniffing > tools, such as tcpdump(1M) and snoop(1). > > Ngrep makes no effort to validate input from live or offline > sources as it is focused more on performance and handling > large amounts of data than protocol correctness, which is > most often a fair assumption to make. However, sometimes it > matters and thus as a rule ngrep will try to be defensive > and drop any root privileges it might have after started > catching of packets. > > > > OPTIONS > -h Display help/usage information. > > > -N Show sub-protocol number along with single-character > identifier (useful when observing raw or unknown proto- > cols). > > > -X Treat the match expression as a hexadecimal string. > See the explanation of match expression below. > > > -V Display version information. > > > -i Ignore case for the regex expression. > > > -w Match the regex expression as a word. > > > > > *nux Last change: November 2006 1 > > > > > > > User Manuals NGREP(1M) > > > > -q Be quiet; don't output any information other than > packet headers and their payloads (if relevant). > > > -p Don't put the interface into promiscuous mode. > > > -e Show empty packets. Normally empty packets are dis- > carded because they have no payload to search. If > specified, empty packets will be shown, regardless of > the specified regex expression. > > > -v Invert the match; only display packets that don't > match. > > > -x Dump packet contents as hexadecimal as well as ASCII. > > > -l Make stdout line buffered. > > > -D When reading pcap_dump files, replay them at their > recorded time intervals (mimic realtime). > > > -t Print a timestamp in the form of YYYY/MM/DD > HH:MM:SS.UUUUUU everytime a packet is matched. > > > -T Print a timestamp in the form of +S.UUUUUU, indicating > the delta between packet matches. > > > > > > > -c cols > Explicitly set the console width to ``cols''. Note > that this is the console width, and not the full width > of what ngrep prints out as payloads; depending on the > output mode ngrep may print less than ``cols'' bytes > per line (indentation). > > > -F file > Read in the bpf filter from the specified filename. > This is a compatibility option for users familiar with > tcpdump. Please note that specifying ``-F'' will over- > ride any bpf filter specified on the command-line. > > > > *nux Last change: November 2006 2 > > > > > > > User Manuals NGREP(1M) > > > > -P char > Specify an alternate character to signify non-printable > characters when displayed. The default is ``.''. > > > -W normal|byline|single|none > Specify an alternate manner for displaying packets, > when not in hexadecimal mode. The ``byline'' mode > honors embedded linefeeds, wrapping text only when a > linefeed is encountered. The ``none'' mode doesn't > wrap under any circumstance (entire payload is > displayed on one line). The ``single'' mode is concep- > tually the same as ``none'', except that everything > including IP and source/destination header information > is all on one line. ``normal'' is the default mode and > is only included for completeness. This option is > incompatible with ``-x''. > > > -s snaplen > Set the bpf caplen to snaplen (default 65536). > > > -S limitlen > Set the upper limit on the size of packets that ngrep > will look at. Useful for looking at only the first N > bytes of packets without changing the BPF snaplen. > > > -I pcap_dump > Input file pcap_dump into ngrep. Works with any pcap- > compatible dump file format. This option is useful for > searching for a wide range of different patterns over > the same packet stream. > > > -O pcap_dump > Output matched packets to a pcap-compatible dump file. > This feature does not interfere with normal output to > stdout. > > > -n num > Match only num packets total, then exit. > > > -d dev > By default ngrep will select a default interface to > listen on. Use this option to force ngrep to listen on > interface dev. > > > > > > *nux Last change: November 2006 3 > > > > > > > User Manuals NGREP(1M) > > > > -A num > Dump num packets of trailing context after matching a > packet. > > > -W normal|byline|none > Alter the method by which ngrep displays packet pay- > load. ``normal'' mode represents the standard > behaviour, ``byline'' instructs ngrep to respect embed- > ded linefeeds (useful for observing HTTP transactions, > for instance), and ``none'' results in the payload on > one single line (useful for scripted processing of > ngrep output). > > > -c cols > Ignore the detected terminal width and force the column > width to the specified size. > > > -P char > Change the non-printable character from the default > ``.'' to the character specified. > > > match expression > A match expression is either an extended regular > expression, or if the -X option is specified, a string > signifying a hexadecimal value. An extended regular > expression follows the rules as implemented by the GNU > regex library. Hexadecimal expressions can optionally > be preceded by `0x'. E.g., `DEADBEEF', `0xDEADBEEF'. > > > bpf filter > Selects a filter that specifies what packets will be > dumped. If no bpf filter is given, all IP packets seen > on the selected interface will be dumped. Otherwise, > only packets for which bpf filter is `true' will be > dumped. > > The bpf filter consists of one or more primitives. Primi- > tives usually consist of an id (name or number) preceded by > one or more qualifiers. There are three different kinds of > qualifier: > > type qualifiers say what kind of thing the id name or number > refers to. Possible types are host, net and port. > E.g., `host blort', `net 1.2.3', `port 80'. If there > is no type qualifier, host is assumed. > > dir qualifiers specify a particular transfer direction to > > > > *nux Last change: November 2006 4 > > > > > > > User Manuals NGREP(1M) > > > > and/or from id. Possible directions are src, dst, src > or dst and src and dst. E.g., `src foo', `dst net > 1.2.3', `src or dst port ftp-data'. If there is no dir > qualifier, src or dst is assumed. For `null' link > layers (i.e. point to point protocols such as slip) the > inbound and outbound qualifiers can be used to specify > a desired direction. > > proto > qualifiers are restricted to ip-only protocols. Possi- > ble protos are: tcp , udp and icmp. e.g., `udp src > foo' or `tcp port 21'. If there is no proto qualifier, > all protocols consistent with the type are assumed. > E.g., `src foo' means `ip and ((tcp or udp) src foo)', > `net bar' means `ip and (net bar)', and `port 53' means > `ip and ((tcp or udp) port 53)'. > > In addition to the above, there are some special `primitive' > keywords that don't follow the pattern: gateway, broadcast, > less, greater and arithmetic expressions. All of these are > described below. > > More complex filter expressions are built up by using the > words and, or and not to combine primitives. E.g., `host > blort and not port ftp and not port ftp-data'. To save typ- > ing, identical qualifier lists can be omitted. E.g., `tcp > dst port ftp or ftp-data or domain' is exactly the same as > `tcp dst port ftp or tcp dst port ftp-data or tcp dst port > domain'. > dst net net > True if the IP destination address of the packet has a > network number of net. Net may be either a name from > /etc/networks or a network number (see networks(4) for > details). > > > src net net > True if the IP source address of the packet has a net- > work number of net. > > > net net > True if either the IP source or destination address of > the packet has a network number of net. > > > net net mask mask > True if the IP address matches net with the specific > netmask. May be qualified with src or dst. > > > net net/len > True if the IP address matches net a netmask len bits > wide. May be qualified with src or dst. > > > dst port port > > > > *nux Last change: November 2006 6 > > > > > > > User Manuals NGREP(1M) > > > > True if the packet is ip/tcp or ip/udp and has a desti- > nation port value of port. The port can be a number or > a name used in /etc/services (see tcp(4P) and udp(4P)). > If a name is used, both the port number and protocol > are checked. If a number or ambiguous name is used, > only the port number is checked (e.g., dst port 513 > will print both tcp/login traffic and udp/who traffic, > and port domain will print both tcp/domain and > udp/domain traffic). > > > src port port > True if the packet has a source port value of port. > > > port port > True if either the source or destination port of the > packet is port. Any of the above port expressions can > be prepended with the keywords, tcp or udp, as in: > > Allowable primitives are: > > > dst host host > True if the IP destination field of the packet is host, > which may be either an address or a name. > > > src host host > True if the IP source field of the packet is host. > > > host host > True if either the IP source or destination of the > packet is host. Any of the above host expressions can > be prepended with the keywords, ip, arp, or rarp as in: > ip host host > which is equivalent to: > > > > ether dst ehost > > > > *nux Last change: November 2006 5 > > > > > > > User Manuals NGREP(1M) > > > > True if the ethernet destination address is ehost. > Ehost may be either a name from /etc/ethers or a number > (see ethers(3N) for numeric format). > > ether src ehost > True if the ethernet source address is ehost. > > ether host ehost > True if either the ethernet source or destination > address is ehost. > > > gateway host > True if the packet used host as a gateway. I.e., the > ethernet source or destination address was host but > neither the IP source nor the IP destination was host. > Host must be a name and must be found in both > /etc/hosts and /etc/ethers. (An equivalent expression > is > ether host ehost and not host host > which can be used with either names or numbers for host > / ehost.) > > > tcp src port port > which matches only tcp packets whose source port is > port. > > > less length > True if the packet has a length less than or equal to > length. This is equivalent to: > len <= length. > > > greater length > True if the packet has a length greater than or equal > to length. This is equivalent to: > len >= length. > > > ip proto protocol > True if the packet is an ip packet (see ip(4P)) of pro- > tocol type protocol. Protocol can be a number or one > of the names tcp, udp or icmp. Note that the identif- > iers tcp and udp are also keywords and must be escaped > via backslash (\), which is \\ in the C-shell. > > > ip broadcast > True if the packet is an IP broadcast packet. It > checks for both the all-zeroes and all-ones broadcast > conventions, and looks up the local subnet mask. > > > ip multicast > True if the packet is an IP multicast packet. > > > > *nux Last change: November 2006 7 > > > > > > > User Manuals NGREP(1M) > > > > ip Abbreviation for: > ether proto ip > > tcp, udp, icmp > Abbreviations for: > ip proto p > where p is one of the above protocols. > > expr relop expr > True if the relation holds, where relop is one of >, <, > >=, <=, =, !=, and expr is an arithmetic expression > composed of integer constants (expressed in standard C > syntax), the normal binary operators [+, -, *, /, &, > |], a length operator, and special packet data acces- > sors. To access data inside the packet, use the fol- > lowing syntax: > proto [ expr : size ] > Proto is one of ip, tcp, udp or icmp, and indicates the > protocol layer for the index operation. The byte > offset, relative to the indicated protocol layer, is > given by expr. Size is optional and indicates the > number of bytes in the field of interest; it can be > either one, two, or four, and defaults to one. The > length operator, indicated by the keyword len, gives > the length of the packet. > > For example, `ether[0] & 1 != 0' catches all multicast > traffic. The expression `ip[0] & 0xf != 5' catches all > IP packets with options. The expression `ip[6:2] & > 0x1fff = 0' catches only unfragmented datagrams and > frag zero of fragmented datagrams. This check is > implicitly applied to the tcp and udp index operations. > For instance, tcp[0] always means the first byte of the > TCP header, and never means the first byte of an inter- > vening fragment. > > Primitives may be combined using: > > A parenthesized group of primitives and operators > (parentheses are special to the Shell and must be > escaped). > > Negation (`!' or `not'). > > Concatenation (`&&' or `and'). > > Alternation (`||' or `or'). > > Negation has highest precedence. Alternation and concatena- > tion have equal precedence and associate left to right. > Note that explicit and tokens, not juxtaposition, are now > required for concatenation. > > > > *nux Last change: November 2006 8 > > > > > > > User Manuals NGREP(1M) > > > > If an identifier is given without a keyword, the most recent > keyword is assumed. For example, > not host vs and ace > is short for > not host vs and host ace > which should not be confused with > not ( host vs or ace ) > > Expression arguments can be passed to ngrep as either a sin- > > If an identifier is given without a keyword, the most recent > keyword is assumed. For example, > not host vs and ace > is short for > not host vs and host ace > which should not be confused with > not ( host vs or ace ) > > Expression arguments can be passed to ngrep as either a sin- > gle argument or as multiple arguments, whichever is more > convenient. Generally, if the expression contains Shell > metacharacters, it is easier to pass it as a single, quoted > argument. Multiple arguments are concatenated with spaces > before being parsed. > > > DIAGNOSTICS > Errors from ngrep, libpcap, and the GNU regex library are > all output to stderr. > > > AUTHOR > Written by Jordan Ritter . > > > REPORTING BUGS > Please report bugs to the ngrep's Sourceforge Bug Tracker, > located at > > http://sourceforge.net/projects/ngrep/ > > Non-bug, non-feature-request general feedback should be sent > to the author directly by email. > > > NOTES > ALL YOUR BASE ARE BELONG TO US. > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > box; cbp-1 | cbp-1 l | l . ATTRIBUTE TYPE ATTRIBUTE VALUE = > Availability SUNWngrep = Interface Stability Uncommitted > > NOTES > Source for ngrep is available on http://opensolaris.org. > > > > > > > > > *nux Last change: November 2006 9 > From Darren.Moffat@Sun.COM Fri Sep 5 02:43:43 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m859hh7M006284 for ; Fri, 5 Sep 2008 02:43:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m859hZm0019359 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 10:43:41 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6P00L03V0TIZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 02:43:41 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6P00CLRV0SKD90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 02:43:41 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m859hdF5008588 for ; Fri, 05 Sep 2008 09:43:39 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6P00401TQX6V00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 10:43:39 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6P006NYV0O0JB0@fe-emea-10.sun.com>; Fri, 05 Sep 2008 10:43:37 +0100 (BST) Date: Fri, 05 Sep 2008 10:43:36 +0100 From: Darren J Moffat Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C0F6E1.6040202@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Martina Tomisova Cc: Brian Utterback , PSARC-ext@Sun.COM Message-id: <48C0FF48.3060502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> <48C0F6E1.6040202@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080811) Status: RO Content-Length: 688 Martina Tomisova wrote: > Hi, > > I'm sorry for the late correction. I have to create the root package for > the ngrep too (because of RBAC) so the exported interface has to change > from: I recommend you don't do this but instead just integrate the one line change to the master exec_attr.txt file in ON. That avoids having a SUNWngrepr just for the purposes of running the class action script to add that entry to exec_attr. There is no harm done by having the /usr/bin/ngrep entry in exec_attr when the SUNWngrep package is not installed. The equivalent thing could occur with exec_attr is retrieved from a remote nameservice (NIS,NIS+,LDAP) anyway. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Fri Sep 5 04:31:01 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85BV0qn007897 for ; Fri, 5 Sep 2008 04:31:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m85BUxwV049879; Fri, 5 Sep 2008 05:30:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6P00305ZZKF100@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Sep 2008 04:30:56 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6P00CYFZZJKCE0@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Sep 2008 04:30:56 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m85BUsO7016428; Fri, 05 Sep 2008 07:30:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m85BUs2R016425; Fri, 05 Sep 2008 07:30:54 -0400 (EDT) Date: Fri, 05 Sep 2008 07:30:54 -0400 From: James Carlson Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48BFF617.2060205@Sun.COM> To: Martina Tomisova Cc: Brian Utterback , PSARC-ext@sun.com Message-id: <18625.6254.592369.975341@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> <18623.53701.713110.298917@gargle.gargle.HOWL> <48BFF617.2060205@Sun.COM> Status: RO Content-Length: 1933 Martina Tomisova writes: > > For those who haven't used ngrep (and for the larger picture), what's > > the difference between this utility and tshark or snoop? What does it > > do that those things don't do, or when might you choose to use one > > over the other? > > > > A quick read through the documentation makes it look mostly equivalent > > to tshark and snoop ... > > You can see more at this page: http://ngrep.sourceforge.net/usage.html > > The main advantage of ngrep is that you can easily define (using regular > expressions) which packets do you want to catch. This is an interesting case. If we were trying to build a coherent system, I'd strongly argue that the minimal extra bit of matching syntax and functionality that's added here (above the other estabilished utilities) ought to be integrated as an extension to at least wireshark, so that the user wouldn't just have ngrep's primitive output format, but would also have access to the more powerful display that wireshark provides. Though there are useful tasks that it can perform, having ngrep as a stand-alone utility makes little sense to me, as it doesn't quite function as a stream filter for packets, so it's an architectural point solution rather than a building block. (It seems one couldn't do the rough equivalent of "ngrep | wireshark" to compose these two things together.) But if all we're doing is integrating random things that someone found useful somewhere, then I guess architectural matters about how it all fits together are much less important. We'll just end up with a profusion of similar-but-not-quite-the-same features with functional gaps between them. So, drive on. I've finished with my concern. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Martina.Tomisova@sun.com Fri Sep 5 05:12:03 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85CC3SO009354 for ; Fri, 5 Sep 2008 05:12:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m85CC1mE061493 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 06:12:02 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00J011W0NI00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 05:12:00 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q003M41VYU0E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 05:12:00 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85CBwSa028856 for ; Fri, 05 Sep 2008 12:11:58 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q005011S01Z00@fe-emea-09.sun.com> (original mail from Martina.Tomisova@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 13:11:58 +0100 (BST) Received: from [129.157.16.195] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q00LMP1VCWR60@fe-emea-09.sun.com>; Fri, 05 Sep 2008 13:11:37 +0100 (BST) Date: Fri, 05 Sep 2008 14:11:36 +0200 From: Martina Tomisova Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] Sender: Martina.Tomisova@sun.com To: Darren J Moffat , Brian Utterback , PSARC-ext@sun.com Message-id: <48C121F8.9060702@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_/Dls5icIt3FDBS60Obvcpw)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 76514 This is a multi-part message in MIME format. --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Darren, there was a quite long discussion (see attachment) with Norm Jacobs and Mike Sullivan about this topic. The final recommendation for me was to user class action script. (The first recommendation was the same as you recommend to me from sustaining gatekeepers. Then I've received the recommendation from gatekeepers that I should use the class action script and sustaining gatekeepers changed their minds and also recommended this to me. Now you are recommending to me the opposite solution. I'm confused now :) Have a nice day, Martina On 09/05/08 11:43, Darren J Moffat wrote: > Martina Tomisova wrote: >> Hi, >> >> I'm sorry for the late correction. I have to create the root package >> for the ngrep too (because of RBAC) so the exported interface has to >> change from: > > I recommend you don't do this but instead just integrate the one line > change to the master exec_attr.txt file in ON. That avoids having a > SUNWngrepr just for the purposes of running the class action script to > add that entry to exec_attr. > > There is no harm done by having the /usr/bin/ngrep entry in exec_attr > when the SUNWngrep package is not installed. The equivalent thing could > occur with exec_attr is retrieved from a remote nameservice > (NIS,NIS+,LDAP) anyway. > --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; name="Attached Message Part" Content-transfer-encoding: 7BIT Content-disposition: inline; filename="Attached Message Part" Content-id: Content-type: message/rfc822; CHARSET=US-ASCII Content-description: Forwarded Message Return-path: Received: from fe-emea-09.sun.com ([192.18.6.119]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6700KHXNOPK340@emea1-mail1.uk.sun.com>; Tue, 26 Aug 2008 14:48:25 +0100 (BST) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700E01MGGIL00@fe-emea-09.sun.com> (ORCPT sig-prg@sun.com); Tue, 26 Aug 2008 14:48:25 +0100 (BST) Received: from phys-emea1-2.uk.sun.com ([192.18.6.10]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K67002DQNOILS90@fe-emea-09.sun.com> (ORCPT sig-prg@sun.com); Tue, 26 Aug 2008 14:48:18 +0100 (BST) Received: from dm-czech-01.uk.sun.com ([129.156.101.183]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6700KEHNOIK340@emea1-mail1.uk.sun.com> (ORCPT sig-prg@sun.com); Tue, 26 Aug 2008 14:48:18 +0100 (BST) Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by dm-czech-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7QDmH74024561; Tue, 26 Aug 2008 14:48:17 +0100 (BST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7QDmDgt052710 for <@sunmail2sca.sfbay.sun.com:sig-prg@sun.com>; Tue, 26 Aug 2008 07:48:16 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6700A05NOGEZ00@nwk-avmta-1.sfbay.Sun.COM> for sig-prg@sun.com (ORCPT sig-prg@sun.com); Tue, 26 Aug 2008 06:48:16 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K67003MGNOF6K70@nwk-avmta-1.sfbay.Sun.COM> for sig-prg@sun.com (ORCPT sig-prg@sun.com); Tue, 26 Aug 2008 06:48:16 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7QDmEad013728 for ; Tue, 26 Aug 2008 13:48:14 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700901NITCG00@fe-emea-10.sun.com> (original mail from Martina.Tomisova@Sun.COM) for sig-prg@sun.com (ORCPT sig-prg@sun.com); Tue, 26 Aug 2008 14:48:14 +0100 (BST) Received: from [129.157.16.195] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6700LNRNNZ5U50@fe-emea-10.sun.com>; Tue, 26 Aug 2008 14:48:01 +0100 (BST) Date: Tue, 26 Aug 2008 15:47:59 +0200 From: martina tomisova - Sun Microsystems - Prague Czech Republic Subject: changes at exec_attr Sender: Martina.Tomisova@Sun.COM To: gatekeeper@sfwnv.sfbay.sun.com, David.Marker@Sun.COM, Suhasini.Peddada@Sun.COM, sig-prg@sun.com Message-id: <48B4098F.3060703@sun.com> X-Envelope-from: Marek.Antozi@Sun.COM X-Envelope-to: @emea1-mail1.uk.sun.com:mt209345@emea1-mail1.UK.Sun.COM MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Original-recipient: rfc822;sig-prg@sun.com Hi, I'm integrating the ngrep package to the Nevada SFW. There is a need of adding one line to the /etc/security/exec_attr file. I've consulted this with sustaining gatekeepers. The results of our consultation are: 1. I should put the SUNWngrep to the sfwnv-gate in a common way without editing the exec_attr file. I should modify the exec_attr file at the SUNWcsr package at onnv-gate. SUNWngrep should depend on SUNWcsr. 2. There are some other packages that modify this exec_attr file (by class action script) at sfwnv-gate and onnv-gate. There is a list: $ ls -l /ws/onnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/security/exec_attr -rw-r--r-- 1 root sys 17653 Aug 26 00:10 /ws/onnv-gate/packages/sparc/nightly-nd/SUNWcsr/reloc/etc/security/exec_attr -rw-r--r-- 1 root sys 1190 Aug 15 00:00 /ws/onnv-gate/packages/sparc/nightly-nd/SUNWmmsr/reloc/etc/security/exec_attr $ ls -l /ws/sfwnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/security/exec_attr -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWmkcdr/reloc/etc/security/exec_attr -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWpostgr-82-server-data-root/reloc/etc/security/exec_attr -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWpostgr-83-server-data-root/reloc/etc/security/exec_attr -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWquaggar/reloc/etc/security/exec_attr Sustaining gatekeepers are afraid that this is not very clean and nice state which can (and should) be cleaned now however it won't be able to be cleaned after they will control this gate. They thing that the solution with editing SUNWcsr file is the cleanest and nicest way. So can you please provide me some more information how am I supposed to solve this situation and who should I contact about the chages at onnv-gate? Thank you, Martina --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; name="Attached Message Part" Content-transfer-encoding: 7BIT Content-disposition: inline; filename="Attached Message Part" Content-id: Content-type: message/rfc822; CHARSET=US-ASCII Content-description: Forwarded Message Return-path: Received: from fe-emea-09.sun.com ([192.18.6.119]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00LF6F2A0H50@emea1-mail1.uk.sun.com>; Thu, 28 Aug 2008 15:32:34 +0100 (BST) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6B00D01EJERW00@fe-emea-09.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 15:32:34 +0100 (BST) Received: from phys-emea1-2.uk.sun.com ([192.18.6.10]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B007ISF21GCB0@fe-emea-09.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 15:32:25 +0100 (BST) Received: from dm-czech-02.uk.sun.com ([129.156.101.215]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00LBPF200H50@emea1-mail1.uk.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 15:32:25 +0100 (BST) Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by dm-czech-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7SEWOUN008970; Thu, 28 Aug 2008 15:32:24 +0100 (BST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7SEWNWh005648 for <@sunmail2sca.sfbay.sun.com:sig-prg@Sun.COM>; Thu, 28 Aug 2008 07:32:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6B0023ZF1Z3800@nwk-avmta-2.sfbay.sun.com> for sig-prg@Sun.COM (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 07:32:23 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6B00LSJF1XLF60@nwk-avmta-2.sfbay.sun.com> for sig-prg@Sun.COM (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 07:32:21 -0700 (PDT) Received: from printing.eng.sun.com (printing.SFBay.Sun.COM [129.146.178.26]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7SEWJ5j029688; Thu, 28 Aug 2008 07:32:19 -0700 (PDT) Received: from [10.7.251.237] (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.eng.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7SEY19Z003335; Thu, 28 Aug 2008 07:34:02 -0700 (PDT) Date: Thu, 28 Aug 2008 09:32:17 -0500 From: Norm Jacobs Subject: Re: changes at exec_attr In-reply-to: <48B4098F.3060703@sun.com> To: martina tomisova - Sun Microsystems - Prague Czech Republic Cc: gatekeeper@sfwnv.sfbay.sun.com, David.Marker@Sun.COM, Suhasini.Peddada@Sun.COM, sig-prg@Sun.COM Message-id: <48B6B6F1.7090605@Sun.COM> X-Envelope-from: Marek.Antozi@Sun.COM X-Envelope-to: @emea1-mail1.uk.sun.com:mt209345@emea1-mail1.UK.Sun.COM MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48B4098F.3060703@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Original-recipient: rfc822;sig-prg@Sun.COM The entries belong with your component in it's packaging in the SFW gate. You can use the approach that the SUNWmmsr package takes in the ON gate. That is, it contains a package specific fragment file in the packaging directory and has the prototype refer directly to it instead of the proto area. Ex: usr/src/pkgdefs/SUNWfoor/prototype_com: i i.rbac i r.rbac e rbac etc/security/exec_attr=./exec_attr 644 root sys usr/src/pkgdefs/SUNWfoor/exec_attr: # # CDDL HEADER START # # The contents of this file are subject to the terms of the # Common Development and Distribution License (the "License"). # You may not use this file except in compliance with the License. # # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE # or http://www.opensolaris.org/os/licensing. # See the License for the specific language governing permissions # and limitations under the License. # # When distributing Covered Code, include this CDDL HEADER in each # file and include the License file at usr/src/OPENSOLARIS.LICENSE. # If applicable, add the following below this CDDL HEADER, with the # fields enclosed by brackets "[]" replaced with your own identifying # information: Portions Copyright [yyyy] [name of copyright owner] # # CDDL HEADER END # # Copyright 2008 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # #ident "@(#)exec_attr 1.7 07/01/07 SMI" # Network Management:solaris:cmd:::/usr/sbin/quaggaadm:privs=basic Network Management:solaris:cmd:::/usr/sbin/zebraadm:privs=basic I expect that we will change to the fragment approach soon, but other SFW components delivering RBAC fragments are editing a common exec_attr file in the sfw gate (${sfw_workspace}/usr/src/common/rbac/exec_attr) and adding the rbac class action script and an entry for the exec_attr file their root package's prototype file. So, for now, this would be acceptable as well. -Norm martina tomisova - Sun Microsystems - Prague Czech Republic wrote: > > Hi, > > I'm integrating the ngrep package to the Nevada SFW. There is a need > of adding one line to the /etc/security/exec_attr file. I've consulted > this with sustaining gatekeepers. The results of our consultation are: > > > 1. I should put the SUNWngrep to the sfwnv-gate in a common way > without editing the exec_attr file. I should modify the exec_attr file > at the SUNWcsr package at onnv-gate. SUNWngrep should depend on SUNWcsr. > > > 2. There are some other packages that modify this exec_attr file (by > class action script) at sfwnv-gate and onnv-gate. There is a list: > > $ ls -l > /ws/onnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/security/exec_attr > -rw-r--r-- 1 root sys 17653 Aug 26 00:10 > /ws/onnv-gate/packages/sparc/nightly-nd/SUNWcsr/reloc/etc/security/exec_attr > > -rw-r--r-- 1 root sys 1190 Aug 15 00:00 > /ws/onnv-gate/packages/sparc/nightly-nd/SUNWmmsr/reloc/etc/security/exec_attr > > > $ ls -l > /ws/sfwnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/security/exec_attr > -rw-r--r-- 1 root sys 2082 Aug 26 02:09 > /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWmkcdr/reloc/etc/security/exec_attr > > -rw-r--r-- 1 root sys 2082 Aug 26 02:09 > /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWpostgr-82-server-data-root/reloc/etc/security/exec_attr > > -rw-r--r-- 1 root sys 2082 Aug 26 02:09 > /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWpostgr-83-server-data-root/reloc/etc/security/exec_attr > > -rw-r--r-- 1 root sys 2082 Aug 26 02:09 > /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWquaggar/reloc/etc/security/exec_attr > > > Sustaining gatekeepers are afraid that this is not very clean and nice > state which can (and should) be cleaned now however it won't be able > to be cleaned after they will control this gate. They thing that the > solution with editing SUNWcsr file is the cleanest and nicest way. > > > So can you please provide me some more information how am I supposed > to solve this situation and who should I contact about the chages at > onnv-gate? > > Thank you, > Martina --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; name="Attached Message Part" Content-transfer-encoding: 7BIT Content-disposition: inline; filename="Attached Message Part" Content-id: Content-type: message/rfc822; CHARSET=US-ASCII Content-description: Forwarded Message Return-path: Received: from fe-emea-10.sun.com ([192.18.6.120]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00L6HFSL0HE0@emea1-mail1.uk.sun.com>; Thu, 28 Aug 2008 15:48:21 +0100 (BST) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6B00E01F9SYF00@fe-emea-10.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 15:48:21 +0100 (BST) Received: from phys-emea1-2.uk.sun.com ([192.18.6.12]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B009JDFS3FK00@fe-emea-10.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 15:48:03 +0100 (BST) Received: from dm-czech-01.uk.sun.com ([129.156.101.183]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00LZDFS20HD0@emea1-mail1.uk.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 15:48:03 +0100 (BST) Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by dm-czech-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7SEm1UB011873; Thu, 28 Aug 2008 15:48:02 +0100 (BST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7SEm0Mc010174 for <@sunmail2sca.sfbay.sun.com:sig-prg@sun.com>; Thu, 28 Aug 2008 07:48:01 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6B00E0NFS0A700@brm-avmta-1.central.sun.com> for sig-prg@sun.com (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 08:48:00 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6B00KFEFRXB5F0@brm-avmta-1.central.sun.com> for sig-prg@sun.com (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 08:47:58 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7SElvbP012693 for ; Thu, 28 Aug 2008 14:47:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6B00E01F9SYF00@fe-emea-10.sun.com> (original mail from Jaromir.Sedlacek@Sun.COM) for sig-prg@Sun.COM (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 15:47:57 +0100 (BST) Received: from dhcp-eprg06-19-40.Czech.Sun.COM ([129.157.19.40]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6B009DGFRKFK00@fe-emea-10.sun.com>; Thu, 28 Aug 2008 15:47:45 +0100 (BST) Date: Thu, 28 Aug 2008 16:47:43 +0200 From: Jaromir Sedlacek Subject: Re: changes at exec_attr In-reply-to: <48B6B6F1.7090605@Sun.COM> Sender: Jaromir.Sedlacek@Sun.COM To: Norm Jacobs Cc: martina tomisova - Sun Microsystems - Prague Czech Republic , gatekeeper@sfwnv.sfbay.sun.com, David.Marker@Sun.COM, Suhasini.Peddada@Sun.COM, sig-prg@Sun.COM Message-id: <2653BDFF-DB75-4014-8AA6-30487BFCB497@sun.com> X-Envelope-from: Marek.Antozi@Sun.COM X-Envelope-to: @emea1-mail1.uk.sun.com:mt209345@emea1-mail1.UK.Sun.COM MIME-version: 1.0 X-Mailer: Apple Mail (2.926) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48B4098F.3060703@sun.com> <48B6B6F1.7090605@Sun.COM> Original-recipient: rfc822;sig-prg@Sun.COM Hi Norm, Files which belongs to multiple packages are against approved packaging architecture and they are causing significant issues later when product is in sustaining cycle. Quoting from http://sac.sfbay/PSARC/1996/039/commit.materials/SW_Pkg_Rqrmts.ps page 48: As a general rule, redundant deliverables across packages are not allowed. and from http://sac.sfbay/PSARC/1991/061/spec.opensolaris : The Rule Again, the rule is: Each component of the system may be provided in only one package. Best regards, Jaromir On Aug 28, 2008, at 16:32, Norm Jacobs wrote: > > The entries belong with your component in it's packaging in the SFW > gate. You can use the approach that the SUNWmmsr package takes in > the ON gate. That is, it contains a package specific fragment file > in the packaging directory and has the prototype refer directly to > it instead of the proto area. > > Ex: > > usr/src/pkgdefs/SUNWfoor/prototype_com: > > i i.rbac > i r.rbac > e rbac etc/security/exec_attr=./exec_attr 644 root sys > > usr/src/pkgdefs/SUNWfoor/exec_attr: > > # > # CDDL HEADER START > # > # The contents of this file are subject to the terms of the > # Common Development and Distribution License (the "License"). > # You may not use this file except in compliance with the License. > # > # You can obtain a copy of the license at usr/src/ > OPENSOLARIS.LICENSE > # or http://www.opensolaris.org/os/licensing. > # See the License for the specific language governing permissions > # and limitations under the License. > # > # When distributing Covered Code, include this CDDL HEADER in each > # file and include the License file at usr/src/OPENSOLARIS.LICENSE. > # If applicable, add the following below this CDDL HEADER, with the > # fields enclosed by brackets "[]" replaced with your own > identifying > # information: Portions Copyright [yyyy] [name of copyright owner] > # > # CDDL HEADER END > # > # Copyright 2008 Sun Microsystems, Inc. All rights reserved. > # Use is subject to license terms. > # > #ident "@(#)exec_attr 1.7 07/01/07 SMI" > # > Network Management:solaris:cmd:::/usr/sbin/quaggaadm:privs=basic > Network Management:solaris:cmd:::/usr/sbin/zebraadm:privs=basic > > I expect that we will change to the fragment approach soon, but > other SFW components delivering RBAC fragments are editing a common > exec_attr file in the sfw gate (${sfw_workspace}/usr/src/common/rbac/ > exec_attr) and adding the rbac class action script and an entry for > the exec_attr file their root package's prototype file. So, for > now, this would be acceptable as well. > > -Norm > > > > > martina tomisova - Sun Microsystems - Prague Czech Republic wrote: >> >> Hi, >> >> I'm integrating the ngrep package to the Nevada SFW. There is a >> need of adding one line to the /etc/security/exec_attr file. I've >> consulted this with sustaining gatekeepers. The results of our >> consultation are: >> >> >> 1. I should put the SUNWngrep to the sfwnv-gate in a common way >> without editing the exec_attr file. I should modify the exec_attr >> file at the SUNWcsr package at onnv-gate. SUNWngrep should depend >> on SUNWcsr. >> >> >> 2. There are some other packages that modify this exec_attr file >> (by class action script) at sfwnv-gate and onnv-gate. There is a >> list: >> >> $ ls -l /ws/onnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/ >> security/exec_attr >> -rw-r--r-- 1 root sys 17653 Aug 26 00:10 /ws/onnv-gate/ >> packages/sparc/nightly-nd/SUNWcsr/reloc/etc/security/exec_attr >> -rw-r--r-- 1 root sys 1190 Aug 15 00:00 /ws/onnv-gate/ >> packages/sparc/nightly-nd/SUNWmmsr/reloc/etc/security/exec_attr >> >> $ ls -l /ws/sfwnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/ >> security/exec_attr >> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >> gate/packages/sparc/nightly-nd/SUNWmkcdr/reloc/etc/security/exec_attr >> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >> gate/packages/sparc/nightly-nd/SUNWpostgr-82-server-data-root/reloc/ >> etc/security/exec_attr >> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >> gate/packages/sparc/nightly-nd/SUNWpostgr-83-server-data-root/reloc/ >> etc/security/exec_attr >> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >> gate/packages/sparc/nightly-nd/SUNWquaggar/reloc/etc/security/ >> exec_attr >> >> Sustaining gatekeepers are afraid that this is not very clean and >> nice state which can (and should) be cleaned now however it won't >> be able to be cleaned after they will control this gate. They thing >> that the solution with editing SUNWcsr file is the cleanest and >> nicest way. >> >> >> So can you please provide me some more information how am I >> supposed to solve this situation and who should I contact about the >> chages at onnv-gate? >> >> Thank you, >> Martina > --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; name="Attached Message Part" Content-transfer-encoding: 7BIT Content-disposition: inline; filename="Attached Message Part" Content-id: Content-type: message/rfc822; CHARSET=US-ASCII Content-description: Forwarded Message Return-path: Received: from fe-emea-09.sun.com ([192.18.6.119]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00LMZHKAOI30@emea1-mail1.uk.sun.com>; Thu, 28 Aug 2008 16:26:34 +0100 (BST) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6B00201G359000@fe-emea-09.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 16:26:34 +0100 (BST) Received: from phys-emea1-2.uk.sun.com ([192.18.6.11]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B004P3HJLBH30@fe-emea-09.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 16:26:09 +0100 (BST) Received: from dm-czech-01.uk.sun.com ([129.156.101.183]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00LG5HJLOI30@emea1-mail1.uk.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 16:26:09 +0100 (BST) Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by dm-czech-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7SFQ94m022416; Thu, 28 Aug 2008 16:26:09 +0100 (BST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7SFQ4Nd021777 for <@sunmail2sca.sfbay.sun.com:sig-prg@Sun.COM>; Thu, 28 Aug 2008 16:26:08 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6B00G2DHJKO900@brm-avmta-1.central.sun.com> for sig-prg@Sun.COM (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 09:26:08 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6B00F5KHJE9U10@brm-avmta-1.central.sun.com> for sig-prg@Sun.COM (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 09:26:03 -0600 (MDT) Received: from printing.eng.sun.com (printing.SFBay.Sun.COM [129.146.178.26]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7SFQ0OI006469; Thu, 28 Aug 2008 08:26:00 -0700 (PDT) Received: from [10.7.251.237] (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.eng.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7SFRhSo003381; Thu, 28 Aug 2008 08:27:43 -0700 (PDT) Date: Thu, 28 Aug 2008 10:25:58 -0500 From: Norm Jacobs Subject: Re: changes at exec_attr In-reply-to: <2653BDFF-DB75-4014-8AA6-30487BFCB497@sun.com> To: Jaromir Sedlacek Cc: martina tomisova - Sun Microsystems - Prague Czech Republic , gatekeeper@sfwnv.sfbay.sun.com, David.Marker@Sun.COM, Suhasini.Peddada@Sun.COM, sig-prg@Sun.COM Message-id: <48B6C386.2090509@Sun.COM> X-Envelope-from: Marek.Antozi@Sun.COM X-Envelope-to: @emea1-mail1.uk.sun.com:mt209345@emea1-mail1.UK.Sun.COM MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48B4098F.3060703@sun.com> <48B6B6F1.7090605@Sun.COM> <2653BDFF-DB75-4014-8AA6-30487BFCB497@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Original-recipient: rfc822;sig-prg@Sun.COM Editable files are exempt from this exactly so they can be delivered as fragments. It's the point of the rbac and some of the other class action scripts. Static files are not exempt and for good reason. -Norm Jaromir Sedlacek wrote: > Hi Norm, > > Files which belongs to multiple packages are against approved > packaging architecture and they are causing significant issues later > when product is in sustaining cycle. > > Quoting from > http://sac.sfbay/PSARC/1996/039/commit.materials/SW_Pkg_Rqrmts.ps page > 48: > > > As a general rule, redundant deliverables across packages are not > allowed. > Please read a little further on (page 49, 1st paragraph) One package object type is exempt to the non-redundancy rule, the editable file. Since editable files do not replace existing files, but are edited during installation and upggrade by means of class action scripts, they may appear in multiple packages without the need for a formal architectural approval. > > and from http://sac.sfbay/PSARC/1991/061/spec.opensolaris : > > > The Rule > > Again, the rule is: > Each component of the system may be provided in only one package. > > > Best regards, > Jaromir > > On Aug 28, 2008, at 16:32, Norm Jacobs wrote: > >> >> The entries belong with your component in it's packaging in the SFW >> gate. You can use the approach that the SUNWmmsr package takes in >> the ON gate. That is, it contains a package specific fragment file >> in the packaging directory and has the prototype refer directly to it >> instead of the proto area. >> >> Ex: >> >> usr/src/pkgdefs/SUNWfoor/prototype_com: >> >> i i.rbac >> i r.rbac >> e rbac etc/security/exec_attr=./exec_attr 644 root sys >> >> usr/src/pkgdefs/SUNWfoor/exec_attr: >> >> # >> # CDDL HEADER START >> # >> # The contents of this file are subject to the terms of the >> # Common Development and Distribution License (the "License"). >> # You may not use this file except in compliance with the License. >> # >> # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE >> # or http://www.opensolaris.org/os/licensing. >> # See the License for the specific language governing permissions >> # and limitations under the License. >> # >> # When distributing Covered Code, include this CDDL HEADER in each >> # file and include the License file at usr/src/OPENSOLARIS.LICENSE. >> # If applicable, add the following below this CDDL HEADER, with the >> # fields enclosed by brackets "[]" replaced with your own identifying >> # information: Portions Copyright [yyyy] [name of copyright owner] >> # >> # CDDL HEADER END >> # >> # Copyright 2008 Sun Microsystems, Inc. All rights reserved. >> # Use is subject to license terms. >> # >> #ident "@(#)exec_attr 1.7 07/01/07 SMI" >> # >> Network Management:solaris:cmd:::/usr/sbin/quaggaadm:privs=basic >> Network Management:solaris:cmd:::/usr/sbin/zebraadm:privs=basic >> >> I expect that we will change to the fragment approach soon, but other >> SFW components delivering RBAC fragments are editing a common >> exec_attr file in the sfw gate >> (${sfw_workspace}/usr/src/common/rbac/exec_attr) and adding the rbac >> class action script and an entry for the exec_attr file their root >> package's prototype file. So, for now, this would be acceptable as >> well. >> >> -Norm >> >> >> >> >> martina tomisova - Sun Microsystems - Prague Czech Republic wrote: >>> >>> Hi, >>> >>> I'm integrating the ngrep package to the Nevada SFW. There is a need >>> of adding one line to the /etc/security/exec_attr file. I've >>> consulted this with sustaining gatekeepers. The results of our >>> consultation are: >>> >>> >>> 1. I should put the SUNWngrep to the sfwnv-gate in a common way >>> without editing the exec_attr file. I should modify the exec_attr >>> file at the SUNWcsr package at onnv-gate. SUNWngrep should depend on >>> SUNWcsr. >>> >>> >>> 2. There are some other packages that modify this exec_attr file (by >>> class action script) at sfwnv-gate and onnv-gate. There is a list: >>> >>> $ ls -l >>> /ws/onnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/security/exec_attr >>> -rw-r--r-- 1 root sys 17653 Aug 26 00:10 >>> /ws/onnv-gate/packages/sparc/nightly-nd/SUNWcsr/reloc/etc/security/exec_attr >>> >>> -rw-r--r-- 1 root sys 1190 Aug 15 00:00 >>> /ws/onnv-gate/packages/sparc/nightly-nd/SUNWmmsr/reloc/etc/security/exec_attr >>> >>> >>> $ ls -l >>> /ws/sfwnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/security/exec_attr >>> >>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 >>> /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWmkcdr/reloc/etc/security/exec_attr >>> >>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 >>> /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWpostgr-82-server-data-root/reloc/etc/security/exec_attr >>> >>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 >>> /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWpostgr-83-server-data-root/reloc/etc/security/exec_attr >>> >>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 >>> /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWquaggar/reloc/etc/security/exec_attr >>> >>> >>> Sustaining gatekeepers are afraid that this is not very clean and >>> nice state which can (and should) be cleaned now however it won't be >>> able to be cleaned after they will control this gate. They thing >>> that the solution with editing SUNWcsr file is the cleanest and >>> nicest way. >>> >>> >>> So can you please provide me some more information how am I supposed >>> to solve this situation and who should I contact about the chages at >>> onnv-gate? >>> >>> Thank you, >>> Martina >> > --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; name="Attached Message Part" Content-transfer-encoding: 7BIT Content-disposition: inline; filename="Attached Message Part" Content-id: Content-type: message/rfc822; CHARSET=US-ASCII Content-description: Forwarded Message Return-path: Received: from fe-emea-10.sun.com ([192.18.6.120]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00LXKI73OIA0@emea1-mail1.uk.sun.com>; Thu, 28 Aug 2008 16:40:15 +0100 (BST) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6B00301I06FP00@fe-emea-10.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 16:40:15 +0100 (BST) Received: from phys-emea1-2.uk.sun.com ([192.18.6.12]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00ADGI6YV760@fe-emea-10.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 16:40:15 +0100 (BST) Received: from dm-czech-01.uk.sun.com ([129.156.101.183]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00LW3I6YOIA0@emea1-mail1.uk.sun.com> (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 16:40:10 +0100 (BST) Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by dm-czech-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7SFeAZp025654; Thu, 28 Aug 2008 16:40:10 +0100 (BST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7SFe56B028070 for <@sunmail2sca.sfbay.sun.com:sig-prg@sun.com>; Thu, 28 Aug 2008 16:40:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6B00D15I6WHD00@nwk-avmta-1.sfbay.Sun.COM> for sig-prg@sun.com (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 08:40:08 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6B006D6I6TJ640@nwk-avmta-1.sfbay.Sun.COM> for sig-prg@sun.com (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 08:40:06 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7SFe5nP019267 for ; Thu, 28 Aug 2008 15:40:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6B00301I06FP00@fe-emea-10.sun.com> (original mail from Jaromir.Sedlacek@Sun.COM) for sig-prg@Sun.COM (ORCPT sig-prg@Sun.COM); Thu, 28 Aug 2008 16:40:05 +0100 (BST) Received: from dhcp-eprg06-19-40.Czech.Sun.COM ([129.157.19.40]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6B00A8XI6DV760@fe-emea-10.sun.com>; Thu, 28 Aug 2008 16:39:49 +0100 (BST) Date: Thu, 28 Aug 2008 17:39:48 +0200 From: Jaromir Sedlacek Subject: Re: changes at exec_attr In-reply-to: <48B6C386.2090509@Sun.COM> Sender: Jaromir.Sedlacek@Sun.COM To: Norm Jacobs Cc: martina tomisova - Sun Microsystems - Prague Czech Republic , gatekeeper@sfwnv.sfbay.sun.com, David.Marker@Sun.COM, Suhasini.Peddada@Sun.COM, sig-prg@Sun.COM Message-id: X-Envelope-from: Marek.Antozi@Sun.COM X-Envelope-to: @emea1-mail1.uk.sun.com:mt209345@emea1-mail1.UK.Sun.COM MIME-version: 1.0 X-Mailer: Apple Mail (2.926) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48B4098F.3060703@sun.com> <48B6B6F1.7090605@Sun.COM> <2653BDFF-DB75-4014-8AA6-30487BFCB497@sun.com> <48B6C386.2090509@Sun.COM> Original-recipient: rfc822;sig-prg@Sun.COM Then there is lot of things which does not conform with this. Starting with WebRTI where deliverable object list is based on object path and not on package ownership. S10 patches has issues too. I am sorry for not carefully reading that document. Thanks and regards, Jaromir On Aug 28, 2008, at 17:25, Norm Jacobs wrote: > Editable files are exempt from this exactly so they can be delivered > as fragments. It's the point of the rbac and some of the other > class action scripts. > Static files are not exempt and for good reason. > > -Norm > > Jaromir Sedlacek wrote: >> Hi Norm, >> >> Files which belongs to multiple packages are against approved >> packaging architecture and they are causing significant issues >> later when product is in sustaining cycle. >> >> Quoting from http://sac.sfbay/PSARC/1996/039/commit.materials/SW_Pkg_Rqrmts.ps >> page 48: >> >> >> As a general rule, redundant deliverables across packages are not >> allowed. >> > Please read a little further on (page 49, 1st paragraph) > > One package object type is exempt to the non-redundancy rule, the > editable file. > Since editable files do not replace existing files, but are edited > during > installation and upggrade by means of class action scripts, they > may appear in > multiple packages without the need for a formal architectural > approval. > > >> >> and from http://sac.sfbay/PSARC/1991/061/spec.opensolaris : >> >> >> The Rule >> >> Again, the rule is: >> Each component of the system may be provided in only one package. >> >> >> Best regards, >> Jaromir >> >> On Aug 28, 2008, at 16:32, Norm Jacobs wrote: >> >>> >>> The entries belong with your component in it's packaging in the >>> SFW gate. You can use the approach that the SUNWmmsr package >>> takes in the ON gate. That is, it contains a package specific >>> fragment file in the packaging directory and has the prototype >>> refer directly to it instead of the proto area. >>> >>> Ex: >>> >>> usr/src/pkgdefs/SUNWfoor/prototype_com: >>> >>> i i.rbac >>> i r.rbac >>> e rbac etc/security/exec_attr=./exec_attr 644 root sys >>> >>> usr/src/pkgdefs/SUNWfoor/exec_attr: >>> >>> # >>> # CDDL HEADER START >>> # >>> # The contents of this file are subject to the terms of the >>> # Common Development and Distribution License (the "License"). >>> # You may not use this file except in compliance with the License. >>> # >>> # You can obtain a copy of the license at usr/src/ >>> OPENSOLARIS.LICENSE >>> # or http://www.opensolaris.org/os/licensing. >>> # See the License for the specific language governing permissions >>> # and limitations under the License. >>> # >>> # When distributing Covered Code, include this CDDL HEADER in each >>> # file and include the License file at usr/src/OPENSOLARIS.LICENSE. >>> # If applicable, add the following below this CDDL HEADER, with the >>> # fields enclosed by brackets "[]" replaced with your own >>> identifying >>> # information: Portions Copyright [yyyy] [name of copyright owner] >>> # >>> # CDDL HEADER END >>> # >>> # Copyright 2008 Sun Microsystems, Inc. All rights reserved. >>> # Use is subject to license terms. >>> # >>> #ident "@(#)exec_attr 1.7 07/01/07 SMI" >>> # >>> Network Management:solaris:cmd:::/usr/sbin/quaggaadm:privs=basic >>> Network Management:solaris:cmd:::/usr/sbin/zebraadm:privs=basic >>> >>> I expect that we will change to the fragment approach soon, but >>> other SFW components delivering RBAC fragments are editing a >>> common exec_attr file in the sfw gate (${sfw_workspace}/usr/src/ >>> common/rbac/exec_attr) and adding the rbac class action script and >>> an entry for the exec_attr file their root package's prototype >>> file. So, for now, this would be acceptable as well. >>> >>> -Norm >>> >>> >>> >>> >>> martina tomisova - Sun Microsystems - Prague Czech Republic wrote: >>>> >>>> Hi, >>>> >>>> I'm integrating the ngrep package to the Nevada SFW. There is a >>>> need of adding one line to the /etc/security/exec_attr file. I've >>>> consulted this with sustaining gatekeepers. The results of our >>>> consultation are: >>>> >>>> >>>> 1. I should put the SUNWngrep to the sfwnv-gate in a common way >>>> without editing the exec_attr file. I should modify the exec_attr >>>> file at the SUNWcsr package at onnv-gate. SUNWngrep should depend >>>> on SUNWcsr. >>>> >>>> >>>> 2. There are some other packages that modify this exec_attr file >>>> (by class action script) at sfwnv-gate and onnv-gate. There is a >>>> list: >>>> >>>> $ ls -l /ws/onnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/ >>>> security/exec_attr >>>> -rw-r--r-- 1 root sys 17653 Aug 26 00:10 /ws/onnv- >>>> gate/packages/sparc/nightly-nd/SUNWcsr/reloc/etc/security/exec_attr >>>> -rw-r--r-- 1 root sys 1190 Aug 15 00:00 /ws/onnv- >>>> gate/packages/sparc/nightly-nd/SUNWmmsr/reloc/etc/security/ >>>> exec_attr >>>> >>>> $ ls -l /ws/sfwnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/ >>>> security/exec_attr >>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >>>> gate/packages/sparc/nightly-nd/SUNWmkcdr/reloc/etc/security/ >>>> exec_attr >>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >>>> gate/packages/sparc/nightly-nd/SUNWpostgr-82-server-data-root/ >>>> reloc/etc/security/exec_attr >>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >>>> gate/packages/sparc/nightly-nd/SUNWpostgr-83-server-data-root/ >>>> reloc/etc/security/exec_attr >>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >>>> gate/packages/sparc/nightly-nd/SUNWquaggar/reloc/etc/security/ >>>> exec_attr >>>> >>>> Sustaining gatekeepers are afraid that this is not very clean and >>>> nice state which can (and should) be cleaned now however it won't >>>> be able to be cleaned after they will control this gate. They >>>> thing that the solution with editing SUNWcsr file is the cleanest >>>> and nicest way. >>>> >>>> >>>> So can you please provide me some more information how am I >>>> supposed to solve this situation and who should I contact about >>>> the chages at onnv-gate? >>>> >>>> Thank you, >>>> Martina >>> >> > --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; name="Attached Message Part" Content-transfer-encoding: 7BIT Content-disposition: inline; filename="Attached Message Part" Content-id: Content-type: message/rfc822; CHARSET=US-ASCII Content-description: Forwarded Message Return-path: Received: from fe-emea-09.sun.com ([192.18.6.119]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B001BIRXKKG20@emea1-mail1.uk.sun.com>; Thu, 28 Aug 2008 20:10:32 +0100 (BST) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6B00601RR2J300@fe-emea-09.sun.com> (ORCPT sig-prg@sun.com); Thu, 28 Aug 2008 20:10:32 +0100 (BST) Received: from phys-emea1-2.uk.sun.com ([192.18.6.10]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B00APYRXKL780@fe-emea-09.sun.com> (ORCPT sig-prg@sun.com); Thu, 28 Aug 2008 20:10:32 +0100 (BST) Received: from dm-czech-01.uk.sun.com ([129.156.101.183]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6B001BDRXKKG20@emea1-mail1.uk.sun.com> (ORCPT sig-prg@sun.com); Thu, 28 Aug 2008 20:10:32 +0100 (BST) Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by dm-czech-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7SJAWWg010654; Thu, 28 Aug 2008 20:10:32 +0100 (BST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7SJAOuL027449; Thu, 28 Aug 2008 20:10:27 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6B0090XRXE4M00@brm-avmta-1.central.sun.com>; Thu, 28 Aug 2008 13:10:26 -0600 (MDT) Received: from yavin.Eng.Sun.COM ([129.146.228.146]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6B006W2RXDOW10@brm-avmta-1.central.sun.com>; Thu, 28 Aug 2008 13:10:25 -0600 (MDT) Received: from [129.146.228.146] (yavin [129.146.228.146]) by yavin.Eng.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m7SJAOBm465848; Thu, 28 Aug 2008 12:10:24 -0700 (PDT) Date: Thu, 28 Aug 2008 12:10:24 -0700 From: Mike Sullivan Subject: Re: changes at exec_attr In-reply-to: To: Jaromir Sedlacek Cc: Norm Jacobs , martina tomisova - Sun Microsystems - Prague Czech Republic , gatekeeper@sfwnv.sfbay.sun.com, David.Marker@Sun.COM, Suhasini.Peddada@Sun.COM, sig-prg@sun.com Message-id: <48B6F820.7050305@Sun.COM> X-Envelope-from: Marek.Antozi@Sun.COM X-Envelope-to: @emea1-mail1.uk.sun.com:mt209345@emea1-mail1.UK.Sun.COM MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48B4098F.3060703@sun.com> <48B6B6F1.7090605@Sun.COM> <2653BDFF-DB75-4014-8AA6-30487BFCB497@sun.com> <48B6C386.2090509@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080804) Original-recipient: rfc822;sig-prg@sun.com Jaromir Sedlacek wrote: > Then there is lot of things which does not conform with this. Starting > with WebRTI where deliverable object list is based on object path and > not on package ownership. S10 patches has issues too. WebRTI doesn't enforce your deliverable list is right either, which is a bigger issue. But I'm not sure how relevant that is. The key is that packages aren't supposed to overwrite each others files. The problem is that some do indeed need to share common files (like ones that ON provides, say the RBAC ones here) and the class-action script method is used to handle that. RE does enforce some things at package integration time and I think that is where cross-consolidation attempts to deliver the same file (as 'f none', not 'e specificclassactionscript') would be caught. Within the consolidation protocmp should be catching that I think (for ON and SFW at least). I think they miss symlinks though and we do have that in a few packages. And of course they can't check directories. patches have their own mystical process which hopefully also catch this. Mike > > I am sorry for not carefully reading that document. > > Thanks and regards, > Jaromir > > On Aug 28, 2008, at 17:25, Norm Jacobs wrote: > >> Editable files are exempt from this exactly so they can be delivered >> as fragments. It's the point of the rbac and some of the other class >> action scripts. >> Static files are not exempt and for good reason. >> >> -Norm >> >> Jaromir Sedlacek wrote: >>> Hi Norm, >>> >>> Files which belongs to multiple packages are against approved >>> packaging architecture and they are causing significant issues later >>> when product is in sustaining cycle. >>> >>> Quoting from >>> http://sac.sfbay/PSARC/1996/039/commit.materials/SW_Pkg_Rqrmts.ps page >>> 48: >>> >>> >>> As a general rule, redundant deliverables across packages are not >>> allowed. >>> >> Please read a little further on (page 49, 1st paragraph) >> >> One package object type is exempt to the non-redundancy rule, the >> editable file. >> Since editable files do not replace existing files, but are edited >> during >> installation and upggrade by means of class action scripts, they >> may appear in >> multiple packages without the need for a formal architectural approval. >> >> >>> >>> and from http://sac.sfbay/PSARC/1991/061/spec.opensolaris : >>> >>> >>> The Rule >>> >>> Again, the rule is: >>> Each component of the system may be provided in only one package. >>> >>> >>> Best regards, >>> Jaromir >>> >>> On Aug 28, 2008, at 16:32, Norm Jacobs wrote: >>> >>>> >>>> The entries belong with your component in it's packaging in the SFW >>>> gate. You can use the approach that the SUNWmmsr package takes in >>>> the ON gate. That is, it contains a package specific fragment file >>>> in the packaging directory and has the prototype refer directly to >>>> it instead of the proto area. >>>> >>>> Ex: >>>> >>>> usr/src/pkgdefs/SUNWfoor/prototype_com: >>>> >>>> i i.rbac >>>> i r.rbac >>>> e rbac etc/security/exec_attr=./exec_attr 644 root sys >>>> >>>> usr/src/pkgdefs/SUNWfoor/exec_attr: >>>> >>>> # >>>> # CDDL HEADER START >>>> # >>>> # The contents of this file are subject to the terms of the >>>> # Common Development and Distribution License (the "License"). >>>> # You may not use this file except in compliance with the License. >>>> # >>>> # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE >>>> # or http://www.opensolaris.org/os/licensing. >>>> # See the License for the specific language governing permissions >>>> # and limitations under the License. >>>> # >>>> # When distributing Covered Code, include this CDDL HEADER in each >>>> # file and include the License file at usr/src/OPENSOLARIS.LICENSE. >>>> # If applicable, add the following below this CDDL HEADER, with the >>>> # fields enclosed by brackets "[]" replaced with your own identifying >>>> # information: Portions Copyright [yyyy] [name of copyright owner] >>>> # >>>> # CDDL HEADER END >>>> # >>>> # Copyright 2008 Sun Microsystems, Inc. All rights reserved. >>>> # Use is subject to license terms. >>>> # >>>> #ident "@(#)exec_attr 1.7 07/01/07 SMI" >>>> # >>>> Network Management:solaris:cmd:::/usr/sbin/quaggaadm:privs=basic >>>> Network Management:solaris:cmd:::/usr/sbin/zebraadm:privs=basic >>>> >>>> I expect that we will change to the fragment approach soon, but >>>> other SFW components delivering RBAC fragments are editing a common >>>> exec_attr file in the sfw gate >>>> (${sfw_workspace}/usr/src/common/rbac/exec_attr) and adding the rbac >>>> class action script and an entry for the exec_attr file their root >>>> package's prototype file. So, for now, this would be acceptable as >>>> well. >>>> >>>> -Norm >>>> >>>> >>>> >>>> >>>> martina tomisova - Sun Microsystems - Prague Czech Republic wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm integrating the ngrep package to the Nevada SFW. There is a >>>>> need of adding one line to the /etc/security/exec_attr file. I've >>>>> consulted this with sustaining gatekeepers. The results of our >>>>> consultation are: >>>>> >>>>> >>>>> 1. I should put the SUNWngrep to the sfwnv-gate in a common way >>>>> without editing the exec_attr file. I should modify the exec_attr >>>>> file at the SUNWcsr package at onnv-gate. SUNWngrep should depend >>>>> on SUNWcsr. >>>>> >>>>> >>>>> 2. There are some other packages that modify this exec_attr file >>>>> (by class action script) at sfwnv-gate and onnv-gate. There is a list: >>>>> >>>>> $ ls -l >>>>> /ws/onnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/security/exec_attr >>>>> >>>>> -rw-r--r-- 1 root sys 17653 Aug 26 00:10 >>>>> /ws/onnv-gate/packages/sparc/nightly-nd/SUNWcsr/reloc/etc/security/exec_attr >>>>> >>>>> -rw-r--r-- 1 root sys 1190 Aug 15 00:00 >>>>> /ws/onnv-gate/packages/sparc/nightly-nd/SUNWmmsr/reloc/etc/security/exec_attr >>>>> >>>>> >>>>> $ ls -l >>>>> /ws/sfwnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/security/exec_attr >>>>> >>>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 >>>>> /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWmkcdr/reloc/etc/security/exec_attr >>>>> >>>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 >>>>> /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWpostgr-82-server-data-root/reloc/etc/security/exec_attr >>>>> >>>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 >>>>> /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWpostgr-83-server-data-root/reloc/etc/security/exec_attr >>>>> >>>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 >>>>> /ws/sfwnv-gate/packages/sparc/nightly-nd/SUNWquaggar/reloc/etc/security/exec_attr >>>>> >>>>> >>>>> Sustaining gatekeepers are afraid that this is not very clean and >>>>> nice state which can (and should) be cleaned now however it won't >>>>> be able to be cleaned after they will control this gate. They thing >>>>> that the solution with editing SUNWcsr file is the cleanest and >>>>> nicest way. >>>>> >>>>> >>>>> So can you please provide me some more information how am I >>>>> supposed to solve this situation and who should I contact about the >>>>> chages at onnv-gate? >>>>> >>>>> Thank you, >>>>> Martina >>>> >>> >> > > --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; name="Attached Message Part" Content-transfer-encoding: 7BIT Content-disposition: inline; filename="Attached Message Part" Content-id: Content-type: message/rfc822; CHARSET=US-ASCII Content-description: Forwarded Message Return-path: Received: from fe-emea-09.sun.com ([192.18.6.119]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6D0086Y0UASS80@emea1-mail1.uk.sun.com>; Fri, 29 Aug 2008 12:20:34 +0100 (BST) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6D008010TFAV00@fe-emea-09.sun.com> (ORCPT sig-prg@sun.com); Fri, 29 Aug 2008 12:20:34 +0100 (BST) Received: from phys-emea1-1.uk.sun.com ([192.18.6.11]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6D0045R0UARG80@fe-emea-09.sun.com> (ORCPT sig-prg@sun.com); Fri, 29 Aug 2008 12:20:34 +0100 (BST) Received: from dm-czech-02.uk.sun.com ([129.156.101.215]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6D0086Q0UASS80@emea1-mail1.uk.sun.com> (ORCPT sig-prg@sun.com); Fri, 29 Aug 2008 12:20:34 +0100 (BST) Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by dm-czech-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7TBKX29005339; Fri, 29 Aug 2008 12:20:33 +0100 (BST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7TBKTxG011403; Fri, 29 Aug 2008 19:20:30 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6D00C050U4HN00@brm-avmta-1.central.sun.com>; Fri, 29 Aug 2008 05:20:28 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6D0002T0U3GQ80@brm-avmta-1.central.sun.com>; Fri, 29 Aug 2008 05:20:28 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7TBKR1v028018; Fri, 29 Aug 2008 11:20:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6D00H010SSBR00@fe-emea-10.sun.com> (original mail from Martina.Tomisova@Sun.COM); Fri, 29 Aug 2008 12:20:27 +0100 (BST) Received: from [129.157.16.195] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6D000HY0TWGK60@fe-emea-10.sun.com>; Fri, 29 Aug 2008 12:20:21 +0100 (BST) Date: Fri, 29 Aug 2008 13:20:19 +0200 From: martina tomisova - Sun Microsystems - Prague Czech Republic Subject: Re: changes at exec_attr In-reply-to: <48B6F820.7050305@Sun.COM> Sender: Martina.Tomisova@Sun.COM To: Mike Sullivan Cc: Jaromir Sedlacek , Norm Jacobs , gatekeeper@sfwnv.sfbay.sun.com, David.Marker@Sun.COM, Suhasini.Peddada@Sun.COM, sig-prg@sun.com Message-id: <48B7DB73.90102@sun.com> X-Envelope-from: Marek.Antozi@Sun.COM X-Envelope-to: @emea1-mail1.uk.sun.com:mt209345@emea1-mail1.UK.Sun.COM MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48B4098F.3060703@sun.com> <48B6B6F1.7090605@Sun.COM> <2653BDFF-DB75-4014-8AA6-30487BFCB497@sun.com> <48B6C386.2090509@Sun.COM> <48B6F820.7050305@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Original-recipient: rfc822;sig-prg@sun.com So I'm going to use the class action script as Norm have written at his first email. Thank you all for you help and have a nice day, Martina --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw) Content-type: text/plain; name="Attached Message Part" Content-transfer-encoding: 7BIT Content-disposition: inline; filename="Attached Message Part" Content-id: Content-type: message/rfc822; CHARSET=US-ASCII Content-description: Forwarded Message Return-path: Received: from fe-emea-09.sun.com ([192.18.6.119]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6D00C1IF3UHCA0@emea1-mail1.uk.sun.com>; Fri, 29 Aug 2008 17:28:45 +0100 (BST) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6D00H01F0FMM00@fe-emea-09.sun.com> (ORCPT sig-prg@sun.com); Fri, 29 Aug 2008 17:28:43 +0100 (BST) Received: from phys-emea1-1.uk.sun.com ([192.18.6.12]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6D00KA8F3F3T70@fe-emea-09.sun.com> (ORCPT sig-prg@sun.com); Fri, 29 Aug 2008 17:28:27 +0100 (BST) Received: from dm-czech-02.uk.sun.com ([129.156.101.215]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K6D00CZLF3FHC90@emea1-mail1.uk.sun.com> (ORCPT sig-prg@sun.com); Fri, 29 Aug 2008 17:28:27 +0100 (BST) Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by dm-czech-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7TGSQMU012245; Fri, 29 Aug 2008 17:28:27 +0100 (BST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7TGSPbh007823; Fri, 29 Aug 2008 09:28:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6D0000VF3DCK00@nwk-avmta-2.sfbay.sun.com>; Fri, 29 Aug 2008 09:28:25 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6D00H5AF3ARWA0@nwk-avmta-2.sfbay.sun.com>; Fri, 29 Aug 2008 09:28:23 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7TGSMJS021755; Fri, 29 Aug 2008 16:28:22 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6D00H01F0FMM00@fe-emea-09.sun.com> (original mail from Jaromir.Sedlacek@Sun.COM); Fri, 29 Aug 2008 17:28:22 +0100 (BST) Received: from dhcp-eprg06-19-40.Czech.Sun.COM ([129.157.19.40]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6D00K6OF2I3T70@fe-emea-09.sun.com>; Fri, 29 Aug 2008 17:27:55 +0100 (BST) Date: Fri, 29 Aug 2008 18:27:54 +0200 From: Jaromir Sedlacek Subject: Re: changes at exec_attr In-reply-to: <48B6F820.7050305@Sun.COM> Sender: Jaromir.Sedlacek@Sun.COM To: Mike Sullivan Cc: Norm Jacobs , martina tomisova - Sun Microsystems - Prague Czech Republic , gatekeeper@sfwnv.sfbay.sun.com, David.Marker@Sun.COM, Suhasini.Peddada@Sun.COM, sig-prg@sun.com Message-id: <9A91B545-4D95-4386-965C-54E94D65AF9E@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.926) Content-type: multipart/mixed; boundary="Boundary_(ID_WkLORA86qxd+TiWlwD86qg)" X-PMX-Version: 5.4.1.325704 References: <48B4098F.3060703@sun.com> <48B6B6F1.7090605@Sun.COM> <2653BDFF-DB75-4014-8AA6-30487BFCB497@sun.com> <48B6C386.2090509@Sun.COM> <48B6F820.7050305@Sun.COM> Original-recipient: rfc822;sig-prg@sun.com --Boundary_(ID_WkLORA86qxd+TiWlwD86qg) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Hello Mike, On Aug 28, 2008, at 21:10, Mike Sullivan wrote: > Jaromir Sedlacek wrote: >> Then there is lot of things which does not conform with this. >> Starting with WebRTI where deliverable object list is based on >> object path and not on package ownership. S10 patches has issues too. > > WebRTI doesn't enforce your deliverable list is right either, which is > a bigger issue. But I'm not sure how relevant that is. > That is something what we (patch GKs) are already addressing. We have developed PRC tool which checks patch RTIs from GKs perspective, including deliverable objects. It works for any saved RTI (for prelim and temp too). We are just piloting AutoPRC which is checking RTIs after they are updated and we plan to implement it prior ON10 U7B1. I am attaching example of AutoPRC report. PRC documentation is available at https://sig-wiki.czech.sun.com/Wiki.jsp?page=Quick_guide_AutoPRC or more detail https://sig-wiki.czech.sun.com/Wiki.jsp?page=HOWTOUsePublicRTIChecker . Best regards, Jaromir --Boundary_(ID_WkLORA86qxd+TiWlwD86qg) Content-type: message/rfc822; x-unix-mode=0644; name="AutoPRC Failed: RTI 325402 (on: 5.10_update[SUBMITTED ] 5.10_sustaining[SUBMITTED ])" Return-path: Received: from fe-emea-10.sun.com ([192.18.6.120]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K5Y00I5WTJMAR20@emea1-mail1.uk.sun.com>; Thu, 21 Aug 2008 20:16:34 +0100 (BST) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5Y00F01THQSB00@fe-emea-10.sun.com> (ORCPT sig-prc@Sun.COM); Thu, 21 Aug 2008 20:16:34 +0100 (BST) Received: from phys-emea1-2.uk.sun.com ([192.18.6.12]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K5Y00FKZTJL6000@fe-emea-10.sun.com> (ORCPT sig-prc@Sun.COM); Thu, 21 Aug 2008 20:16:33 +0100 (BST) Received: from dm-czech-02.uk.sun.com ([129.156.101.215]) by emea1-mail1.uk.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0K5Y00I5MTJLAR20@emea1-mail1.uk.sun.com> (ORCPT sig-prc@Sun.COM); Thu, 21 Aug 2008 20:16:33 +0100 (BST) Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by dm-czech-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m7LJGW3V009387; Thu, 21 Aug 2008 20:16:33 +0100 (BST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7LJGWNC012024 for <@sunmail2sca.sfbay.sun.com:sig-prc@Sun.COM>; Thu, 21 Aug 2008 12:16:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5Y00101TJHJU00@nwk-avmta-2.sfbay.sun.com> for sig-prc@Sun.COM (ORCPT sig-prc@Sun.COM); Thu, 21 Aug 2008 12:16:29 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5Y00FO6TJHNHB0@nwk-avmta-2.sfbay.sun.com> for sig-prc@Sun.COM (ORCPT sig-prc@Sun.COM); Thu, 21 Aug 2008 12:16:29 -0700 (PDT) Received: from sig-prd.sfbay.sun.com (sig-prd.SFBay.Sun.COM [10.4.161.154]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7LJGSU3059220 for ; Thu, 21 Aug 2008 12:16:29 -0700 (PDT) Received: from sig-prd.sfbay.sun.com (localhost [127.0.0.1]) by sig-prd.sfbay.sun.com (8.13.4+Sun/8.13.3) with ESMTP id m7LJGN55007773 for ; Thu, 21 Aug 2008 12:16:24 -0700 (PDT) Received: (from prtiroute@localhost) by sig-prd.sfbay.sun.com (8.13.4+Sun/8.13.3/Submit) id m7LJGKrT007771; Thu, 21 Aug 2008 12:16:20 -0700 (PDT) Date: Thu, 21 Aug 2008 12:16:20 -0700 (PDT) From: sig-prc@sun.com Subject: AutoPRC Failed: RTI 325402 (on: 5.10_update[SUBMITTED ] 5.10_sustaining[SUBMITTED ]) To: sig-prc@sun.com Message-id: <200808211916.m7LJGKrT007771@sig-prd.sfbay.sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_1eMaXw066hy9iO2mvXDuxg)" X-PMX-Version: 5.4.1.325704 Original-recipient: rfc822;sig-prc@Sun.COM This is MIME multipart mail message --Boundary_(ID_1eMaXw066hy9iO2mvXDuxg) Content-type: text/plain Content-transfer-encoding: 7BIT ORIGINAL RECIPIENTS: Jack.Lee@Sun.COM Jim.Pugsley@Sun.COM shwp-pm@sun.com sig-prc@Sun.COM AutoPRC has detected potential problems in RTI 325402 These errors may prevent further processing of this RTI by gatekeepers. For more details please click on the link containing full error report bellow. If you think the errors detected by AutoPRC are false positives please let us know. RTI: http://webrti.sfbay.sun.com/rti/view.php?r=325402 REPORT_LOCATION: http://sig-prd.sfbay.sun.com/autoprc-reports/prc_report_325402_2008-08-21_12-15-05_1966.xml DATE: 2008-08-21 12:15:06 PDT GATE: 5.10_update STATUS: S_SUBMITTED REQUESTOR: Jack.Lee@Sun.COM EVALUATOR: Jim.Pugsley@Sun.COM FIRST CR: 6739508 GATE: 5.10_sustaining STATUS: S_SUBMITTED REQUESTOR: Jack.Lee@Sun.COM EVALUATOR: Jim.Pugsley@Sun.COM FIRST CR: 6739508 DETAILS: RTI: 325402 =========== GATE: 5.10_sustaining ~~~~~~~~~~~ ARCH: SPARC ----------- ERROR: "Non existing object "platform/sun4us/kernel/sparcv9/genunix"" --Boundary_(ID_1eMaXw066hy9iO2mvXDuxg)-- --Boundary_(ID_WkLORA86qxd+TiWlwD86qg) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT > The key is that packages aren't supposed to overwrite each others > files. > The problem is that some do indeed need to share common files (like > ones that ON provides, say the RBAC ones here) and the class-action > script method is used to handle that. > > RE does enforce some things at package integration time and I think > that is where cross-consolidation attempts to deliver the same > file (as 'f none', not 'e specificclassactionscript') would be caught. > Within the consolidation protocmp should be catching that I think > (for ON and SFW at least). > > I think they miss symlinks though and we do have that in a few > packages. And of course they can't check directories. > > patches have their own mystical process which hopefully also catch > this. > > Mike > >> I am sorry for not carefully reading that document. >> Thanks and regards, >> Jaromir >> On Aug 28, 2008, at 17:25, Norm Jacobs wrote: >>> Editable files are exempt from this exactly so they can be >>> delivered as fragments. It's the point of the rbac and some of >>> the other class action scripts. >>> Static files are not exempt and for good reason. >>> >>> -Norm >>> >>> Jaromir Sedlacek wrote: >>>> Hi Norm, >>>> >>>> Files which belongs to multiple packages are against approved >>>> packaging architecture and they are causing significant issues >>>> later when product is in sustaining cycle. >>>> >>>> Quoting from http://sac.sfbay/PSARC/1996/039/commit.materials/SW_Pkg_Rqrmts.ps >>>> page 48: >>>> >>>> >>>> As a general rule, redundant deliverables across packages are not >>>> allowed. >>>> >>> Please read a little further on (page 49, 1st paragraph) >>> >>> One package object type is exempt to the non-redundancy rule, the >>> editable file. >>> Since editable files do not replace existing files, but are edited >>> during >>> installation and upggrade by means of class action scripts, they >>> may appear in >>> multiple packages without the need for a formal architectural >>> approval. >>> >>> >>>> >>>> and from http://sac.sfbay/PSARC/1991/061/spec.opensolaris : >>>> >>>> >>>> The Rule >>>> >>>> Again, the rule is: >>>> Each component of the system may be provided in only one package. >>>> >>>> >>>> Best regards, >>>> Jaromir >>>> >>>> On Aug 28, 2008, at 16:32, Norm Jacobs wrote: >>>> >>>>> >>>>> The entries belong with your component in it's packaging in the >>>>> SFW gate. You can use the approach that the SUNWmmsr package >>>>> takes in the ON gate. That is, it contains a package specific >>>>> fragment file in the packaging directory and has the prototype >>>>> refer directly to it instead of the proto area. >>>>> >>>>> Ex: >>>>> >>>>> usr/src/pkgdefs/SUNWfoor/prototype_com: >>>>> >>>>> i i.rbac >>>>> i r.rbac >>>>> e rbac etc/security/exec_attr=./exec_attr 644 root sys >>>>> >>>>> usr/src/pkgdefs/SUNWfoor/exec_attr: >>>>> >>>>> # >>>>> # CDDL HEADER START >>>>> # >>>>> # The contents of this file are subject to the terms of the >>>>> # Common Development and Distribution License (the "License"). >>>>> # You may not use this file except in compliance with the License. >>>>> # >>>>> # You can obtain a copy of the license at usr/src/ >>>>> OPENSOLARIS.LICENSE >>>>> # or http://www.opensolaris.org/os/licensing. >>>>> # See the License for the specific language governing permissions >>>>> # and limitations under the License. >>>>> # >>>>> # When distributing Covered Code, include this CDDL HEADER in each >>>>> # file and include the License file at usr/src/ >>>>> OPENSOLARIS.LICENSE. >>>>> # If applicable, add the following below this CDDL HEADER, with >>>>> the >>>>> # fields enclosed by brackets "[]" replaced with your own >>>>> identifying >>>>> # information: Portions Copyright [yyyy] [name of copyright owner] >>>>> # >>>>> # CDDL HEADER END >>>>> # >>>>> # Copyright 2008 Sun Microsystems, Inc. All rights reserved. >>>>> # Use is subject to license terms. >>>>> # >>>>> #ident "@(#)exec_attr 1.7 07/01/07 SMI" >>>>> # >>>>> Network Management:solaris:cmd:::/usr/sbin/quaggaadm:privs=basic >>>>> Network Management:solaris:cmd:::/usr/sbin/zebraadm:privs=basic >>>>> >>>>> I expect that we will change to the fragment approach soon, but >>>>> other SFW components delivering RBAC fragments are editing a >>>>> common exec_attr file in the sfw gate (${sfw_workspace}/usr/src/ >>>>> common/rbac/exec_attr) and adding the rbac class action script >>>>> and an entry for the exec_attr file their root package's >>>>> prototype file. So, for now, this would be acceptable as well. >>>>> >>>>> -Norm >>>>> >>>>> >>>>> >>>>> >>>>> martina tomisova - Sun Microsystems - Prague Czech Republic wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm integrating the ngrep package to the Nevada SFW. There is a >>>>>> need of adding one line to the /etc/security/exec_attr file. >>>>>> I've consulted this with sustaining gatekeepers. The results of >>>>>> our consultation are: >>>>>> >>>>>> >>>>>> 1. I should put the SUNWngrep to the sfwnv-gate in a common way >>>>>> without editing the exec_attr file. I should modify the >>>>>> exec_attr file at the SUNWcsr package at onnv-gate. SUNWngrep >>>>>> should depend on SUNWcsr. >>>>>> >>>>>> >>>>>> 2. There are some other packages that modify this exec_attr >>>>>> file (by class action script) at sfwnv-gate and onnv-gate. >>>>>> There is a list: >>>>>> >>>>>> $ ls -l /ws/onnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/ >>>>>> security/exec_attr >>>>>> -rw-r--r-- 1 root sys 17653 Aug 26 00:10 /ws/onnv- >>>>>> gate/packages/sparc/nightly-nd/SUNWcsr/reloc/etc/security/ >>>>>> exec_attr >>>>>> -rw-r--r-- 1 root sys 1190 Aug 15 00:00 /ws/onnv- >>>>>> gate/packages/sparc/nightly-nd/SUNWmmsr/reloc/etc/security/ >>>>>> exec_attr >>>>>> >>>>>> $ ls -l /ws/sfwnv-gate/packages/sparc/nightly-nd/S*/reloc/etc/ >>>>>> security/exec_attr >>>>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >>>>>> gate/packages/sparc/nightly-nd/SUNWmkcdr/reloc/etc/security/ >>>>>> exec_attr >>>>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >>>>>> gate/packages/sparc/nightly-nd/SUNWpostgr-82-server-data-root/ >>>>>> reloc/etc/security/exec_attr >>>>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >>>>>> gate/packages/sparc/nightly-nd/SUNWpostgr-83-server-data-root/ >>>>>> reloc/etc/security/exec_attr >>>>>> -rw-r--r-- 1 root sys 2082 Aug 26 02:09 /ws/sfwnv- >>>>>> gate/packages/sparc/nightly-nd/SUNWquaggar/reloc/etc/security/ >>>>>> exec_attr >>>>>> >>>>>> Sustaining gatekeepers are afraid that this is not very clean >>>>>> and nice state which can (and should) be cleaned now however it >>>>>> won't be able to be cleaned after they will control this gate. >>>>>> They thing that the solution with editing SUNWcsr file is the >>>>>> cleanest and nicest way. >>>>>> >>>>>> >>>>>> So can you please provide me some more information how am I >>>>>> supposed to solve this situation and who should I contact about >>>>>> the chages at onnv-gate? >>>>>> >>>>>> Thank you, >>>>>> Martina >>>>> >>>> >>> > --Boundary_(ID_WkLORA86qxd+TiWlwD86qg)-- --Boundary_(ID_/Dls5icIt3FDBS60Obvcpw)-- From Nicolas.Williams@sun.com Fri Sep 5 08:33:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85FXi3l014055 for ; Fri, 5 Sep 2008 08:33:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m85FXXt4007598; Fri, 5 Sep 2008 16:33:42 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00C0HB85VO00@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Sep 2008 08:33:41 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q00BS8B85DW30@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Sep 2008 08:33:41 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m85FXeNT003152; Fri, 05 Sep 2008 10:33:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m85FXdtP003151; Fri, 05 Sep 2008 10:33:39 -0500 (CDT) Date: Fri, 05 Sep 2008 10:33:39 -0500 From: Nicolas Williams Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C121F8.9060702@Sun.COM> To: Martina Tomisova Cc: Darren J Moffat , Brian Utterback , PSARC-ext@sun.com Message-id: <20080905153339.GS1524@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1089 On Fri, Sep 05, 2008 at 02:11:36PM +0200, Martina Tomisova wrote: > Hi Darren, > > there was a quite long discussion (see attachment) with Norm Jacobs and > Mike Sullivan about this topic. The final recommendation for me was to > user class action script. That can't be right, can it? Of course, that would be the correct approach in the old world of SVR4 packaging. But now that OpenSolaris and IPS (which has no package scripting) are in the picture one would think that we should minimize new uses of class action scripts (CAS). Now, perhaps the SFWNV gatekeepers and the IPS team are in touch and they agree that adding new CAS uses in SFWNV is OK -- after all it's only one more bit of work for the IPS folks to do to deal with this. What has this to do with ARC? As long as the gatekeepers and the IPS team agree on a way forward in such cases, then I think the answer is: nothing. But if they haven't discussed it, or haven't reached agreement yet, then I think the ARC may be interested in making sure that one is reached before approving of any more CAS uses. Nico -- From Martina.Tomisova@sun.com Mon Sep 8 00:29:52 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m887Tps6004284 for ; Mon, 8 Sep 2008 00:29:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m887TeNn021776 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 8 Sep 2008 08:29:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6V002018TNY000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 00:29:47 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6V00IO68TMC750@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 00:29:47 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m887TkiI007912 for ; Mon, 08 Sep 2008 07:29:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6V00E017JCMR00@fe-emea-10.sun.com> (original mail from Martina.Tomisova@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 08:29:46 +0100 (BST) Received: from [129.157.16.195] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6V00FTX8TBWI30@fe-emea-10.sun.com>; Mon, 08 Sep 2008 08:29:37 +0100 (BST) Date: Mon, 08 Sep 2008 09:29:35 +0200 From: Martina Tomisova Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <20080905153339.GS1524@Sun.COM> Sender: Martina.Tomisova@sun.com To: Nicolas Williams Cc: Darren J Moffat , Brian Utterback , PSARC-ext@sun.com Message-id: <48C4D45F.9060308@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 274 Hi Nicolas, > That can't be right, can it? It seems it can. I'm integrating the package into the Nevada so as I'm informed it has nothing to do with IPS team and Indiana. And Nevada SFW gatekeepers recommended me to use the class action script. Have a nice day, Martina From Darren.Moffat@sun.com Mon Sep 8 02:07:12 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8897BWl008290 for ; Mon, 8 Sep 2008 02:07:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m88976Io002930 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 8 Sep 2008 17:07:10 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6V00G17DBWHA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 03:07:08 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6V00FAQDBVZN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 03:07:07 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m88976dF028289 for ; Mon, 08 Sep 2008 09:07:06 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6V00901BA1M900@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 10:07:06 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6V00FAFDBNWIA0@fe-emea-10.sun.com>; Mon, 08 Sep 2008 10:07:00 +0100 (BST) Date: Mon, 08 Sep 2008 10:06:59 +0100 From: Darren J Moffat Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C4D45F.9060308@Sun.COM> Sender: Darren.Moffat@sun.com To: Martina Tomisova Cc: Nicolas Williams , Brian Utterback , PSARC-ext@sun.com Message-id: <48C4EB33.7070301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080811) Status: RO Content-Length: 785 Martina Tomisova wrote: > Hi Nicolas, > >> That can't be right, can it? > It seems it can. I'm integrating the package into the Nevada so as I'm > informed it has nothing to do with IPS team and Indiana. And Nevada SFW > gatekeepers recommended me to use the class action script. However the ARC members are advising you to do something different not just because of IPS (in fact not because of IPS at all!) but because I think that creating a package purely to run a class action script when there is a neater and simpler solution of integrating the line into ON. I'd like to hear from other ARC members on this but I feel that introducing a root package just for updating exec_attr is wasteful, even though it does mean putbacks to two consolidations. -- Darren J Moffat From brian.utterback@sun.com Wed Sep 10 05:55:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8ACtXnS019136 for ; Wed, 10 Sep 2008 05:55:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8ACtQx0025440 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 20:55:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00409D8GHL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 05:55:28 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z002ECD8F0A10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 05:55:27 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8ACtN5R062663; Wed, 10 Sep 2008 08:55:24 -0400 (EDT) Date: Wed, 10 Sep 2008 08:55:23 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C4EB33.7070301@Sun.COM> To: Darren J Moffat Cc: Martina Tomisova , Nicolas Williams , Brian Utterback , PSARC-ext@sun.com Message-id: <48C7C3BB.6030906@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 1085 Darren J Moffat wrote: > I'd like to hear from other ARC members on this but I feel that > introducing a root package just for updating exec_attr is wasteful, even > though it does mean putbacks to two consolidations. > So, do I take the lack of further comment as assent? Is the plan to simply add a line to exec_attr and forgo the *r package? By the way, does that have any ramifications for possible name collisions? If as a nefarious evil genius bent on world domination, if I wrote a FOSS package that happens to install (amongst other items) a binary called "/usr/sbin/ngrep" that installs a rootkit when run as root, would that amount to priv elevation if run by the network admin? I guess I am asking if there is an issue with decoupling the exec_attr line from the actual binary installation? -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Darren.Moffat@sun.com Wed Sep 10 06:05:23 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AD5Mxo019293 for ; Wed, 10 Sep 2008 06:05:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AD5GlV006914 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 14:05:21 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00503DOWI000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 06:05:20 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z002ZCDOV0010@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 06:05:20 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8AD5Iq9027683 for ; Wed, 10 Sep 2008 13:05:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Z00D01CED7J00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 14:05:18 +0100 (BST) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Z000XIDO8HFC0@fe-emea-09.sun.com>; Wed, 10 Sep 2008 14:04:57 +0100 (BST) Date: Wed, 10 Sep 2008 14:04:56 +0100 From: Darren J Moffat Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C7C3BB.6030906@sun.com> Sender: Darren.Moffat@sun.com To: Brian Utterback Cc: Martina Tomisova , Nicolas Williams , Brian Utterback , PSARC-ext@sun.com Message-id: <48C7C5F8.1050009@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 1705 Brian Utterback wrote: > > > Darren J Moffat wrote: > >> I'd like to hear from other ARC members on this but I feel that >> introducing a root package just for updating exec_attr is wasteful, >> even though it does mean putbacks to two consolidations. >> > > So, do I take the lack of further comment as assent? Is the plan to > simply add a line to exec_attr and forgo the *r package? That is my strong preference but it seems no other ARC members are either listening or have an opinion on this that they wish to share. > By the way, does that have any ramifications for possible name > collisions? If as a nefarious evil genius bent on world domination, if I > wrote a FOSS package that happens to install (amongst other items) a > binary called "/usr/sbin/ngrep" that installs a rootkit when run as > root, would that amount to priv elevation if run by the network admin? Yes it would but that is in no way prevented by splitting the installation of this projects components over two packages. But then if you can get someone to install a package with a trojan horse ngrep why bother with exec_attr entries just make the trojan ngrep setuid, or even why bother with that you may was well just install the rootkit straight out of the package. > I guess I am asking if there is an issue with decoupling the exec_attr > line from the actual binary installation? No, and in many cases delivered by ON there are entries in the exec_attr file when the corresponding packages that deliver those binaries are not present. Also remember that your exec_attr table might not be local or even hosted on the same OS release so we already have that situation anyway. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Wed Sep 10 07:03:28 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AE3R8T020848 for ; Wed, 10 Sep 2008 07:03:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8AE3Egg018985; Wed, 10 Sep 2008 22:03:19 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00I1HGDI8G00@brm-avmta-1.central.sun.com>; Wed, 10 Sep 2008 08:03:18 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z009OHGDH5MD0@brm-avmta-1.central.sun.com>; Wed, 10 Sep 2008 08:03:18 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8AE3GVH029014; Wed, 10 Sep 2008 10:03:16 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8AE3Gc9029011; Wed, 10 Sep 2008 10:03:16 -0400 (EDT) Date: Wed, 10 Sep 2008 10:03:16 -0400 From: James Carlson Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C7C5F8.1050009@Sun.COM> To: Darren J Moffat Cc: Brian Utterback , Martina Tomisova , Nicolas Williams , Brian Utterback , PSARC-ext@sun.com Message-id: <18631.54180.811183.540092@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> Status: RO Content-Length: 724 Darren J Moffat writes: > > So, do I take the lack of further comment as assent? Is the plan to > > simply add a line to exec_attr and forgo the *r package? > > That is my strong preference but it seems no other ARC members are > either listening or have an opinion on this that they wish to share. I think it's a bit of teak polishing. Either will work fine, neither appears to me to have architectural significance, and if the project and/or consolidation team have a preference, go for that. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Wed Sep 10 07:16:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AEG0HI020934 for ; Wed, 10 Sep 2008 07:16:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AEFv42006213 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 15:15:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00C0HGYMIU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:15:58 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z002OZGYJ0650@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:15:56 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8AEFtb7006681 for ; Wed, 10 Sep 2008 14:15:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Z00101GENLA00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 15:15:55 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Z00C4ZGYICR10@fe-emea-10.sun.com>; Wed, 10 Sep 2008 15:15:54 +0100 (BST) Date: Wed, 10 Sep 2008 15:15:54 +0100 From: Darren J Moffat Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <18631.54180.811183.540092@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: James Carlson Cc: Brian Utterback , Martina Tomisova , Nicolas Williams , Brian Utterback , PSARC-ext@sun.com Message-id: <48C7D69A.5070204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 1292 James Carlson wrote: > Darren J Moffat writes: >>> So, do I take the lack of further comment as assent? Is the plan to >>> simply add a line to exec_attr and forgo the *r package? >> That is my strong preference but it seems no other ARC members are >> either listening or have an opinion on this that they wish to share. > > I think it's a bit of teak polishing. Either will work fine, neither > appears to me to have architectural significance, and if the project > and/or consolidation team have a preference, go for that. I think this does have architectural significance which is why I brought it up. How something is packaged up and split across multiple packages is something we normally expect to review in ARC, particularly when the reason for the split is to support zones and diskless clients that require separate root and usr packages (in the SRV4 package model but not with IPS). As proposed with a root package this case is exposing, as a package name, something that is essentially an implementation issue of RBAC and our current requirement to have root and usr packages separate. This seems a waste of a package unless there will ever be anything else delivered in a root package by ngrep. Like it or not package names are interfaces. -- Darren J Moffat From brian.utterback@sun.com Wed Sep 10 07:25:29 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AEPT8V021008 for ; Wed, 10 Sep 2008 07:25:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AEPSZN061456 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 08:25:29 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00D0NHEGEH00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:25:28 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z002VYHEE0A70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:25:27 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AEPMlG040966; Wed, 10 Sep 2008 10:25:23 -0400 (EDT) Date: Wed, 10 Sep 2008 10:25:22 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C7D69A.5070204@Sun.COM> To: Darren J Moffat Cc: James Carlson , Martina Tomisova , Nicolas Williams , Brian Utterback , PSARC-ext@sun.com Message-id: <48C7D8D2.3050100@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 1791 Okay, so Jim says either is fine, and you say one is better. So, as far as this case is concerned, the project team will do it your way, and you and Jim can be in violent agreement. Darren J Moffat wrote: > James Carlson wrote: >> Darren J Moffat writes: >>>> So, do I take the lack of further comment as assent? Is the plan to >>>> simply add a line to exec_attr and forgo the *r package? >>> That is my strong preference but it seems no other ARC members are >>> either listening or have an opinion on this that they wish to share. >> >> I think it's a bit of teak polishing. Either will work fine, neither >> appears to me to have architectural significance, and if the project >> and/or consolidation team have a preference, go for that. > > I think this does have architectural significance which is why I brought > it up. How something is packaged up and split across multiple packages > is something we normally expect to review in ARC, particularly when the > reason for the split is to support zones and diskless clients that > require separate root and usr packages (in the SRV4 package model but > not with IPS). > > As proposed with a root package this case is exposing, as a package > name, something that is essentially an implementation issue of RBAC and > our current requirement to have root and usr packages separate. This > seems a waste of a package unless there will ever be anything else > delivered in a root package by ngrep. > > Like it or not package names are interfaces. > -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From carlsonj@phorcys.east.sun.com Wed Sep 10 07:31:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AEVhCT021122 for ; Wed, 10 Sep 2008 07:31:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AEVa6b013220; Wed, 10 Sep 2008 15:31:41 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00K0LHOT2A00@brm-avmta-1.central.sun.com>; Wed, 10 Sep 2008 08:31:41 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z00JJ8HORP400@brm-avmta-1.central.sun.com>; Wed, 10 Sep 2008 08:31:39 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8AEVcfV029309; Wed, 10 Sep 2008 10:31:38 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8AEVc2N029306; Wed, 10 Sep 2008 10:31:38 -0400 (EDT) Date: Wed, 10 Sep 2008 10:31:38 -0400 From: James Carlson Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C7D69A.5070204@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, Brian Utterback , Martina Tomisova , Brian Utterback Message-id: <18631.55882.626225.379121@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> Status: RO Content-Length: 2257 Darren J Moffat writes: > James Carlson wrote: > > I think it's a bit of teak polishing. Either will work fine, neither > > appears to me to have architectural significance, and if the project > > and/or consolidation team have a preference, go for that. > > I think this does have architectural significance which is why I brought > it up. How something is packaged up and split across multiple packages > is something we normally expect to review in ARC, In general, agree. > particularly when the > reason for the split is to support zones and diskless clients that > require separate root and usr packages (in the SRV4 package model but > not with IPS). Also, in general, agree. Just not for this case. > As proposed with a root package this case is exposing, as a package > name, something that is essentially an implementation issue of RBAC and > our current requirement to have root and usr packages separate. This > seems a waste of a package unless there will ever be anything else > delivered in a root package by ngrep. Actually, I think that's directly contradicted by your previous assertions. Creating a separate tiny root package allows the owner of a system with writable RBAC files but without a writable '/usr' to install the necessary bits to make this feature work. If it's done as you're suggesting, as a single 'usr' type package with a postinstall, then the owner of such a machine simply cannot install the necessary RBAC bits, except by hand, as the 'usr' package is inapplicable. The fact that RBAC control files are in the root file system and that this feature comes with RBAC bits as part of the packaged information seems to argue to me that (at least under the dying svr4 system) it ought to have a separate package for those bits, no matter how slight. However, I also don't think it matters terribly much. > Like it or not package names are interfaces. I wasn't disputing that. Only that for this particular case minimizing the number of packages seems like teak polishing. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From brian.utterback@sun.com Wed Sep 10 07:42:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AEgfQ9021356 for ; Wed, 10 Sep 2008 07:42:42 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AEgaG1017962 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 15:42:41 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00K0JI73QG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 08:42:39 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z00JBEI72PA10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 08:42:38 -0600 (MDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AEgYqE046712; Wed, 10 Sep 2008 10:42:35 -0400 (EDT) Date: Wed, 10 Sep 2008 10:42:34 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <18631.55882.626225.379121@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C7DCDA.8080602@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 1024 James Carlson wrote: > Creating a separate tiny root package allows the owner of a system > with writable RBAC files but without a writable '/usr' to install the > necessary bits to make this feature work. If it's done as you're > suggesting, as a single 'usr' type package with a postinstall, then > the owner of such a machine simply cannot install the necessary RBAC > bits, except by hand, as the 'usr' package is inapplicable. > Maybe I am misunderstanding Darren, but I thought his proposal was to make the integration of ngrep into SFW also have the addition of the ngrep line into the default exec_attr file as a parallel but separate integration into ON, thus obviating the need to do any post/pre install anything at pkg install time. -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Darren.Moffat@sun.com Wed Sep 10 07:45:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AEj06q021371 for ; Wed, 10 Sep 2008 07:45:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AEiula018959 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 15:44:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00F0BIAZ5T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:44:59 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z002BBIAX0670@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:44:58 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8AEivjw012978 for ; Wed, 10 Sep 2008 14:44:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Z00101GENLA00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 15:44:57 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Z00C27IACCR30@fe-emea-10.sun.com>; Wed, 10 Sep 2008 15:44:36 +0100 (BST) Date: Wed, 10 Sep 2008 15:44:35 +0100 From: Darren J Moffat Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <18631.55882.626225.379121@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: James Carlson Cc: PSARC-ext@sun.com, Brian Utterback , Martina Tomisova , Brian Utterback Message-id: <48C7DD53.3050304@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 1896 James Carlson wrote: > Darren J Moffat writes: >> James Carlson wrote: >>> I think it's a bit of teak polishing. Either will work fine, neither >>> appears to me to have architectural significance, and if the project >>> and/or consolidation team have a preference, go for that. >> I think this does have architectural significance which is why I brought >> it up. How something is packaged up and split across multiple packages >> is something we normally expect to review in ARC, > > In general, agree. > >> particularly when the >> reason for the split is to support zones and diskless clients that >> require separate root and usr packages (in the SRV4 package model but >> not with IPS). > > Also, in general, agree. Just not for this case. > >> As proposed with a root package this case is exposing, as a package >> name, something that is essentially an implementation issue of RBAC and >> our current requirement to have root and usr packages separate. This >> seems a waste of a package unless there will ever be anything else >> delivered in a root package by ngrep. > > Actually, I think that's directly contradicted by your previous > assertions. > > Creating a separate tiny root package allows the owner of a system > with writable RBAC files but without a writable '/usr' to install the > necessary bits to make this feature work. If it's done as you're > suggesting, as a single 'usr' type package with a postinstall, then > the owner of such a machine simply cannot install the necessary RBAC > bits, except by hand, as the 'usr' package is inapplicable. I never suggested that it be done in a usr package because I know that will break sparse root zones. What I suggested is that the exec_attr entry be intgrated into the master exec_attr file in ON $SRC/lib/libsecdb/exec_attr.txt. That file is delivered from an ON root package. -- Darren J Moffat From Darren.Moffat@sun.com Wed Sep 10 07:46:08 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AEk8kQ021387 for ; Wed, 10 Sep 2008 07:46:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AEk0fG004911 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 08:46:07 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00011ICV3X00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:46:07 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z00HE6ICT3EE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:46:06 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8AEk52T011679 for ; Wed, 10 Sep 2008 14:46:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Z00G01HPLAS00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 15:46:05 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Z00C4HIBZCR30@fe-emea-10.sun.com>; Wed, 10 Sep 2008 15:45:36 +0100 (BST) Date: Wed, 10 Sep 2008 15:45:35 +0100 From: Darren J Moffat Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C7DCDA.8080602@sun.com> Sender: Darren.Moffat@sun.com To: Brian Utterback Cc: James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C7DD8F.2070609@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 855 Brian Utterback wrote: > > > James Carlson wrote: > >> Creating a separate tiny root package allows the owner of a system >> with writable RBAC files but without a writable '/usr' to install the >> necessary bits to make this feature work. If it's done as you're >> suggesting, as a single 'usr' type package with a postinstall, then >> the owner of such a machine simply cannot install the necessary RBAC >> bits, except by hand, as the 'usr' package is inapplicable. >> > > Maybe I am misunderstanding Darren, but I thought his proposal was to > make the integration of ngrep into SFW also have the addition of the > ngrep line into the default exec_attr file as a parallel but separate > integration into ON, thus obviating the need to do any post/pre install > anything at pkg install time. You understood me correctly. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Wed Sep 10 07:52:22 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AEqM5r021571 for ; Wed, 10 Sep 2008 07:52:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AEqHPl001897; Wed, 10 Sep 2008 07:52:17 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00F0FIN4XF00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 10 Sep 2008 07:52:16 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z002IKIN40890@nwk-avmta-1.sfbay.Sun.COM>; Wed, 10 Sep 2008 07:52:16 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8AEqF9v029532; Wed, 10 Sep 2008 10:52:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8AEqFOD029529; Wed, 10 Sep 2008 10:52:15 -0400 (EDT) Date: Wed, 10 Sep 2008 10:52:15 -0400 From: James Carlson Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C7DD53.3050304@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, Brian Utterback , Martina Tomisova , Brian Utterback Message-id: <18631.57119.45804.914307@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DD53.3050304@Sun.COM> Status: RO Content-Length: 1070 Darren J Moffat writes: > What I suggested is that the exec_attr entry be intgrated into the > master exec_attr file in ON $SRC/lib/libsecdb/exec_attr.txt. That file > is delivered from an ON root package. Ah, ok. In that case, it's truly six of one and half dozen of another. You're talking about either a small extra package to deliver versus a mandatory patch/upgrade of a well-trodden ON package to accompany this new package. I don't see a lot of benefit in either approach, so just pick either one and move on. If we had a policy that said "all RBAC bits for bundled components must be delivered through ON," then that'd be another matter. But there are several examples of things already in SFW that deliver their own RBAC file updates, so I don't see what the extended discussion and appeal to other members to comment is about. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From brian.utterback@sun.com Wed Sep 10 07:59:52 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AExqik021994 for ; Wed, 10 Sep 2008 07:59:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AExpfi011038 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 08:59:52 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z0001TIZQK300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:59:50 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z00064IZPHP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 07:59:50 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AExkcf051920; Wed, 10 Sep 2008 10:59:46 -0400 (EDT) Date: Wed, 10 Sep 2008 10:59:46 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <18631.57119.45804.914307@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C7E0E2.40804@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DD53.3050304@Sun.COM> <18631.57119.45804.914307@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 514 James Carlson wrote: > so I don't see what the extended discussion and > appeal to other members to comment is about. > As I said, violent agreement. I was just trying to make sure there weren't any unresolved conflicts, and there weren't. -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From gww@eng.sun.com Wed Sep 10 08:41:54 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AFfs0a023374 for ; Wed, 10 Sep 2008 08:41:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AFfZA3002698 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 08:41:54 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00K07KXRE500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 08:41:51 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z002HOKXR03D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 08:41:51 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AFfm0x023333; Wed, 10 Sep 2008 08:41:48 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m8AFbkAu012317; Wed, 10 Sep 2008 08:37:46 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m8AFbkFu012316; Wed, 10 Sep 2008 08:37:46 -0700 (PDT) Date: Wed, 10 Sep 2008 08:37:46 -0700 (PDT) From: Gary Winiger Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] To: James.D.Carlson@sun.com, brian.utterback@sun.com Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, Martina.Tomisova@sun.com, blu@sac.sfbay.sun.com Message-id: <200809101537.m8AFbkFu012316@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 805 > As I said, violent agreement. I was just trying to make sure there > weren't any unresolved conflicts, and there weren't. Jumping in late and probably missing some important mail, but.... Documented best practice (pre IPS -- which really doesn't exist yet from an ARC perspective) is that consolidations deliver their own RBAC database entries and use the i.rbac class action script to install them. Beyond that the IPS team needs to provide an equivalent best practice. Failing that, if the ngrep project team doesn't get ARCable advice from the IPS team, I (thought not confirmed with others of the RBAC project team) would advise doing the expedient and integrating into both SFW and ON. More concerning for the i.rbac class action script are unbundleds. Still on sabbatical, Gary.. From Norm.Jacobs@sun.com Wed Sep 10 10:09:29 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AH9T64028689 for ; Wed, 10 Sep 2008 10:09:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AH9SQh002445 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 10 Sep 2008 10:09:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z0060DOZS0A00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 10 Sep 2008 10:09:28 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z000JGOZR5D50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 10 Sep 2008 10:09:27 -0700 (PDT) Received: from printing.eng.sun.com (printing.SFBay.Sun.COM [129.146.178.26]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AH9OIp029244; Wed, 10 Sep 2008 10:09:24 -0700 (PDT) Received: from [10.7.251.237] (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.eng.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8AHB5Tu014456; Wed, 10 Sep 2008 10:11:06 -0700 (PDT) Date: Wed, 10 Sep 2008 12:09:19 -0500 From: Norm Jacobs Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C7DD8F.2070609@Sun.COM> To: Darren J Moffat Cc: Brian Utterback , James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C7FF3F.6060209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 1308 Darren J Moffat wrote: > Brian Utterback wrote: >> >> >> James Carlson wrote: >> >>> Creating a separate tiny root package allows the owner of a system >>> with writable RBAC files but without a writable '/usr' to install the >>> necessary bits to make this feature work. If it's done as you're >>> suggesting, as a single 'usr' type package with a postinstall, then >>> the owner of such a machine simply cannot install the necessary RBAC >>> bits, except by hand, as the 'usr' package is inapplicable. >>> >> >> Maybe I am misunderstanding Darren, but I thought his proposal was to >> make the integration of ngrep into SFW also have the addition of the >> ngrep line into the default exec_attr file as a parallel but separate >> integration into ON, thus obviating the need to do any post/pre >> install anything at pkg install time. > > You understood me correctly. > I missed much of this thread and I'm not a PSARC member, so my vote doesn't count here, but... If you can avoid it, please don't split your delivery across consolidations. I would like to avoid adding places where we introduce a potential need to coordinate integrations and/or where any future orphaning that may occur. There are several components in SFW that already deliver root packages with RBAC entries. -Norm From brian.utterback@sun.com Wed Sep 10 10:12:20 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AHCKjq028842 for ; Wed, 10 Sep 2008 10:12:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AHCJiA006912 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 11:12:20 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z0050JP4J4C00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 10:12:19 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z000CIP4IHLB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 10:12:19 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AHCGwA043473; Wed, 10 Sep 2008 13:12:17 -0400 (EDT) Date: Wed, 10 Sep 2008 13:12:16 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> To: PSARC-ext@sun.com Cc: martina tomisova - Sun Microsystems - Prague Czech Republic Message-id: <48C7FFF0.202@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041203.m84C3GjB005331@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 22218 This case was approved in today's PSARC meeting. Brian Utterback wrote: > I am sponsoring the following fast-track for Martina Tomisova. This case > proposes to integrate the ngrep open-source utility into the SFW consolidation. > A patch binding is requested. > > Template Version: @(#)sac_nextcase %I% %G% SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Integrate ngrep into Solaris > 1.2. Name of Document Author/Supplier: > Author: Martina Tomisova > 1.3 Date of This Document: > 04 September, 2008 > 4. Technical Description > Proposal: > > Integrate ngrep into Solaris. > > Detail: > > ngrep is a tool for ?grepping? specific information in network > packets. ngrep strives to provide most of GNU grep's common > features, applying them to the network layer. ngrep is a > pcap-aware tool that will allow you to specify extended regular > or hexadecimal expressions to match against data payloads of > packets. It currently recognizes IPv4, TCP, UDP, ICMPv4, IGMP > and Raw across Ethernet, PPP, SLIP, FDDI, Token Ring and null > interfaces, and understands BPF filter logic in the same fashion > as more common packet sniffing tools, such as tcpdump and snoop. > The current version of ngrep is 1.45 at the time of this case. > > > > Exported Interfaces: > > SUNWngrep Uncommitted Package name > /usr/sbin/ngrep Committed Executable location > ngrep Uncommitted Commandline syntax > > Imported Interfaces: > > SUNWlibpcap Libraries (libpcap.so) > > Security: > > RBAC - Anyone who has a role which contains the Network > Management privileges can execute the ngrep as a root. (no SUID > bit for all, just line added to /etc/security/exec_attr as for > other sniffing tools like snoop). > > There was an '-R' option that prevents ngrep from dropping the > root privileges after it starts the capturing. It could be > dangerous (one never knows what will be received from the > network). This option has been removed. > > References: > > [1] http://ngrep.sourceforge.net/ > Author(s) of ngrep: Jordan Ritter > [2] 6721123 - Integrate ngrep into Solaris. > > List of new files: > usr/sbin/ngrep > usr/share/man/man1m/ngrep.1m > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > on > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > Proposes man page: > > User Manuals NGREP(1M) > > > > NAME > ngrep - network grep > > > SYNOPSIS > ngrep <-hNXViwqpevxlDtTRM> <-IO pcap_dump > < -n num > < -d > dev > < -A num > < -s snaplen > < -S limitlen > < -W > normal|byline|single|none > < -c cols > < -P char > < -F > file > < match expression > < bpf filter > > > > DESCRIPTION > ngrep strives to provide most of GNU grep's common features, > applying them to the network layer. ngrep is a pcap-aware > tool that will allow you to specify extended regular expres- > sions to match against data payloads of packets. It > currently recognizes TCP, UDP and ICMP across Ethernet, PPP, > SLIP, FDDI and null interfaces, and understands bpf filter > logic in the same fashion as more common packet sniffing > tools, such as tcpdump(1M) and snoop(1). > > Ngrep makes no effort to validate input from live or offline > sources as it is focused more on performance and handling > large amounts of data than protocol correctness, which is > most often a fair assumption to make. However, sometimes it > matters and thus as a rule ngrep will try to be defensive > and drop any root privileges it might have after started > catching of packets. > > > > OPTIONS > -h Display help/usage information. > > > -N Show sub-protocol number along with single-character > identifier (useful when observing raw or unknown proto- > cols). > > > -X Treat the match expression as a hexadecimal string. > See the explanation of match expression below. > > > -V Display version information. > > > -i Ignore case for the regex expression. > > > -w Match the regex expression as a word. > > > > > *nux Last change: November 2006 1 > > > > > > > User Manuals NGREP(1M) > > > > -q Be quiet; don't output any information other than > packet headers and their payloads (if relevant). > > > -p Don't put the interface into promiscuous mode. > > > -e Show empty packets. Normally empty packets are dis- > carded because they have no payload to search. If > specified, empty packets will be shown, regardless of > the specified regex expression. > > > -v Invert the match; only display packets that don't > match. > > > -x Dump packet contents as hexadecimal as well as ASCII. > > > -l Make stdout line buffered. > > > -D When reading pcap_dump files, replay them at their > recorded time intervals (mimic realtime). > > > -t Print a timestamp in the form of YYYY/MM/DD > HH:MM:SS.UUUUUU everytime a packet is matched. > > > -T Print a timestamp in the form of +S.UUUUUU, indicating > the delta between packet matches. > > > > > > > -c cols > Explicitly set the console width to ``cols''. Note > that this is the console width, and not the full width > of what ngrep prints out as payloads; depending on the > output mode ngrep may print less than ``cols'' bytes > per line (indentation). > > > -F file > Read in the bpf filter from the specified filename. > This is a compatibility option for users familiar with > tcpdump. Please note that specifying ``-F'' will over- > ride any bpf filter specified on the command-line. > > > > *nux Last change: November 2006 2 > > > > > > > User Manuals NGREP(1M) > > > > -P char > Specify an alternate character to signify non-printable > characters when displayed. The default is ``.''. > > > -W normal|byline|single|none > Specify an alternate manner for displaying packets, > when not in hexadecimal mode. The ``byline'' mode > honors embedded linefeeds, wrapping text only when a > linefeed is encountered. The ``none'' mode doesn't > wrap under any circumstance (entire payload is > displayed on one line). The ``single'' mode is concep- > tually the same as ``none'', except that everything > including IP and source/destination header information > is all on one line. ``normal'' is the default mode and > is only included for completeness. This option is > incompatible with ``-x''. > > > -s snaplen > Set the bpf caplen to snaplen (default 65536). > > > -S limitlen > Set the upper limit on the size of packets that ngrep > will look at. Useful for looking at only the first N > bytes of packets without changing the BPF snaplen. > > > -I pcap_dump > Input file pcap_dump into ngrep. Works with any pcap- > compatible dump file format. This option is useful for > searching for a wide range of different patterns over > the same packet stream. > > > -O pcap_dump > Output matched packets to a pcap-compatible dump file. > This feature does not interfere with normal output to > stdout. > > > -n num > Match only num packets total, then exit. > > > -d dev > By default ngrep will select a default interface to > listen on. Use this option to force ngrep to listen on > interface dev. > > > > > > *nux Last change: November 2006 3 > > > > > > > User Manuals NGREP(1M) > > > > -A num > Dump num packets of trailing context after matching a > packet. > > > -W normal|byline|none > Alter the method by which ngrep displays packet pay- > load. ``normal'' mode represents the standard > behaviour, ``byline'' instructs ngrep to respect embed- > ded linefeeds (useful for observing HTTP transactions, > for instance), and ``none'' results in the payload on > one single line (useful for scripted processing of > ngrep output). > > > -c cols > Ignore the detected terminal width and force the column > width to the specified size. > > > -P char > Change the non-printable character from the default > ``.'' to the character specified. > > > match expression > A match expression is either an extended regular > expression, or if the -X option is specified, a string > signifying a hexadecimal value. An extended regular > expression follows the rules as implemented by the GNU > regex library. Hexadecimal expressions can optionally > be preceded by `0x'. E.g., `DEADBEEF', `0xDEADBEEF'. > > > bpf filter > Selects a filter that specifies what packets will be > dumped. If no bpf filter is given, all IP packets seen > on the selected interface will be dumped. Otherwise, > only packets for which bpf filter is `true' will be > dumped. > > The bpf filter consists of one or more primitives. Primi- > tives usually consist of an id (name or number) preceded by > one or more qualifiers. There are three different kinds of > qualifier: > > type qualifiers say what kind of thing the id name or number > refers to. Possible types are host, net and port. > E.g., `host blort', `net 1.2.3', `port 80'. If there > is no type qualifier, host is assumed. > > dir qualifiers specify a particular transfer direction to > > > > *nux Last change: November 2006 4 > > > > > > > User Manuals NGREP(1M) > > > > and/or from id. Possible directions are src, dst, src > or dst and src and dst. E.g., `src foo', `dst net > 1.2.3', `src or dst port ftp-data'. If there is no dir > qualifier, src or dst is assumed. For `null' link > layers (i.e. point to point protocols such as slip) the > inbound and outbound qualifiers can be used to specify > a desired direction. > > proto > qualifiers are restricted to ip-only protocols. Possi- > ble protos are: tcp , udp and icmp. e.g., `udp src > foo' or `tcp port 21'. If there is no proto qualifier, > all protocols consistent with the type are assumed. > E.g., `src foo' means `ip and ((tcp or udp) src foo)', > `net bar' means `ip and (net bar)', and `port 53' means > `ip and ((tcp or udp) port 53)'. > > In addition to the above, there are some special `primitive' > keywords that don't follow the pattern: gateway, broadcast, > less, greater and arithmetic expressions. All of these are > described below. > > More complex filter expressions are built up by using the > words and, or and not to combine primitives. E.g., `host > blort and not port ftp and not port ftp-data'. To save typ- > ing, identical qualifier lists can be omitted. E.g., `tcp > dst port ftp or ftp-data or domain' is exactly the same as > `tcp dst port ftp or tcp dst port ftp-data or tcp dst port > domain'. > dst net net > True if the IP destination address of the packet has a > network number of net. Net may be either a name from > /etc/networks or a network number (see networks(4) for > details). > > > src net net > True if the IP source address of the packet has a net- > work number of net. > > > net net > True if either the IP source or destination address of > the packet has a network number of net. > > > net net mask mask > True if the IP address matches net with the specific > netmask. May be qualified with src or dst. > > > net net/len > True if the IP address matches net a netmask len bits > wide. May be qualified with src or dst. > > > dst port port > > > > *nux Last change: November 2006 6 > > > > > > > User Manuals NGREP(1M) > > > > True if the packet is ip/tcp or ip/udp and has a desti- > nation port value of port. The port can be a number or > a name used in /etc/services (see tcp(4P) and udp(4P)). > If a name is used, both the port number and protocol > are checked. If a number or ambiguous name is used, > only the port number is checked (e.g., dst port 513 > will print both tcp/login traffic and udp/who traffic, > and port domain will print both tcp/domain and > udp/domain traffic). > > > src port port > True if the packet has a source port value of port. > > > port port > True if either the source or destination port of the > packet is port. Any of the above port expressions can > be prepended with the keywords, tcp or udp, as in: > > Allowable primitives are: > > > dst host host > True if the IP destination field of the packet is host, > which may be either an address or a name. > > > src host host > True if the IP source field of the packet is host. > > > host host > True if either the IP source or destination of the > packet is host. Any of the above host expressions can > be prepended with the keywords, ip, arp, or rarp as in: > ip host host > which is equivalent to: > > > > ether dst ehost > > > > *nux Last change: November 2006 5 > > > > > > > User Manuals NGREP(1M) > > > > True if the ethernet destination address is ehost. > Ehost may be either a name from /etc/ethers or a number > (see ethers(3N) for numeric format). > > ether src ehost > True if the ethernet source address is ehost. > > ether host ehost > True if either the ethernet source or destination > address is ehost. > > > gateway host > True if the packet used host as a gateway. I.e., the > ethernet source or destination address was host but > neither the IP source nor the IP destination was host. > Host must be a name and must be found in both > /etc/hosts and /etc/ethers. (An equivalent expression > is > ether host ehost and not host host > which can be used with either names or numbers for host > / ehost.) > > > tcp src port port > which matches only tcp packets whose source port is > port. > > > less length > True if the packet has a length less than or equal to > length. This is equivalent to: > len <= length. > > > greater length > True if the packet has a length greater than or equal > to length. This is equivalent to: > len >= length. > > > ip proto protocol > True if the packet is an ip packet (see ip(4P)) of pro- > tocol type protocol. Protocol can be a number or one > of the names tcp, udp or icmp. Note that the identif- > iers tcp and udp are also keywords and must be escaped > via backslash (\), which is \\ in the C-shell. > > > ip broadcast > True if the packet is an IP broadcast packet. It > checks for both the all-zeroes and all-ones broadcast > conventions, and looks up the local subnet mask. > > > ip multicast > True if the packet is an IP multicast packet. > > > > *nux Last change: November 2006 7 > > > > > > > User Manuals NGREP(1M) > > > > ip Abbreviation for: > ether proto ip > > tcp, udp, icmp > Abbreviations for: > ip proto p > where p is one of the above protocols. > > expr relop expr > True if the relation holds, where relop is one of >, <, > >=, <=, =, !=, and expr is an arithmetic expression > composed of integer constants (expressed in standard C > syntax), the normal binary operators [+, -, *, /, &, > |], a length operator, and special packet data acces- > sors. To access data inside the packet, use the fol- > lowing syntax: > proto [ expr : size ] > Proto is one of ip, tcp, udp or icmp, and indicates the > protocol layer for the index operation. The byte > offset, relative to the indicated protocol layer, is > given by expr. Size is optional and indicates the > number of bytes in the field of interest; it can be > either one, two, or four, and defaults to one. The > length operator, indicated by the keyword len, gives > the length of the packet. > > For example, `ether[0] & 1 != 0' catches all multicast > traffic. The expression `ip[0] & 0xf != 5' catches all > IP packets with options. The expression `ip[6:2] & > 0x1fff = 0' catches only unfragmented datagrams and > frag zero of fragmented datagrams. This check is > implicitly applied to the tcp and udp index operations. > For instance, tcp[0] always means the first byte of the > TCP header, and never means the first byte of an inter- > vening fragment. > > Primitives may be combined using: > > A parenthesized group of primitives and operators > (parentheses are special to the Shell and must be > escaped). > > Negation (`!' or `not'). > > Concatenation (`&&' or `and'). > > Alternation (`||' or `or'). > > Negation has highest precedence. Alternation and concatena- > tion have equal precedence and associate left to right. > Note that explicit and tokens, not juxtaposition, are now > required for concatenation. > > > > *nux Last change: November 2006 8 > > > > > > > User Manuals NGREP(1M) > > > > If an identifier is given without a keyword, the most recent > keyword is assumed. For example, > not host vs and ace > is short for > not host vs and host ace > which should not be confused with > not ( host vs or ace ) > > Expression arguments can be passed to ngrep as either a sin- > > If an identifier is given without a keyword, the most recent > keyword is assumed. For example, > not host vs and ace > is short for > not host vs and host ace > which should not be confused with > not ( host vs or ace ) > > Expression arguments can be passed to ngrep as either a sin- > gle argument or as multiple arguments, whichever is more > convenient. Generally, if the expression contains Shell > metacharacters, it is easier to pass it as a single, quoted > argument. Multiple arguments are concatenated with spaces > before being parsed. > > > DIAGNOSTICS > Errors from ngrep, libpcap, and the GNU regex library are > all output to stderr. > > > AUTHOR > Written by Jordan Ritter . > > > REPORTING BUGS > Please report bugs to the ngrep's Sourceforge Bug Tracker, > located at > > http://sourceforge.net/projects/ngrep/ > > Non-bug, non-feature-request general feedback should be sent > to the author directly by email. > > > NOTES > ALL YOUR BASE ARE BELONG TO US. > > ATTRIBUTES > See attributes(5) for descriptions of the following attri- > butes: > > box; cbp-1 | cbp-1 l | l . ATTRIBUTE TYPE ATTRIBUTE VALUE = > Availability SUNWngrep = Interface Stability Uncommitted > > NOTES > Source for ngrep is available on http://opensolaris.org. > > > > > > > > > *nux Last change: November 2006 9 -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From brian.utterback@sun.com Wed Sep 10 10:24:33 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AHOWql029107 for ; Wed, 10 Sep 2008 10:24:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AHOW0R012318 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 11:24:32 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00703POWIT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 10:24:32 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z000SDPOV5B80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 10:24:31 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AHORx2048482; Wed, 10 Sep 2008 13:24:27 -0400 (EDT) Date: Wed, 10 Sep 2008 13:24:26 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C7FF3F.6060209@Sun.COM> To: Norm Jacobs Cc: Darren J Moffat , James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C802CA.4060407@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> <48C7FF3F.6060209@Sun.COM> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 500 Norm Jacobs wrote: > orphaning that may occur. There are several components in SFW that > already deliver root packages with RBAC entries. But only one (SUNWmkcdr) delivers nothing else. What do you see as the problem here? -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Norm.Jacobs@sun.com Wed Sep 10 10:55:00 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AHt0sB000511 for ; Wed, 10 Sep 2008 10:55:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AHsx8V022394 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 10 Sep 2008 11:54:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00A0NR3MIF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 10 Sep 2008 10:54:58 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z0002OR3L5L90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 10 Sep 2008 10:54:57 -0700 (PDT) Received: from printing.eng.sun.com (printing.SFBay.Sun.COM [129.146.178.26]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AHssCl064477; Wed, 10 Sep 2008 10:54:54 -0700 (PDT) Received: from [10.7.251.237] (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.eng.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8AHud1T014607; Wed, 10 Sep 2008 10:56:40 -0700 (PDT) Date: Wed, 10 Sep 2008 12:54:53 -0500 From: Norm Jacobs Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C802CA.4060407@sun.com> To: Brian Utterback Cc: Darren J Moffat , James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C809ED.2020805@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> <48C7FF3F.6060209@Sun.COM> <48C802CA.4060407@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 1164 Brian Utterback wrote: > > > Norm Jacobs wrote: > >> orphaning that may occur. There are several components in SFW that >> already deliver root packages with RBAC entries. > > But only one (SUNWmkcdr) delivers nothing else. What do you see as the > problem here? > In this particular case, I doubt that you are going to cause any real harm if the SFW and ON bits are ever out of sync, but by splitting the delivery, you are all but guaranteeing that it will happen at some time. The RBAC bits for this in ON are almost certainly going to be forgotten. If they are in SFW in packaging related to the component, they more likely to be attended to. Aside from that, by packaging them in a root package in SFW, you can add/remove the RBAC data with the functionality. If you simply put it in ON and leave it up to SUNWcsr to install, you leave potentially orphaned entries in the RBAC data that may or may not become a problem down the road. Finally, it seems to me that if/when IPS provides a better answer for delivering file fragments, we will want those fragments in with the functionality that they are supporting. Just my $0.02 -Norm From gdamore@sun.com Wed Sep 10 11:14:04 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AIE3cx001371 for ; Wed, 10 Sep 2008 11:14:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8AIDoE4023203 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 11 Sep 2008 02:14:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z0070NRZCC900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 11:14:00 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z000OBRZAHRE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 11:13:58 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8AIDwmS008806 for ; Wed, 10 Sep 2008 11:13:58 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Z00E01QR8RG00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 11:13:58 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Z00I8ARZ79FD0@fe-sfbay-10.sun.com>; Wed, 10 Sep 2008 11:13:55 -0700 (PDT) Date: Wed, 10 Sep 2008 11:12:45 -0700 From: "Garrett D'Amore" Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C809ED.2020805@Sun.COM> Sender: Garrett.Damore@sun.com To: Norm Jacobs Cc: Brian Utterback , Darren J Moffat , James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C80E1D.4020204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C121F8.9060702@Sun.COM> <20080905153339.GS1524@Sun.COM> <48C4D45F.9060308@Sun.COM> <48C4EB33.7070301@Sun.COM> <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> <48C7FF3F.6060209@Sun.COM> <48C802CA.4060407@sun.com> <48C809ED.2020805@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1672 Norm Jacobs wrote: > Brian Utterback wrote: >> >> >> Norm Jacobs wrote: >> >>> orphaning that may occur. There are several components in SFW that >>> already deliver root packages with RBAC entries. >> >> But only one (SUNWmkcdr) delivers nothing else. What do you see as >> the problem here? >> > In this particular case, I doubt that you are going to cause any real > harm if the SFW and ON bits are ever out of sync, but by splitting the > delivery, you are all but guaranteeing that it will happen at some > time. The RBAC bits for this in ON are almost certainly going to be > forgotten. If they are in SFW in packaging related to the component, > they more likely to be attended to. Aside from that, by packaging > them in a root package in SFW, you can add/remove the RBAC data with > the functionality. If you simply put it in ON and leave it up to > SUNWcsr to install, you leave potentially orphaned entries in the > RBAC data that may or may not become a problem down the road. > Finally, it seems to me that if/when IPS provides a better answer for > delivering file fragments, we will want those fragments in with the > functionality that they are supporting. Just my $0.02 > > -Norm > > I think I have a very mild preference for the separate root package, for the reasons listed above. It does seem to me that Darren's concerns here about a mostly trivial root package are mostly aesthetic (an extra root package). But, I also believe that either way is OK, and that the argument is not architectural in nature. We do need IPS to address this somehow, going forward -- but that's not a problem for this case. -- Garrett From Nicolas.Williams@sun.com Wed Sep 10 11:36:13 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AIaCnl001723 for ; Wed, 10 Sep 2008 11:36:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8AIa1EQ000881; Thu, 11 Sep 2008 02:36:04 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00D01T039G00@brm-avmta-1.central.sun.com>; Wed, 10 Sep 2008 12:36:03 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.107]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z009E8T02XQ40@brm-avmta-1.central.sun.com>; Wed, 10 Sep 2008 12:36:03 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8AIZutX003287; Wed, 10 Sep 2008 13:35:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8AIZuss003286; Wed, 10 Sep 2008 13:35:56 -0500 (CDT) Date: Wed, 10 Sep 2008 13:35:56 -0500 From: Nicolas Williams Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C809ED.2020805@Sun.COM> To: Norm Jacobs Cc: Brian Utterback , Darren J Moffat , James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <20080910183556.GJ1875@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> <48C7FF3F.6060209@Sun.COM> <48C802CA.4060407@sun.com> <48C809ED.2020805@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 280 [Good points about splitting pkgs vs. spanning consolidations elided.] Perhaps the best answer is: do as always until IPS is delivered and SVR4 packaging dead. "As always" here would probably be the c-team's preference. The root pkg name should probably be Volatile. Nico -- From brian.utterback@sun.com Wed Sep 10 11:59:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AIxHtY002273 for ; Wed, 10 Sep 2008 11:59:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AIxFkb012217 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 11:59:17 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00F07U2S4D00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 12:59:16 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z009V8U2RXI60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 12:59:15 -0600 (MDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AIxAiu016591; Wed, 10 Sep 2008 14:59:10 -0400 (EDT) Date: Wed, 10 Sep 2008 14:59:10 -0400 From: Brian Utterback Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <20080910183556.GJ1875@Sun.COM> To: Nicolas Williams Cc: Norm Jacobs , Darren J Moffat , James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C818FE.3000009@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> <48C7FF3F.6060209@Sun.COM> <48C802CA.4060407@sun.com> <48C809ED.2020805@Sun.COM> <20080910183556.GJ1875@Sun.COM> User-Agent: Thunderbird 2.0.0.17pre (X11/20080901) Status: RO Content-Length: 797 The case was approved with only a single package and separate integration into ON. Does anybody care enough to want to re-open the case, or are we really just talking about getting IPS guidance for the future? Nicolas Williams wrote: > [Good points about splitting pkgs vs. spanning consolidations elided.] > > Perhaps the best answer is: do as always until IPS is delivered and SVR4 > packaging dead. "As always" here would probably be the c-team's > preference. The root pkg name should probably be Volatile. > > Nico -- blu There are two rules in life: Rule 1- Don't tell people everything you know ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From Norm.Jacobs@sun.com Wed Sep 10 12:50:10 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AJo9d8003818 for ; Wed, 10 Sep 2008 12:50:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AJo9UW025608 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 10 Sep 2008 12:50:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00I0BWFLRG00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 10 Sep 2008 13:50:09 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z0096TWFKXSA0@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 10 Sep 2008 13:50:08 -0600 (MDT) Received: from printing.eng.sun.com (printing.SFBay.Sun.COM [129.146.178.26]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m8AJo4IZ018651; Wed, 10 Sep 2008 12:50:04 -0700 (PDT) Received: from [10.7.251.237] (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.eng.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8AJpoig014820; Wed, 10 Sep 2008 12:51:50 -0700 (PDT) Date: Wed, 10 Sep 2008 14:50:03 -0500 From: Norm Jacobs Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C818FE.3000009@sun.com> To: Brian Utterback Cc: Nicolas Williams , Darren J Moffat , James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C824EB.5010101@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> <48C7FF3F.6060209@Sun.COM> <48C802CA.4060407@sun.com> <48C809ED.2020805@Sun.COM> <20080910183556.GJ1875@Sun.COM> <48C818FE.3000009@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 648 I care enough to want to see the root package added to this case. -Norm Brian Utterback wrote: > The case was approved with only a single package and separate > integration into ON. Does anybody care enough to want to re-open the > case, or are we really just talking about getting IPS guidance for the > future? > > Nicolas Williams wrote: >> [Good points about splitting pkgs vs. spanning consolidations elided.] >> >> Perhaps the best answer is: do as always until IPS is delivered and SVR4 >> packaging dead. "As always" here would probably be the c-team's >> preference. The root pkg name should probably be Volatile. >> >> Nico > From gdamore@sun.com Wed Sep 10 13:00:28 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AK0R2K004585 for ; Wed, 10 Sep 2008 13:00:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8AK0KRK029482 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 11 Sep 2008 04:00:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00B0LWWOOO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 13:00:24 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z007C5WWNJ170@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 13:00:23 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8AK0NtK025398 for ; Wed, 10 Sep 2008 13:00:23 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Z00001VTR1200@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 13:00:23 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Z00HEPWWKZ1C0@fe-sfbay-10.sun.com>; Wed, 10 Sep 2008 13:00:20 -0700 (PDT) Date: Wed, 10 Sep 2008 12:59:10 -0700 From: "Garrett D'Amore" Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C818FE.3000009@sun.com> Sender: Garrett.Damore@sun.com To: Brian Utterback Cc: Nicolas Williams , Norm Jacobs , Darren J Moffat , James Carlson , PSARC-ext@sun.com, Martina Tomisova , Brian Utterback Message-id: <48C8270E.5080903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> <48C7FF3F.6060209@Sun.COM> <48C802CA.4060407@sun.com> <48C809ED.2020805@Sun.COM> <20080910183556.GJ1875@Sun.COM> <48C818FE.3000009@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 815 Brian Utterback wrote: > The case was approved with only a single package and separate > integration into ON. Does anybody care enough to want to re-open the > case, or are we really just talking about getting IPS guidance for the > future? I doubt anyone cares enough to reopen the case. The details of this issue (particularly whether the rbac is delivered as a separate root package or as part of a stock ON package) IMO fall below the threshold of ARC review. -- Garrett > > Nicolas Williams wrote: >> [Good points about splitting pkgs vs. spanning consolidations elided.] >> >> Perhaps the best answer is: do as always until IPS is delivered and SVR4 >> packaging dead. "As always" here would probably be the c-team's >> preference. The root pkg name should probably be Volatile. >> >> Nico > From John.Plocher@sun.com Wed Sep 10 13:32:25 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8AKWPnV006671 for ; Wed, 10 Sep 2008 13:32:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AKWOuY008226 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Sep 2008 13:32:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Z00303YE1TA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 13:32:25 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z00MC9YE0EP20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 13:32:24 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8AKWOTY029766 for ; Wed, 10 Sep 2008 13:32:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Z00C01VXB2A00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Sep 2008 13:32:24 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Z00975YDXW9C0@fe-sfbay-09.sun.com>; Wed, 10 Sep 2008 13:32:21 -0700 (PDT) Date: Wed, 10 Sep 2008 13:32:21 -0700 From: John Plocher Subject: Re: Integrate ngrep into Solaris [PSARC/2008/562 FastTrack timeout 09/11/2008] In-reply-to: <48C8270E.5080903@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: Brian Utterback , Norm Jacobs , Martina Tomisova , James Carlson , psarc-ext@sun.com, Brian Utterback Message-id: <48C82ED5.7090001@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C7C3BB.6030906@sun.com> <48C7C5F8.1050009@Sun.COM> <18631.54180.811183.540092@gargle.gargle.HOWL> <48C7D69A.5070204@Sun.COM> <18631.55882.626225.379121@gargle.gargle.HOWL> <48C7DCDA.8080602@sun.com> <48C7DD8F.2070609@Sun.COM> <48C7FF3F.6060209@Sun.COM> <48C802CA.4060407@sun.com> <48C809ED.2020805@Sun.COM> <20080910183556.GJ1875@Sun.COM> <48C818FE.3000009@sun.com> <48C8270E.5080903@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 479 Garrett D'Amore wrote: > I doubt anyone cares enough to reopen the case. The details of this > issue (particularly whether the rbac is delivered as a separate root > package or as part of a stock ON package) IMO fall below the threshold > of ARC review. Specifically, it is up to Brian and his C-Team to decide what path to follow here; the ARC was OK with all the alternatives that were presented and was willing to let the project team make the final decision. -John