11 Feb
2005
11 Feb
'05
11:26 p.m.
Did ser crash or locked up ? Usrloc has been designed to overcome
database issues, thus if a database operation fails, usrloc should
continue using internal memory cache.
If it crashed, could you, please, provide me with more information ?
Especially SER coredump along with compiled sources would be handy.
Please contact me by private email if you need more information on getting
debugging data from SER.
Jan.
On 10-02 14:47, Karl A. Krueger wrote:
We are using SER with the PostgreSQL module, so that
SER and our
Asterisk PSTN gateway and voice mail system can use the same back-end
database for user records. (Anyone who's interested in how we did this,
let me know -- it's still a little shaky, but it pretty much works.)
Recently we have encountered a problem: it seems that if any database
error occurs, SER hangs or crashes. We have so far been able to mostly
work around these conditions by being Really Careful with the database,
but it is a little unsettling.
The database schema we're working from is practically identical to the
MySQL schema that ships with SER. Notably for this problem the lengths
of all CHARACTER VARYING fields are the same. The User-Agent field is
CHARACTER VARYING(50), for instance.
So ... today boss got a copy of Xten's "eyeBeam" software, set it up
to register to our SER ... and SER promptly locked up. I looked in the
PostgreSQL database log and found this:
Feb 10 13:39:32 mabell postgres[13058]: [267] ERROR: value too long for
type character varying(50)
Whoops. SER tried to insert eyeBeam's User-Agent data, PostgreSQL
returned a data integrity error, and SER went bye-bye.
So I did a little ALTER TABLE and adjusted the field to length 128 ...
then put this in ser.cfg:
# Disallow long user-agent
if (search("^User-Agent: .{100,}") ) {
log(1, "LOG: User agent too long\n");
sl_send_reply("479", "User agent too long!");
break;
};
But this is obviously a kludge ... and doesn't fix the problem of one of
the *other* fields being over-long.
Anyone have any thoughts on this? Robustness patches for the PostgreSQL
module or usrloc? Better ser.cfg workarounds to protect the world from
malformed or over-long SIP header fields? Should I just change all the
database fields to TEXT instead of CHARACTER VARYING(whatever) ?
--
Karl A. Krueger <kkrueger(a)whoi.edu>
Network Security -- Linux/Unix Systems Support -- Etc.
Woods Hole Oceanographic Institution
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers