when i try to use my kamailio.cfg with sip-router, the first place where it fails is this:
dns_try_ipv6=no
sip-router says that the config var is unknown.
sip-router core cookbook lists the variable, but does not say anything about it.
is there a replacement or what should i do about it?
-- juha
On May 28, 2009 at 20:23, Juha Heinanen jh@tutpro.com wrote:
when i try to use my kamailio.cfg with sip-router, the first place where it fails is this:
dns_try_ipv6=no
sip-router says that the config var is unknown.
That's strange. It works for me with and without USE_IPV6.
sip-router core cookbook lists the variable, but does not say anything about it.
is there a replacement or what should i do about it?
It should work as it is. Are you sure you haven't mispelled it somehow? Could you send me the output of ser -cf your.cfg ?
Andrei
On 05/28/2009 10:01 PM, Andrei Pelinescu-Onciul wrote:
On May 28, 2009 at 20:23, Juha Heinanen jh@tutpro.com wrote:
when i try to use my kamailio.cfg with sip-router, the first place where it fails is this:
dns_try_ipv6=no
sip-router says that the config var is unknown.
That's strange. It works for me with and without USE_IPV6.
it works for me as well.
Cheers, Daniel
sip-router core cookbook lists the variable, but does not say anything about it.
is there a replacement or what should i do about it?
It should work as it is. Are you sure you haven't mispelled it somehow? Could you send me the output of ser -cf your.cfg ?
Andrei
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Andrei Pelinescu-Onciul writes:
It should work as it is. Are you sure you haven't mispelled it somehow? Could you send me the output of ser -cf your.cfg ?
sorry, i rechecked and the line sip-router is complaining is the next one:
rev_dns=no dns_use_search_list=no dns_try_ipv6=no disable_dns_blacklist=yes ********** this one
# sip-router -cf /etc/sip-router/sip-router.cfg 0(8340) : <core> [cfg.y:2915]: parse error in config file, line 231, column 22: syntax error 0(8340) : <core> [cfg.y:2915]: parse error in config file, line 231, column 22: unknown config variable 0(8340) : <core> [cfg.y:2912]: parse error in config file, line 231, column 23-25: ERROR: bad config file (3 errors) 0(8340) DEBUG: <core> [mem/shm_mem.c:261]: shm_mem_destroy
according to cookbook there are these dnsblacklist related variables:
dst_blacklist_expire|dst_blacklist_ttl dst_blacklist_gc_interval dst_blacklist_init dst_blacklist_mem
perhaps one of those can be used to get the same effect as k disable_dns_blacklist=yes?
-- juha
On May 28, 2009 at 22:15, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
It should work as it is. Are you sure you haven't mispelled it somehow? Could you send me the output of ser -cf your.cfg ?
sorry, i rechecked and the line sip-router is complaining is the next one:
rev_dns=no dns_use_search_list=no dns_try_ipv6=no disable_dns_blacklist=yes ********** this one
# sip-router -cf /etc/sip-router/sip-router.cfg 0(8340) : <core> [cfg.y:2915]: parse error in config file, line 231, column 22: syntax error 0(8340) : <core> [cfg.y:2915]: parse error in config file, line 231, column 22: unknown config variable 0(8340) : <core> [cfg.y:2912]: parse error in config file, line 231, column 23-25: ERROR: bad config file (3 errors) 0(8340) DEBUG: <core> [mem/shm_mem.c:261]: shm_mem_destroy
according to cookbook there are these dnsblacklist related variables:
dst_blacklist_expire|dst_blacklist_ttl dst_blacklist_gc_interval dst_blacklist_init dst_blacklist_mem
perhaps one of those can be used to get the same effect as k disable_dns_blacklist=yes?
dst_blacklist_init=off if you want it disabled without the possibility to enable it later ar runtime. use_dst_blacklist=off, if you want to start with it disabled, but with the possibility to enable it later at runtime via rpcs (e.g. $ sercmd cfg.set_int_now core use_dst_blacklist 1 ).
Note however that the blacklist in sr is ip based and not dns based (I don't know how the blacklist worked in k).
Andrei
Andrei Pelinescu-Onciul writes:
dst_blacklist_init=off if you want it disabled without the possibility to enable it later ar runtime. use_dst_blacklist=off, if you want to start with it disabled, but with the possibility to enable it later at runtime via rpcs (e.g. $ sercmd cfg.set_int_now core use_dst_blacklist 1 ).
Note however that the blacklist in sr is ip based and not dns based (I don't know how the blacklist worked in k).
i think i was mixing things up again. sr variables are dst, not dns. perhaps they are not same thing at all. in k,
disable_dns_blacklist
The DNS resolver, when configured with failover, can automatically store in a temporary blacklist the failed destinations. This will prevent (for a limited period of time) openser to send requests to destination known as failed. So, the blacklist can be used as a memory for the DNS resolver.
The temporary blacklist created by DNS resolver is named ??dns?? and it is by default selected for usage (no need use the use_blacklist()) function. The rules from this list have a life time of 4 minutes - you can change it at compile time, from blacklists.h .
Can be 'yes' or 'no'. By default the blacklist is disabled (Default value is 'yes').
if sip-router does not include dns blacklisting, then i can just delete the line, because i was turning dns black listing off in k config.
-- juha
On May 28, 2009 at 22:32, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
dst_blacklist_init=off if you want it disabled without the possibility to enable it later ar runtime. use_dst_blacklist=off, if you want to start with it disabled, but with the possibility to enable it later at runtime via rpcs (e.g. $ sercmd cfg.set_int_now core use_dst_blacklist 1 ).
Note however that the blacklist in sr is ip based and not dns based (I don't know how the blacklist worked in k).
i think i was mixing things up again. sr variables are dst, not dns. perhaps they are not same thing at all. in k,
disable_dns_blacklist
The DNS resolver, when configured with failover, can automatically store in a temporary blacklist the failed destinations. This will prevent (for a limited period of time) openser to send requests to destination known as failed. So, the blacklist can be used as a memory for the DNS resolver.
In sr/ser we have dns cache which caches also negative replies.
The temporary blacklist created by DNS resolver is named ??dns?? and it is by default selected for usage (no need use the use_blacklist()) function. The rules from this list have a life time of 4 minutes - you can change it at compile time, from blacklists.h .
Can be 'yes' or 'no'. By default the blacklist is disabled (Default value is 'yes').
In this case, try dns_cache_negative_ttl=0 (or you could disable the entire dns cache with ude_dns_cache=off, but that will disable also dns failover and in general I wouldn't recommend it).
if sip-router does not include dns blacklisting, then i can just delete the line, because i was turning dns black listing off in k config.
Andrei
Andrei Pelinescu-Onciul writes:
In this case, try dns_cache_negative_ttl=0 (or you could disable the entire dns cache with ude_dns_cache=off, but that will disable also dns failover and in general I wouldn't recommend it).
thanks. i tried to document these two in sr core cookbook.
-- juha
On May 28, 2009 at 23:02, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
In this case, try dns_cache_negative_ttl=0 (or you could disable the entire dns cache with ude_dns_cache=off, but that will disable also dns failover and in general I wouldn't recommend it).
thanks. i tried to document these two in sr core cookbook.
They are documented in: doc/dns.txt doc/dst_blacklist.txt and in NEWS (just grep after the name).
In fact almost all config variables and new script commands are briefly documented in NEWS.
Andrei
On May 29, 2009 at 09:50, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
They are documented in: doc/dns.txt doc/dst_blacklist.txt and in NEWS (just grep after the name).
good that docs exist somewhere. however, it would be more user friendly if core documentation would be in the wiki.
It might be, but I prefer to have it along the code. It doesn't require starting a browser or internet access to update it and it's easy to spot if a new feature is not documented.
Andrei
On 29-05 09:35, Andrei Pelinescu-Onciul wrote:
On May 29, 2009 at 09:50, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
They are documented in: doc/dns.txt doc/dst_blacklist.txt and in NEWS (just grep after the name).
good that docs exist somewhere. however, it would be more user friendly if core documentation would be in the wiki.
It might be, but I prefer to have it along the code. It doesn't require starting a browser or internet access to update it and it's easy to spot if a new feature is not documented.
How about adopting the dokuwiki syntax for plain-text documentation files in the repository? It is readable and easy to remember and we can then come up with a way how to synchronize them with the wiki.
Jan.
On May 29, 2009 at 12:30, Jan Janak jan@iptel.org wrote:
On 29-05 09:35, Andrei Pelinescu-Onciul wrote:
On May 29, 2009 at 09:50, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
They are documented in: doc/dns.txt doc/dst_blacklist.txt and in NEWS (just grep after the name).
good that docs exist somewhere. however, it would be more user friendly if core documentation would be in the wiki.
It might be, but I prefer to have it along the code. It doesn't require starting a browser or internet access to update it and it's easy to spot if a new feature is not documented.
How about adopting the dokuwiki syntax for plain-text documentation files in the repository? It is readable and easy to remember and we can then come up with a way how to synchronize them with the wiki.
Is there an easy way to generate a .html or plain txt from them or to do some syntax checking?
Andrei
On 29-05 12:52, Andrei Pelinescu-Onciul wrote:
On May 29, 2009 at 12:30, Jan Janak jan@iptel.org wrote:
On 29-05 09:35, Andrei Pelinescu-Onciul wrote:
On May 29, 2009 at 09:50, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
They are documented in: doc/dns.txt doc/dst_blacklist.txt and in NEWS (just grep after the name).
good that docs exist somewhere. however, it would be more user friendly if core documentation would be in the wiki.
It might be, but I prefer to have it along the code. It doesn't require starting a browser or internet access to update it and it's easy to spot if a new feature is not documented.
How about adopting the dokuwiki syntax for plain-text documentation files in the repository? It is readable and easy to remember and we can then come up with a way how to synchronize them with the wiki.
Is there an easy way to generate a .html or plain txt from them or to do some syntax checking?
They are plain text, I don't think you can do syntax checking and I don't think it is needed, because the format is very simple:
====== Heading ======
* List item one * List item two
- Numbered list item
paragraps separated by spaces
Links with description [[http://usenix.org%7CUSENIX]]
**bold** //italic// __underlined__ ''monospace''
That's all you need, I think.
If we people stick to this format in text files in the git repository then we can easily make them visible in the wiki. Synchronization git->dokuwiki is easy.
For the opposite direction (i.e. when somebody modifies the wiki page), I am not yet sure, but I guess it should not be hard to make dokuwiki send a diff to the mailing list when somebody modifies a wiki page that originates from the git repository.
Jan.
Jan Janak writes:
How about adopting the dokuwiki syntax for plain-text documentation files in the repository? It is readable and easy to remember and we can then come up with a way how to synchronize them with the wiki.
that is what i was also thinking. we could then keep the docs in the source tree and autogenerate core cookbook wiki page.
-- juha
On 05/29/2009 06:25 PM, Juha Heinanen wrote:
Jan Janak writes:
How about adopting the dokuwiki syntax for plain-text documentation files in the repository? It is readable and easy to remember and we can then come up with a way how to synchronize them with the wiki.
that is what i was also thinking. we could then keep the docs in the source tree and autogenerate core cookbook wiki page.
there has to be two-way update. Kamailio wiki was built with large contribution of community, anonymous users without devel access -- more details, examples, spell fixes.
Cheers, Daniel
Daniel-Constantin Mierla writes:
there has to be two-way update. Kamailio wiki was built with large contribution of community, anonymous users without devel access -- more details, examples, spell fixes.
my understanding is that we are here only talking about core cookbook, not the whole wiki.
if information is in two places, one of them is always out of sync, which is very bad. perhaps it would be possible to get the core definitions from source tree to which people could add comments, example. etc. like online php manual.
-- juha
On 05/29/2009 06:39 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
there has to be two-way update. Kamailio wiki was built with large contribution of community, anonymous users without devel access -- more details, examples, spell fixes.
my understanding is that we are here only talking about core cookbook, not the whole wiki.
does not matter, if something is kept in git and wiki at same time, has to be sync'ed in both ways, otherwise we lose information.
In K we went for wiki because devels were not very diligent in writing docs and there were good results.
Cheers, Daniel
if information is in two places, one of them is always out of sync, which is very bad. perhaps it would be possible to get the core definitions from source tree to which people could add comments, example. etc. like online php manual.
-- juha
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com