[Serusers] Over-long fields can crash SER with PostgreSQL
Jan Janak
jan at iptel.org
Fri Feb 11 22:26:39 CET 2005
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 at whoi.edu>
> Network Security -- Linux/Unix Systems Support -- Etc.
> Woods Hole Oceanographic Institution
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
More information about the sr-users
mailing list