Since watchfrr invokes vtysh to gather the show run output and
write the data, if we are operating inside of a namespace FRR
must also pass this in.
Yes. This seems hacky. I don't fully understand why vtysh
is invoked this way.
New output:
sharpd@eva:~/frr3$ sudo vtysh -N one
Hello, this is FRRouting (version 8.1-dev).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
eva# wr mem
Note: this version of vtysh never writes vtysh.conf
% Can't open configuration file /etc/frr/one/vtysh.conf due to 'No such file or directory'.
Building Configuration...
Integrated configuration saved to /etc/frr/one/frr.conf
[OK]
eva#
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
struct thread_master *master;
static bool watch_only = false;
+const char *pathspace;
typedef enum {
PHASE_NONE = 0,
else
unsetenv("FRR_PATHSPACE");
+ /*
+ * when watchfrr_di.pathspace is read, if it is not specified
+ * pathspace is NULL as expected
+ */
+ pathspace = watchfrr_di.pathspace;
+
if (netns_en && !netns)
netns = watchfrr_di.pathspace;
+
if (netns_en && netns && netns[0])
netns_setup(netns);
DECLARE_MGROUP(WATCHFRR);
+/*
+ * This is the name of the pathspace we are in `-N XXX`
+ * If the default then this is NULL
+ */
+extern const char *pathspace;
+
extern void watchfrr_vty_init(void);
extern pid_t integrated_write_pid;
/* don't allow the user to pass parameters, we're root here!
* should probably harden vtysh at some point too... */
- execl(VTYSH_BIN_PATH, "vtysh", "-w", NULL);
+ if (pathspace)
+ execl(VTYSH_BIN_PATH, "vtysh", "-N", pathspace, "-w", NULL);
+ else
+ execl(VTYSH_BIN_PATH, "vtysh", "-w", NULL);
/* unbuffered write; we just messed with stdout... */
char msg[512];