[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: gvpe, the GNU Virtual Private Ethernet daemon



On Wed, Jul 01, 2009 at 08:39:32PM -0400, Robert Edmonds wrote:
> do you mean $DAEMON instead of $NAME?  $NAME isn't moved...

Oops, yes.

> the DAEMON variable is set later because it's constructed based on the
> values of $CIPHER and $DIGEST, which can be overriden by
> /etc/default/gvpe.  so it has to be set after sourcing the defaults
> file.

Ok, that's really obvious now ;)

> in this case, though, the path to the daemon is constructed, and it
> could be constructed to a nonexistent path (say, a typo in
> /etc/default/gvpe) and the init script wouldn't run.  so instead test
> for a stable binary name included in the package (gvpectrl in this case)
> instead.

Makes perfect sense.

> > Is this change to the output text a preference, or is there a style for
> > this sort of message that I've missed somewhere?
> 
> it looks odd because log_failure_msg prints out the string you gave it
> and appends "failed!" in red letters, so your sequence prints out
> "failed!" twice.  it looks nicer if "failed!" is only printed once.
> i don't know if there's a style guide.  the message should probably fit
> on an 80 column terminal though.

I'd missed that there were two messages. Reduced it to one - I've still
used log_failure_message though, because I think it would help to make
it clear that this isn't a warn-and-continue situation.

> sorry.  the template you copied from had a lot of tabs-vs-spaces
> confusion too.

Yes, and it's the default template from dh-make, which isn't great. I may
file bugs and patches if I get around to it.

> actually, the whole init script would probably be a lot shorter / neater
> if you used start-stop-daemon :)

I've done this (again, I just believed the boilerplate was a Good Way).
So, perhaps you could take a look over the whole script again.

> > I gathered from the configure script output that extra protocols, like
> > --enable-icmp and --enable-tcp and so on had to be explicitly enabled.
> > Certainly using your configure command they don't appear at the end of
> > the outpt summary; have I mis-interpreted this?
> 
> i removed --enable-icmp and --enable-tcp because they are already
> enabled:
> 
>     --disable-icmp          enable icmp protocol support (default enabled).
>     --disable-tcp           enable tcp protocol support (default enabled).
> 
> [ appears to be a braino here in the configure help output. ]

I think I skimmed that quickly and got the wrong idea (not that it was
hard!).


> i removed --enable-rawip and --enable-udp because there doesn't appear
> to be any such options (earlier version of gvpe perhaps?).

Very possibly.
 
> and according to the changelog:
> 
>         - implemented dns tunneling (experimental now and in the future).
> 
> so i removed --enable-dns (tunneling IP over DNS in general is a huge
> hack, if the author says his implementation will always be experimental,
> may as well leave it in the default disabled state).

Agreed.

> debconf might be kind of extravagant.  i'm planning on rolling out some
> gvpe instances and i'll probably end up auto-generating /etc/gvpe/* and
> /etc/default/gvpe.  debconf might be ok if the whole thing could be
> configured via prompts, but gvpe is probably too flexible to be
> configured with debconf to most users' satisfaction.  also, remember
> that the gvpe config file has to be updated on every node when a new
> node is added.

That's exactly why I hesitated about it. I'd like to think that an
administrator building a network with gvpe would want fine control in
any case.

I've uploaded to mentors with the same version number, so same .dsc
location. Thanks.


-- 
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3  A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Attachment: signature.asc
Description: Digital signature


Reply to: