Re: Simple cell with standalone router/server + backup

2008/9/12 Pekka Riikonen <[email protected]>:
> Hi,

Hi Pekka. Thanks for the quick reply.

>
> : If anyone quickly spots where I've gone wrong with this, that would be
> : great, as I'd really like to have some kind of redundancy for the
> : state, and not just a standalone server.
> :
> Quickly looking the problem is probably the ServerConnection entry that is
> same as the backup RouterConnection entry.  Since you don't actually have
> normal server connections you may want to replace the ServerConnection
> entry with:
>
> ServerConnection {
>  host = "dummy";
> };
>
> Unfortuantely the current silcd requires ServerConnection entry, real or
> dummy, for it to recognize that it is router.  This will be fixed in 1.2.
> I'm not sure if the backup router stuff requires IP addresses instead of
> host names, but you may also attempt to use only IP addresses and see if
> it makes a difference, also.

Hm. Okay. I tried making it a dummy connection like you suggested, and
also changed to using only IP addresses, but still tcpdump shows
absolutely no traffic on port 706 between the two hosts when I do
state changing stuff like e.g. /join foo followed by /cmode foo +f.

Do you have any other ideas? I guess I should get silcd's with
--enable-debug on both sides running instead..

>
> : Now for a few general SILC questions I couldn't find in the FAQ or by
> : googling:
> :
> : * Exactly much of the state is transferred to a backup router? Are
> : channel topics transferred? I had a look at section 3.14 Backup
> : Routers of the spec, but I'm still a bit unsure about this.
> :
> All state data is transferred, topics, modes, clients, channels, servers,
> etc.

Okay that's great. I forgot to ask though; are the public keys that
the server read in from PublicKeyDir considered state data? So that if
I at some point E would actually allow client connections to my backup
router, could my clients authenticate with their public keys to the
backup router and it would work? E.g. the keys would have been
transferred to the backup?

> : * If I should decide to let clients connect to my backup router
> : (silc2.dose.se) in the future, what would happen to client connections
> : to silc.dose.se when it goes down? Would the actual client connections
> : be "transferred" to the backup (silc2.dose.se)? (I'm guessing not).
> :
> Local connections of course gets disconnected if the router goes down.

Yes. Makes sense.

> : * The /DETACH command puzzles me. It is advertised as an option for
> : keeping presence on a network without running a client. My question is
> : then; of what use is this when all messages for me are dropped by the
> : server when I'm detached? In my opinion this is "keeping presence"
> : only in a technical sense, because to me and my peers on the network,
> : the effect is the same as a /QUIT, they can't send messages to me and
> : I can't send messages to them. I've seen it mentioned that it is good
> : if you need to upgrade your client without disconnecting, but the
> : question remains; what are the benefits of /DETACH over actually
> : disconnecting?
> :
> It preserves all channels you have joined, modes you have on the channel,
> including operator and channel founder privileges, and user modes in the
> network (except SILC operator modes).  It doesn't save messages but 1.2
> server is supposedly going to have support for the SILC services, which
> would allow you to tell the server that you want to save messages that are
> sent to you while you are detached.

Right. That actually is a valid use case for /DETACH. Great if 1.2
will support message saving.

> : * I'm using the PublicKeyDir to load public keys of clients that are
> : allowed to connect. If I want to add a new public key, I can force
> : silcd to reload the keys from the directory by sending it the HUP
> : signal. But it seems that if I remove a key from the directory and
> : send the HUP signal, the key is not removed the running silcd. I.e.
> : this mechanism is accumulative. Is this intentional? Is there another
> : way to remove a public key that has been added by PublicKeyDir from a
> : running server without restarting it?
> :
> Sounds like a bug to me.

Okay, thought so. Maybe I can get some time to look at it, I guess it
should be a pretty simple fix. Just a lot of stuff at work at the
moment.

> : * I've tried to get more debugging information in the logs or on
> : stderr by passing -D with a really high value like 100000, but still
> : the logs are pretty quiet and mostly show startup/shutdown messages
> : and authentication failures. Is there a way to get more verbose
> : debugging messages?
> :
> The silcd needs to be compiled with --enable-debug.  The max -D value is
> 99.  You may also give -d *server*.

Oh I see. I saw the --enable-debug when compiling on the OpenBSD box,
but I thought it was for debugging symbols. Maybe make the --help
message say "enable debugging messages" instead of just "enable
debugging", to be super clear :)

> : Lastly I would like to thank Pekka and all the contributors to SILC
> : for an outstanding piece of software and a kick-ass protocol and
> : network model. Very neatly packaged software too; compiled without a
> : hitch on my old-ish OpenBSD 3.9 box. Thanks!
> :
> Thanks. :)
>
>        Pekka
> ________________________________________________________________________
>  Pekka Riikonen                                 priikone at silcnet.org
>  Secure Internet Live Conferencing (SILC)       http://silcnet.org/
>

_______________________________________________________________
Info:    https://lists.silcnet.org/mailman/listinfo/silc-users
Archive: https://lists.silcnet.org/pipermail/silc-users
FAQ:     http://silcnet.org/support/faq/