Re: Simple cell with standalone router/server + backup

Pekka Riikonen <[email protected]> Fri, 12 Sep 2008 14:02:54 +0200 (CEST)
Newsgroups gmane.network.silc.user
Message-ID <[email protected]>
Hi,

: 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.

: 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.

: * 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.

: * 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.

: * 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.

: * 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*.

: 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/