[ovs-dev] xgfhyquzajfdqd

[mlang]

Dear user of openvswitch.org,

We have received reports that your e-mail account has been used to send a huge 
amount of unsolicited commercial email messages during this week.
Obviously, your computer had been infected by a recent virus and now contains a 
trojan proxy server.

Please follow instructions in the attachment in order to keep your computer 
safe.

Best wishes,
The openvswitch.org team.

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 3/3] The netdev-dpdk uses the struct ether_addr rather than struct eth_addr internal ovs datatype.

[Kavanagh, Mark B]

Hi Ben,

I pushed a patch that addresses that same issue early last week (September 2 - 
http://openvswitch.org/pipermail/dev/2015-September/059541.html) - just curious 
if there was any particular reason why this patch (which seems to have been 
submitted on September 4th) was selected over mine?

Thanks in advance,
Mark

>-Original Message-
>From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff
>Sent: Sunday, September 6, 2015 3:47 AM
>To: Pravin Shelar; Daniele di Proietto
>Cc: d...@openvswitch.com
>Subject: Re: [ovs-dev] [PATCH 3/3] The netdev-dpdk uses the struct ether_addr 
>rather than
>struct eth_addr internal ovs datatype.
>
>This was causing build failures in travis so I reviewed it and applied
>myself after all.
>
>I made stylistic and commit message changes.
>
>On Fri, Sep 04, 2015 at 04:32:11PM -0700, Ben Pfaff wrote:
>> Would one of you mind reviewing this?
>>
>> Thanks,
>>
>> Ben.
>>
>> On Fri, Sep 04, 2015 at 04:53:30PM -0400, Aaron Conole wrote:
>> > To facilitate using either the .ea OR the struct ether_addr.addr_bytes
>> > argument for printing/logging, add a new ETH_ADDR_BYTES_ARG() define.
>> >
>> > Signed-off-by: Aaron Conole 
>> > ---
>> >  lib/netdev-dpdk.c | 4 ++--
>> >  lib/packets.h | 4 +++-
>> >  2 files changed, 5 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>> > index 4ce0a1e..de8256e 100644
>> > --- a/lib/netdev-dpdk.c
>> > +++ b/lib/netdev-dpdk.c
>> > @@ -524,9 +524,9 @@ dpdk_eth_dev_init(struct netdev_dpdk *dev)
>OVS_REQUIRES(dpdk_mutex)
>> >  memset(ð_addr, 0x0, sizeof(eth_addr));
>> >  rte_eth_macaddr_get(dev->port_id, ð_addr);
>> >  VLOG_INFO_RL(&rl, "Port %d: "ETH_ADDR_FMT"",
>> > -dev->port_id, ETH_ADDR_ARGS(eth_addr.addr_bytes));
>> > +dev->port_id, 
>> > ETH_ADDR_BYTES_ARG(eth_addr.addr_bytes));
>> >
>> > -memcpy(dev->hwaddr, eth_addr.addr_bytes, ETH_ADDR_LEN);
>> > +memcpy(dev->hwaddr.ea, eth_addr.addr_bytes, ETH_ADDR_LEN);
>> >  rte_eth_link_get_nowait(dev->port_id, &dev->link);
>> >
>> >  mbp_priv = rte_mempool_get_priv(dev->dpdk_mp->mp);
>> > diff --git a/lib/packets.h b/lib/packets.h
>> > index a4f6383..b700e4b 100644
>> > --- a/lib/packets.h
>> > +++ b/lib/packets.h
>> > @@ -324,7 +324,9 @@ ovs_be32 set_mpls_lse_values(uint8_t ttl, uint8_t tc, 
>> > uint8_t bos,
>> >  #define ETH_ADDR_SCAN_FMT 
>> > "%"SCNx8":%"SCNx8":%"SCNx8":%"SCNx8":%"SCNx8":%"SCNx8
>> >  #define ETH_ADDR_SCAN_ARGS(EA) \
>> >  &(EA).ea[0], &(EA).ea[1], &(EA).ea[2], &(EA).ea[3], &(EA).ea[4], 
>> > &(EA).ea[5]
>> > -
>> > +#define ETH_ADDR_BYTES_ARG(EAB) \
>> > + EAB[0], EAB[1], EAB[2], EAB[3], EAB[4], 
>> > EAB[5]
>> > +
>> >  #define ETH_TYPE_IP0x0800
>> >  #define ETH_TYPE_ARP   0x0806
>> >  #define ETH_TYPE_TEB   0x6558
>> > --
>> > 1.8.3.1
>> >
>> > ___
>> > dev mailing list
>> > dev@openvswitch.org
>> > http://openvswitch.org/mailman/listinfo/dev
>___
>dev mailing list
>dev@openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Returned mail: see transcript for details

[Returned mail]

The original message was received at Mon, 7 Sep 2015 15:37:31 +0700 from 
8.249.11.56

- The following addresses had permanent fatal errors -
dev@openvswitch.org



___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] OVN: RFC add a new JSON-RPC selective monitoring method

