[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