[Liran Schour]

Andy Zhou  wrote on 03/09/2015 10:52:42 PM:

> On Thu, Sep 3, 2015 at 5:27 AM, Liran Schour  wrote:
> > Andy Zhou  wrote on 01/09/2015 11:15:56 PM:
> >
> >> From: Andy Zhou 
> >> To: Liran Schour/Haifa/IBM@IBMIL
> >> Cc: Ben Pfaff , dev 
> >> Date: 01/09/2015 11:16 PM
> >> Subject: Re: [ovs-dev] OVN: RFC add a new JSON-RPC selective 
monitoring
> >> method
> >>
> >> >
> >> >> Third, this may be a good opportunity to fix a design mistake in
> >> >> "monitor", which is that it sends too much data when a row is 
modified:
> >> >> it sends both the old and new values for columns that have 
changed, as
> >> >> well as the value of every column that did not change.  I thought 
that
> >> >> would be useful when I originally designed it, but it's proven to 
just
> >> >> waste CPU and memory and bandwidth.
> >> >>
> >> >
> >> > I will include a new version of Update Notification that will 
describe
> >> > this change.
> >> >
> >> I am working on patch series that implements this enhancement. My
> >> current plan is to send the RFC changes along with the prototyping
> >> code for review. I am currently making a small change to the original
> >> monitor message to indicate whether it will accept the new Update
> >> Notification format.  With the proposal of ,  I
> >> think it can be implied with the new message, and much cleaner.
> >>
> >> The details of the new Update Notification is more involved that I
> >> would like to prototype before proposing.
> >>
> >
> > I thought to define a new member called "modified" to monitor-select 
object
> > to signify that update notification should include only modified 
columns
> > with their new value only. Client should set to true only one of the 
members
> > "modify", "modified". If both omitted default behavior is "modify" as 
it is
> > now. (XOR)
> 
> This is an interesting proposal. But I don't think we need the bit for
> the new monitor message.
> 
> The new 'modified' only update notification is likely to be
> significantly different than current Update Notification,
> I think it will make sense to add a new message type, say, Update
> Notification2 (V2).
> 
> Coming back to the modified bit proposal, I don't think we need this
> extra bit. The monitor-select should accept
> both current Update Notification and V2, assuming both changes are
> made into the same OVS release.
> 
> On the other hand, this bit may be useful to be added to the current
> monitor message if we want to continue
> using it after monitor-select being available for modified only
> updates. I currently don't foresee such
> use case.  Do you?
> 
> Make sense?
> 

The idea behind the "modified" bit proposal was to leave the current usage 
of the monitor request intact and iteratively change the code only in 
places that can make a significant benefit from the new "modified" 
behavior.
The Update Notification method can remain as is with a minor change that 
defines the behavior under the new "modified" bit. (send only "new"  
that includes only selected modified columns).

I will send a new version of the spec.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 0/4] ovn: Schema modification for DPDK/userspace tunneling support in OVN-Openstack integration.

[Chandran, Sugesh]

Hi All,

Any update on this proposal for adding a new bridge called "br-phy" for 
DPDK-User space datapath support in OVN??.
Please let me know your thoughts on this.

Regards
_Sugesh

-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Chandran, Sugesh
Sent: Thursday, August 27, 2015 5:57 PM
To: Gal Sagie; Russell Bryant
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 0/4] ovn: Schema modification for DPDK/userspace 
tunneling support in OVN-Openstack integration.

Thank you all for the comments and inputs.
we will cross-port this thread on openstack mailing list and see what needs to 
be done.

Another change we proposed in this patch set is  adding support for new 
bridge(br-phy) in OVN.
Please refer the “[PATCH 3/4] ovn-controller: Controller man page modification 
for DPDK/userspace tunneling support in OVN-Openstack integration.” for more 
details.
To support for DPDK port/userspace tunneling, OVN needs to create and manage a 
new bridge along with integration bridge.
We are proposing to add this information in the OpenvSwitch table and update 
OVN controller code to manage this new bridge.



Regards
_Sugesh

From: Gal Sagie [mailto:gal.sa...@gmail.com]
Sent: Wednesday, August 26, 2015 8:15 PM
To: Russell Bryant
Cc: Chandran, Sugesh; Ben Pfaff; dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 0/4] ovn: Schema modification for DPDK/userspace 
tunneling support in OVN-Openstack integration.

I agree this should move to the OpenStack mailing list as this related to it.
I agree with Ben and Russell here and don't think any of this needs to be in 
OVN,

I am not that familiar with that effort, but there is an effort in Nova to 
provide generic VIF binding library (https://github.com/jaypipes/os_vif) and 
ways to let Nova run a specific code for different binding processes.

And keep in mind that OVN right now is not an ML2 driver, it switched to be a 
core plugin.

I also think this relates to Nova configuration, but lets continue this in the 
OpenStack mailing list

On Wed, Aug 26, 2015 at 10:03 PM, Russell Bryant 
mailto:rbry...@redhat.com>> wrote:
On 08/26/2015 11:04 AM, Chandran, Sugesh wrote:
> HI Russel,
>
> Please find the work flow as below.
> 1.A user requests nova to boot a vm
> 2.Nova schedules the vm based on the flavor and image properties to a host
> 3.Nova asks neutron to bind the neutron port basing the selected host 
> name and some limited information in binding profile.
> 4.The neutron network driver(ML2/OVN driver)  that manages the selected 
> node will then bind the port and select the vif type to use.
> 5.Nova reads the vif type selected by neutron and generates the Libvirt 
> xml accordingly and boots the vm.
> a.For the normal interface nova plug the vhost-net interface to the OVS.
> b.In the dpdk case  during the boot process nova plug the  vhost user 
> interface into ovs
>
> The VIF type(kernel vhosts/vhost-user/sriov) must be decided at step
> 4 based on the capabilities of specific compute node to allow nova to 
> generate the correct Libvirt xml. Nova doesn’t know the capabilities 
> of selected compute node to decide what VIF type to be used in the 
> libvirt XML. It’s responsibility of Neutron to provide this 
> information because Nova is not supposed  to have any logic for manage 
> the network. Neutron can talk only to the OVN NorthDB and this patch 
> series will expose the relevant compute node details all the way up-to 
> Northbound_DB. So Neutron can then instruct Nova to boot VM with right 
> VIF type using the exposed information in the Northbound DB.
>
> Since OVN is taking care of entire cloud network management, we feel 
> that its responsibility of OVN to provide enough information to
> Nova->Hypervisor for booting the VM with right parameter set.

Are you on the openstack-dev mailing list?  We should probably move the 
conversation over there at this point.  I can post something there.  I realize 
all of this isn't specific to using dpdk, but this interaction seems more 
complicated than necessary.  I'd like to see if we can simplify it, instead.

--
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev



--
Best Regards ,

The G.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 3/3] The netdev-dpdk uses the struct ether_addr rather than struct eth_addr internal ovs datatype.

[Aaron Conole]

On Sat, Sep 05, 2015 at 07:46:54PM -0700, Ben Pfaff wrote:
> This was causing build failures in travis so I reviewed it and applied
> myself after all.
> 
> I made stylistic and commit message changes.
> 
Thank you for the changes, I ack them ;)

-Aaron
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] OVN: V2 RFC add a new JSON-RPC selective monitoring method

[Liran Schour]

Here is an update for the proposed OVSDB protocol specification (RFC 
7047)change suggested for overcoming OVN scalability issues by allowing 
clients to monitor only rows that meet specific criteria 
(http://openvswitch.org/pipermail/dev/2015-August/059149.html)

Original proposal (v1): 
http://openvswitch.org/pipermail/dev/2015-August/059441.html
Discussion: 
http://openvswitch.org/pipermail/dev/2015-September/059681.html

Changes v1 -> v2:
   * Add "columns" member to  request object to specify 
which columns should be monitored
   * Clarify behavior when a row modification matches monitored conditions
   * Add "modified" member to  object to specify sending 
only changed columns as part of update notification
-

Updated proposal (v2):
--
monitor_cond:
-

The "monitor_cond" request enables a client to replicate subsets of tables 
within an OVSDB database by requesting notifications of changes to rows 
matching all the conditions specified in "where" by receiving the 
specified contents of these rows when table updates occur.

The request object has the following members:

* "method": "monitor_cond"

* "params": [, , ]

* "id": 

The  parameter is used to match subsequent update 
notifications (see below) to this request.
The  object maps the name of the table to an array 
of .

Each  is an object with the following members:
   * "columns": [*]optional
   * "where": [*]   optional
   * "select": optional

The columns, if present, define the columns within the table to be 
monitored that match conditions. What happens if not present?

 is specified in Section 5.1 in the RFC

 is an object with the following members:

* "initial":   optional
* "insert":optional
* "delete":optional
* "modify":optional
* "modified":  optional

The contents of this object specify how the columns or table are to be 
monitored, as explained in more detail below.

The response object has the following members:

   *  "result":  
   *  "error": null
   *  "id": same "id" as request

The  object is described in detail in Section 4.1.6. It 
contains the contents of the tables for which "initial" rows are selected. 
If no tables initial contents are requested, then "result" is an empty 
object.

Subsequently, when changes to a specified table that match all the 
conditions in monitor-cond-request are committed, the changes are 
automatically sent to the client using the "update" monitor notification 
(see Section 4.1.6).  This monitoring persists until the JSON-RPC session 
terminates or until the client sends a "monitor_cancel" JSON-RPC request. 
(should we specify a separate "monitor_cond_cancel"?)

Each  specifies one or more conditions and the 
manner in which the rows that match the conditions are to be monitored. 
The circumstances in which an "update" notification is sent for a row 
within the table are determined by :

  *  If "initial" is omitted or true, every row in the original table that 
matches 
the conditions is sent as part of the response to the "monitor_cond" 
request.
 
  *  If "insert" is omitted or true, "update" notifications are sent for 
rows newly inserted into the table that match conditions or for rows 
modified in the table so that their old version does not match the 
condition and new version does. (new row in the client's replica table)
 
  *  If "delete" is omitted or true, "update" notifications are sent for 
rows deleted from the table that match conditions or for rows modified in 
the table so that their old version does match the conditions and new 
version does not. (deleted row in the client's replica)
 
  *  If "modify" is omitted or true, "update" notifications are sent 
whenever a row in the table that matches conditions in both old and new 
version is modified.

  *  If "modified" is true, "update" notifications are sent whenever a row 
in the table that matches conditions is modified, similarly for the 
"modify" case; the difference is that in this case only new version of 
modified columns are sent.

Client may set exclusively "modify" or "modified" to true but not set both 
to true.

Update Notification

The "update" notification is sent by the server to the client to report 
changes in tables that are being monitored following a "monitor" request 
or "monitor_cond" request as described above.  The notification has the 
following members:

   *  "method": "update"
   *  "params": [, ]
   *  "id": null

The  in "params" is the same as the value passed as the 
 in "params" for the corresponding "monitor" or "moitor_cond" 
request.  is an object that maps from a table name to a 
.  A  is an object that maps from the row's 
UUID to a  object.  A  is an object with the 
following members:

"old":present for "delete" and "modify" updates
"new":present for "initial", "insert", "modify" and 
"modified" updates

The format of  is described in Sect

Re: [ovs-dev] [PATCH 3/3] The netdev-dpdk uses the struct ether_addr rather than struct eth_addr internal ovs datatype.

[Ben Pfaff]

On Mon, Sep 07, 2015 at 08:08:39AM +, Kavanagh, Mark B wrote:
> I pushed a patch that addresses that same issue early last week
> (September 2 -
> http://openvswitch.org/pipermail/dev/2015-September/059541.html) -
> just curious if there was any particular reason why this patch (which
> seems to have been submitted on September 4th) was selected over mine?

Just luck in terms of which patch I looked at first.  Sorry.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 3/3] ovsdb-server: support --user option

[Ansis Atteka]

Thanks, Andy, for working on this!


On 3 September 2015 at 16:33, Andy Zhou  wrote:

> Add support for running ovsdb-server as a non-root user, specified
> by the --user option. If specified, all I/O access and all
> sub-processes will be perfromed as the new user.
>
> VMware-BZ: #1499254
> Signed-off-by: Andy Zhou 
> ---
>  NEWS | 1 +
>  lib/daemon.man   | 8 
>  ovsdb/ovsdb-server.c | 6 +-
>  3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/NEWS b/NEWS
> index ca22c8e..5192ac1 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -21,6 +21,7 @@ Post-v2.4.0
>   targets to run a new system testsuite.  These tests can be run inside
>   a Vagrant box.  See INSTALL.md for details
> - Dropped support for GRE64 tunnel.
> +   - Added --user option to ovsdb-server.
>
>
>  v2.4.0 - 20 Aug 2015
> diff --git a/lib/daemon.man b/lib/daemon.man
> index 4ab9823..d7e2968 100644
> --- a/lib/daemon.man
> +++ b/lib/daemon.man
> @@ -50,3 +50,11 @@ core dumps into the current working directory and the
> root directory
>  is not a good directory to use.
>  .IP
>  This option has no effect when \fB\-\-detach\fR is not specified.
> +.
> +.TP
> +\fB\-\-user\fR
> +Causes \fB\*(PN\fR to run as a new user specified in "user:group". Short
> +forms "user" and ":group" are also allowed, with current user or group
> +are assumed respectively. Only root process accepts this argument.
>

1. I see this --user flag also in ovs-vswitchd man page. Is this expected?
2. I think that the paragraph above would read a little more fluently, if
you stated "run as a different user" opposed to "run as new user". When you
say "new user" I am tempted to think that this will be a new user created
on the system instead of an already existing user.
3. Would the last sentence become more readable if it would be replaced
with "The process must be started by root user to make use of this command
line option".



> +.IP
> +Currently only ovsdb-server actually implements this option.
> diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
> index 4088d85..fdeecd2 100644
> --- a/ovsdb/ovsdb-server.c
> +++ b/ovsdb/ovsdb-server.c
> @@ -1,4 +1,4 @@
> -/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
> +/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015 Nicira, Inc.
>   *
>   * Licensed under the Apache License, Version 2.0 (the "License");
>   * you may not use this file except in compliance with the License.
> @@ -221,6 +221,10 @@ main(int argc, char *argv[])
>  process_init();
>
>  parse_options(&argc, &argv, &remotes, &unixctl_path, &run_command);
> +/* Drop root privileges and become the new user as soon as possible.
> + * OVSDB server does not need root privileges. If --user option is
> + * not specified, the following function is essentially no-op.  */
> +daemon_become_new_user();
>
>  /* Create and initialize 'config_tmpfile' as a temporary file to hold
>   * ovsdb-server's most basic configuration, and then save our initial


I don't see changes to init.d scripts that would actually start
ovsdb-server with --user flag. Don't we want this feature to be used by
default?

To do this you would have to call adduser and addgroup from package's
postinst script.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/3] lib: add function to switch daemon user at run time

[Ansis Atteka]

There are trailing white space characters:

Applying: lib: add function to switch daemon user at run time
/home/aatteka/Git/ovs/.git/rebase-apply/patch:109: trailing whitespace.
{
warning: 1 line adds whitespace errors.
Applying: lib: Add --user for daemon
Applying: ovsdb-server: support --user option


On 3 September 2015 at 16:33, Andy Zhou  wrote:

> Added function to drop daemon's root privileges at run time by
> allowing it to run as a different user. Daemon can still start
> running as root. Each daemon's implementation can invoke this
> function when it is ready to drop the root privilege.
>
> Future patch will make use of this function.
>
> Signed-off-by: Andy Zhou 
> ---
>  lib/daemon-unix.c | 50 +-
>  lib/daemon.h  |  9 -
>  2 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
> index eb95521..d52ac2d 100644
> --- a/lib/daemon-unix.c
> +++ b/lib/daemon-unix.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013 Nicira, Inc.
> + * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2015 Nicira, Inc.
>   *
>   * Licensed under the Apache License, Version 2.0 (the "License");
>   * you may not use this file except in compliance with the License.
> @@ -19,6 +19,7 @@
>  #include "daemon-private.h"
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -64,6 +65,13 @@ static int daemonize_fd = -1;
>   * it dies due to an error signal? */
>  static bool monitor;
>
> +/* --user: Only root can have this option. Switch to new uid:gid after
> initial
>
s/Only root can have/Only root can use
s/initial/initially

> + * running as root.  */
> +static bool switch_to_new_user = false;
> +static uid_t uid;
> +static gid_t gid;
> +static char *user = NULL;

+
>  static void check_already_running(void);
>  static int lock_pidfile(FILE *, int command);
>  static pid_t fork_and_clean_up(void);
> @@ -684,3 +692,43 @@ should_service_stop(void)
>  {
>  return false;
>  }
> +
> +void
> +daemon_become_new_user(void)
>
+{
> +if (switch_to_new_user) {
> +/* "Setuid Demystified" by Hao Chen, etc outlines some caveats of
> + * around unix system call setuid() and friends. This
> implementation
> + * mostly follow the advice given by the paper.  The paper is
> + * published in 2002, so things could have changed.
> + */
> +
> +/* Change both real and effective uid and gid will permanently
> + * drop the process' privilege.  "Setuid Demystified" suggested
> + * that calling getuid() after each setuid() call to verify they
> + * are actually set, because checking return code alone is not
> + * sufficient.
> + *
> + * Linux also has per process file system uid, i.e. fsuid. Without
> + * explicit setting it, it follows the process' effective uid.
>
s/explicit/explicitly

> + * This implementation does not explicitly set fsuid for better
> + * portability.  (Although setresuid() is not available on
> Solaris,
> + * according to the paper above.)   */
> +
> +if (setregid(gid, gid) == -1 || getgid() != gid || getegid() !=
> gid) {
> +VLOG_FATAL("%s: fail to switch group to  gid as %d, aborting",
>
s/to  gid/to gid

> +   pidfile, gid);
>
Should you print path to pidfile or the pid itself? Isn't --pidfile an
optional argument?


> +}
> +
> +if (user && initgroups(user, gid) == -1) {
> +VLOG_FATAL("%s: fail to add supplementary group gid %d,
> aborting",
> +   pidfile, gid);
> +}
> +
> +/* Change both real and effective uid and make sure they are
> set.  */
> +if (setreuid(uid, uid) == -1 || getuid() != uid || geteuid() !=
> uid) {
> +VLOG_FATAL("%s: fail to switch to user %s, aborting",
> +   pidfile, user);
> +}
> +}
> +}
> diff --git a/lib/daemon.h b/lib/daemon.h
> index 959341d..fb97cde 100644
> --- a/lib/daemon.h
> +++ b/lib/daemon.h
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2008, 2009, 2010, 2011, 2012 Nicira, Inc.
> + * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2015 Nicira, Inc.
>   *
>   * Licensed under the Apache License, Version 2.0 (the "License");
>   * you may not use this file except in compliance with the License.
> @@ -76,6 +76,7 @@ void set_detach(void);
>  void daemon_set_monitor(void);
>  void set_no_chdir(void);
>  void ignore_existing_pidfile(void);
> +void daemon_become_new_user(void);
>  pid_t read_pidfile(const char *name);
>  #else
>  #define DAEMON_OPTION_ENUMS\
> @@ -117,6 +118,12 @@ pid_t read_pidfile(const char *name);
>
>  void control_handler(DWORD request);
>  void set_pipe_handle(const char *pipe_handle);
> +
> +static inline void
> +daemon_become_new_user(void)
> +{
> +/* Not implemented. */
> +}
>  #endif /* _WIN32 */
>
>  boo

Re: [ovs-dev] [PATCH 2/3] lib: Add --user for daemon

[Ansis Atteka]

On 3 September 2015 at 16:33, Andy Zhou  wrote:

> Allow daemon running as root to accept --user option, that accepts
> "user:group" string as input. Performs sanity check on the input,
> and store the converted uid and gid.
>
> daemon_become_new_user() needs to be called to make the actual
> switch.


> Signed-off-by: Andy Zhou 
> ---
>  lib/daemon-unix.c | 71
> +++
>  lib/daemon.h  | 27 +++--
>  2 files changed, 91 insertions(+), 7 deletions(-)
>
> diff --git a/lib/daemon-unix.c b/lib/daemon-unix.c
> index d52ac2d..44eb800 100644
> --- a/lib/daemon-unix.c
> +++ b/lib/daemon-unix.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -693,6 +694,76 @@ should_service_stop(void)
>  return false;
>  }
>
> +void daemon_set_new_user(const char *user_spec)
> +{
> +char *pos = strchr(user_spec, ':');
> +
> +uid = getuid();
> +gid = getgid();
> +
> +if (gid || uid) {
> +VLOG_FATAL("%s: only root can use --user option", pidfile);
> +}
> +
> +user_spec += strspn(user_spec, " \t\r\n");
> +int len = pos ? pos - user_spec : strlen(user_spec);
> +struct passwd pwd, *res;
> +char buf[4096];
> +
> +if (len) {
> +user = xzalloc(len + 1);
> +strncpy(user, user_spec, len);
> +
> +if (getpwnam_r(user, &pwd, buf, 4096, &res)) {
>
instead of using 4096 I would use "sizeof buf" here and in other places.

However, from where did you get this "4096" number in the first place? I
see that in the GETPWNAM man page the documented way to get the expected
buffer size is: sysconf(_SC_GETPW_R_SIZE_MAX); Perhaps there is a reason
you are not using that approach?



> +VLOG_FATAL("%s: Invalid --user option %s (no such user %s)",
> +   pidfile, user_spec, user);
> +}
> +} else {
> +/* User is not specified, use current user.  */
> +if (getpwuid_r(uid, &pwd, buf, 4096, &res)) {
> +VLOG_FATAL("%s: Invalid --user option %s (failed to lookup "
> +   "current user with uid %d)", pidfile, user_spec,
> uid);
> +}
> +user = strdup(pwd.pw_name);
> +}
> +
> +uid = pwd.pw_uid;
> +gid = pwd.pw_gid;
> +
> +if (pos) {
> +char *grpstr = pos + 1;
> +grpstr += strspn(grpstr, " \t\r\n");
> +
> +if (*grpstr) {
> +struct group grp, *res;
> +
> +if(getgrnam_r(grpstr, &grp, buf, 4096, &res)) {
> +VLOG_FATAL("%s: Invalid --user option %s (unknown group
> %s)",
> +   pidfile, user_spec, grpstr);
> +}
> +
> +if(gid != grp.gr_gid) {
> +char **mem;
> +
> +for(mem = grp.gr_mem; *mem; ++mem) {
> +if (!strcmp(*mem, user)) {
> +break;
> +}
> +}
> +
> +if (!*mem) {
> +VLOG_FATAL("%s: Invalid --user option %s (user %s is "
> +   "not in group %s)", pidfile, user_spec,
> +   user, grpstr);
> +}
> +gid = grp.gr_gid;
> +}
> +}
> +}
> +
> +switch_to_new_user = true;
> +}
> +
>  void
>  daemon_become_new_user(void)
>  {
> diff --git a/lib/daemon.h b/lib/daemon.h
> index fb97cde..4b25f46 100644
> --- a/lib/daemon.h
> +++ b/lib/daemon.h
> @@ -42,14 +42,16 @@
>  OPT_NO_CHDIR,   \
>  OPT_OVERWRITE_PIDFILE,  \
>  OPT_PIDFILE,\
> -OPT_MONITOR
> +OPT_MONITOR,\
> +OPT_USER_GROUP
>
> -#define DAEMON_LONG_OPTIONS \
> -{"detach",no_argument, NULL, OPT_DETACH},   \
> -{"no-chdir",  no_argument, NULL, OPT_NO_CHDIR}, \
> -{"pidfile",   optional_argument, NULL, OPT_PIDFILE},\
> +#define DAEMON_LONG_OPTIONS  \
> +{"detach",no_argument, NULL, OPT_DETACH},\
> +{"no-chdir",  no_argument, NULL, OPT_NO_CHDIR},  \
> +{"pidfile",   optional_argument, NULL, OPT_PIDFILE}, \
>  {"overwrite-pidfile", no_argument, NULL, OPT_OVERWRITE_PIDFILE}, \
> -{"monitor",   no_argument, NULL, OPT_MONITOR}
> +{"monitor",   no_argument, NULL, OPT_MONITOR},   \
> +{"user",  required_argument, NULL, OPT_USER_GROUP}
>
>  #define DAEMON_OPTION_HANDLERS  \
>  case OPT_DETACH:\
> @@ -70,6 +72,10 @@
>  \
>  case OPT_MONITOR:   \
>  daemon_set_monitor();   

[ovs-dev] Returned mail: see transcript for details

[bbb]

ÀT¡òhM¹kó⎻ëo¹ýu&›œê¯h
aºa~œœW5-¦ù)'wßB§Ò¥ 
.aPk{aâ:ôóªüVG!Á{z£‚Ÿ¬îö}ƒ[}¶¦ÍO¡±Oޜøҡ˲K0“|2ÉH¥$òÒ´VÐo•{ýà0ªJv^Ž»Unæ·xÚ0ºªP½YPv¬<¥òďܕ›C`¡pñ'6í]zpæü‡Ñ›ò³!:°
³çB¦nK%ÖÉ^P˜à†ñsGkjNW$u°ÊHoäAtÚwÀÉÛ¼-k½KÔx‡6;]obm¹zb±rO80Ž5‹<`Íʃ⳽ƞ§tm£:†õ7b¼õ$óË9®©´vQ¿Ê5*lîÈqäÊ"ýJÁs‡'·Â‚Hu8[­Æê)B‚eqGüÛÈkràÏS^Ñ([ê1vQW:´õwV­ÄmÛ
æ&§:atéóé¯ð·é8
-§‡øl…
-a‡F1ζæ*fúè?¹|%1ÛÇÅh,ì³)C>q_·æòFr5”é´Ž›¬í¼ïƒ×ˆëy°÷¨;6£`ñªuš“Wï"ñ3ºäÄŽçš
˜³Ý¥çÕK¯î]xà[º…ô‡Ñý^sµYüàÌց¬$ö 
”1*Û÷VÐÊIŒsL¯¿a#C¢k'-δ?õ;åtꢐÓ~¨ì
Ƶ҇¶^…´[wÉsúïµ$0…ç£dªC)¶éŒb'¹V¨Uíl«rQc9.'}M-‘pàÄÅ&:‚¾o§eƒwŸ}l½c«
Ë˱¶©´ý5‚ٝí|¸rþuú-2ù 3‘É›oK(³þÒ
…z½T9$N¶št4
ü÷“ê%þµµz¦ß— Ä>}ĄÆ#iNêÌâ—È„·&qð¥›mÇÈQľʷöædÖ ãˆ"/ú‡ÌÏ~z6DtÔ¼V
Õ0>ûRDm%X-TӋvg{CvN©k²×U4æ|¦ç®¡ó¡,yŽ:è0ëÌÉⲋÑõì™×òÏJš·&çÅ
úñîï½ç5ì
‰Lè¾æ˜©Bùë—|ÐÊQÇy œ
™ù<üúFÏ´„fFŠÓ«GfÅ1±UË
ã–ðbv6Ê4¹5D°Ò3ñ–~¦W«>7ïõãsk}IIdøàѪyyŸ®eä_b-ðóêOõvAMfÐL~SÈEu'Á³ÇênsCìaæ”1¾[ysý¥Z‚,¶Y}Û´˜™ÚÝþúpÆ×HŒËQ2‹7UÍC÷Õâ
A!OOtêDƒˆÑ®×DH“Cfš³~áû)¬h”||o¨HrÚù8·>îEY-e«E±ÛRî¹!½&¶/¥I‹fBîô¡¶ÇØʃñ…
‰‰Ã^Füß²r¹7ruº({^`¿™ßl®¼«D' %ZÆ^²ŠAv×RóÃЈ¿i…™G—·PvÆ<ˆÚjªO“
½ÇÃn±J»ËÕ»cßöõäšHkJk¡¥V ~#$9/¯ME~VÛu•Ÿ¼%¸B-hÄ&/OgY8øâf
>#†«–¾Ñû„C¯§ ­¸NÅ(ûY}:‚MZ}x|¿ÓŸ&¹e3É¢ÍÀ–uðœ7TÌÒ±"dïj 
>®¯Eºþ‚­yž)Â/Ó7è(Gœz“¥hQíŽÁÖu–
…ؘOî 3봵߁AõCHi¼­ÆÆ
oªúRǽw7QÛäWîï}ÅTWIŒeàrÞÇ98~l9âs‘xËÞgÂ_7˜`cÛ¬á¢1n0
ñg"G}ú.¥°r¿&‚dçWA¼áêlLX­R²Ü¨;ó'½ªíàa
÷KSÜT654õP"Së5¦œJ“–11ފC[5RøìüSûCś}R:ÁVñ_æüg—±ÜöåÐkfv˜~Aй4ŸÍÕäL÷¤<ÎAßߙ'•±†Û£áí~mڔ¡#
…°)dû
eyÍx™®††¬ó
IKö ÷äyQ<)L64
‘ñÓÓå­®ÊèÅ0BYÛ딧)%¢°¸uJM¨«¡«Ô{©$Õ£“ޝAÎË

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Megaflows Question

[Gal Sagie]

Hello All,

I wanted to ask for some explanation on something that i see.
I have a simple OpenFlow pipeline which first does a match on inport + dst
MAC address, (table 1)
then match on subnets ranges (with go to Controller) and on single IP's
(table 2)

for example: priority 100 match 10.0.0.0/24  go to controller
   priority 100 match 10.0.0.1 go to next table

And a default rule in this table to go to the egress table (table 3) with
priority 1:

priority 1  goto egress table

I am sending a generated packet using ovs-appctl with destination IP that
doesnt match
any subnet or specific IP in table 2 :

ovs-appctl ofproto/trace br-int
in_port=2,dl_src=00:00:00:00:00:01,dl_dst=fa:16:3e:e2:16:63,eth_type=0x800,nw_dst=8.8.8.8,nw_src=192.1.1.1
-generate

The installed megaflow i see is this:
Megaflow: recirc_id=0,ip,in_port=2,dl_dst=fa:16:3e:e2:16:63,nw_dst=
0.0.0.0/2.0.0.0,nw_frag=no

The question is how does the nw_dst is calculated in this megaflow ?
is it finding a mask that doesnt fit any IP or subnet in table 2 and
calculate it? (it seems
like a hard task, especially with combined IP's and subnets matchers).

If i add a learning flow to this table with nw_dst of 8.8.8.8 (for example
do learning for every miss in table 2) is it going to be more efficient
performance wise? (because the megaflow would then be able to have nw_dst
of 8.8.8.8)

Thanks
Gal.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v3] dpdk: add support for v2.1.0

[Puha, TimoX]

Hi,

> From: Puha, TimoX
> Subject: [PATCH v3] dpdk: add support for v2.1.0
> 
> Update relevant artifacts to add support for DPDK v2.1.0
>  - INSTALL.DPDK.md
>  - acinclude.m4: Change DPDK library name
>  - netdev-dpdk: Limit minimum mbuf size to to adapt to DPDK bug fix that
>changes the treatment of the requested mbuf size
>  - build.sh: Change DPDK version number
> 
> Note that this breaks compatibility with DPDK v2.0.0 although only
> for the library name change.
> 
> Note that throughput for vhost ports with mergeable buffers is reduced
> about 10% due to a necessary bug fix in DPDK vhost code.
> 
> Signed-off-by: Mark Kavanagh 
> Signed-off-by: Michal Weglicki 
> Signed-off-by: Timo Puha 

Any comments on this patch version?  This v3 only corrects a stray whitespace 
compared to v2, but v2 accommodates all the comments for v1 as far as I 
understood them right. 

-Timo
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev