15 Sep
2006
15 Sep
'06
5:48 a.m.
its come up before so i have to ask
I have read the list archives and googled.
1. there is no reinstall option
2. there is nothing in tools/
If this is in CVS why hasnt it been fixed?
Bails
15 Sep
15 Sep
7:21 a.m.
What's amusing is WHY this comes up. I'm not entirely sure the table check
code is right (or it may be correct, but it's not exactly rational).
For instance, the a month or two ago, we were switching from using
lookup("aliases") to alias_db_lookup("dbaliases") as our alias check
(porting
the code from openser to ser).
There was a spot in the config where we'd forgotten to change the command from
lookup to alias_db_lookup, but had changed the table name from aliases to
dbaliases.
What happens? Out pops the 'register_udomain() Invalid table version' error.
Now, I'm not sure what it's checking for in that case, but I can tell you that
THAT error message (and the advice it gives to use the reinstall option of the
mysql script) is entirely NOT helpful. :)
To play around, I added a version entry for dbaliases and matched its version
to the aliases table just to see if indeed that was the result of a version
check. No dice. What it apparently was doing was checking the format of the
dbaliases table against its expected format (aliases is VERY different in
format) and spitting out an error that the table version was incorrect. Um...
no... the table STRUCTURE was incorrect, but that really has nothing at all to
do with the version per se.
I'm thinking that perhaps the version table with its version numbers to denote
some sort of extra check on the tables is, perhaps, not the best way to do
things. At the very least, there ought to be more applicable error messages
when a structure check fails. Something like "aliases table not proper
structure for lookup() command" would have been the most ideal error message
of course. I'd have known in a heartbeat where the problem was.
Someone who DIDN'T know what he was doing might have spent all day trying to
install/reinstall the DB as per instructions in the error message (which don't
work), and would still have gotten nowhere.
N.
On Fri, 15 Sep 2006 10:48:08 +0100, bails wrote
its come up before so i have to ask
I have read the list archives and googled.
1. there is no reinstall option
2. there is nothing in tools/
If this is in CVS why hasnt it been fixed?
Bails
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:48 a.m.
Howdy N.,
I've seen your email on this list often.
Would you mind answering a question?
You have ported from openser to ser. Why?
I've been thinking about it, I just wonder what
you experience was? Does it work about the same?
Is anything missing? Are there features in ser that made
it the one to use?
OK, six questions... :-)
---greg
On Sep 15, 2006, at 6:21 AM, sip wrote:
What's amusing is WHY this comes up. I'm not
entirely sure the
table check
code is right (or it may be correct, but it's not exactly rational).
For instance, the a month or two ago, we were switching from using
lookup("aliases") to alias_db_lookup("dbaliases") as our alias
check (porting
the code from openser to ser).
There was a spot in the config where we'd forgotten to change the
command from
lookup to alias_db_lookup, but had changed the table name from
aliases to
dbaliases.
What happens? Out pops the 'register_udomain() Invalid table
version' error.
Now, I'm not sure what it's checking for in that case, but I can
tell you that
THAT error message (and the advice it gives to use the reinstall
option of the
mysql script) is entirely NOT helpful. :)
To play around, I added a version entry for dbaliases and matched
its version
to the aliases table just to see if indeed that was the result of a
version
check. No dice. What it apparently was doing was checking the
format of the
dbaliases table against its expected format (aliases is VERY
different in
format) and spitting out an error that the table version was
incorrect. Um...
no... the table STRUCTURE was incorrect, but that really has
nothing at all to
do with the version per se.
I'm thinking that perhaps the version table with its version
numbers to denote
some sort of extra check on the tables is, perhaps, not the best
way to do
things. At the very least, there ought to be more applicable error
messages
when a structure check fails. Something like "aliases table not proper
structure for lookup() command" would have been the most ideal
error message
of course. I'd have known in a heartbeat where the problem was.
Someone who DIDN'T know what he was doing might have spent all day
trying to
install/reinstall the DB as per instructions in the error message
(which don't
work), and would still have gotten nowhere.
N.
On Fri, 15 Sep 2006 10:48:08 +0100, bails wrote
its come up before so i have to ask
I have read the list archives and googled.
1. there is no reinstall option
2. there is nothing in tools/
If this is in CVS why hasnt it been fixed?
Bails
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:11 a.m.
Heh, sorry, Greg. It's only that particular module that I've grabbed from
OpenSER that I use in SER.
I've used SER all along. Although, don't get me wrong, there are many
occasions where I find myself wishing that feature X was available in SER (the
ability to use AVPs in the UAC module for instance, would be immensely handy).
If you have OpenSER running, and running well, there's not really any reason
to move back to SER at the moment. In time, that may change, as the two paths
of development are just BEGINNING to diverge more than they had in the past.
But for now, if everything's working for you, you won't really GAIN anything
by moving to SER, and you're actually liable to lose a lot of functionality
that you may be used to.
I chose SER originally because OpenSER was just starting out and I wasn't sure
what sort of direction it would go or what sort of support it would have if I
needed it (we use SER in a production system for quite a great many users
worldwide, so I didn't want to have a product built and then suddently find
out there was no avenue for professional support should we need to spend the
money).
These days, it's really just a matter of preference. OpenSER releases versions
more often and has some handy features available. They're also quite good with
making documentation available. There is, however, concern among some that,
since there are more version releases, there's more a chance for instability.
SER releases versions VERY seldom and, overall, does NOT have anything
resembling good docs. It IS, however, rock solid stable in its current
release, and has many tried and true installations throughout the world using
it (SIPPhone/Gizmo project, FWD, IdeaSIP, etc).
This isn't to say that OpenSER is ACTUALLY any less stable. It's all a matter
of perception, really.
OpenSER and SER are NOW, however, in their more recent forms, becoming more
and more different in the basic underlying configurations. This may or may not
cause issues with migration, but it will almost certainly cause module
developers to end up having to pick sides on which code base to develop for...
and that could cause drastic differences in functionality.
I guess only the future will tell what's in store.
N.
N.
On Fri, 15 Sep 2006 08:48:03 -0500, Greg Fausak wrote
Howdy N.,
I've seen your email on this list often.
Would you mind answering a question?
You have ported from openser to ser. Why?
I've been thinking about it, I just wonder what
you experience was? Does it work about the same?
Is anything missing? Are there features in ser that made
it the one to use?
OK, six questions... :-)
---greg
On Sep 15, 2006, at 6:21 AM, sip wrote:
> What's amusing is WHY this comes up. I'm not entirely sure the
> table check
> code is right (or it may be correct, but it's not exactly rational).
>
> For instance, the a month or two ago, we were switching from using
> lookup("aliases") to alias_db_lookup("dbaliases") as our alias
> check (porting
> the code from openser to ser).
>
> There was a spot in the config where we'd forgotten to change the
> command from
> lookup to alias_db_lookup, but had changed the table name from
> aliases to
> dbaliases.
>
> What happens? Out pops the 'register_udomain() Invalid table
> version' error.
>
> Now, I'm not sure what it's checking for in that case, but I can
> tell you that
> THAT error message (and the advice it gives to use the reinstall
> option of the
> mysql script) is entirely NOT helpful. :)
>
> To play around, I added a version entry for dbaliases and matched
> its version
> to the aliases table just to see if indeed that was the result of a
> version
> check. No dice. What it apparently was doing was checking the
> format of the
> dbaliases table against its expected format (aliases is VERY
> different in
> format) and spitting out an error that the table version was
> incorrect. Um...
> no... the table STRUCTURE was incorrect, but that really has
> nothing at all to
> do with the version per se.
>
> I'm thinking that perhaps the version table with its version
> numbers to denote
> some sort of extra check on the tables is, perhaps, not the best
> way to do
> things. At the very least, there ought to be more applicable error
> messages
> when a structure check fails. Something like "aliases table not proper
> structure for lookup() command" would have been the most ideal
> error message
> of course. I'd have known in a heartbeat where the problem was.
>
> Someone who DIDN'T know what he was doing might have spent all day
> trying to
> install/reinstall the DB as per instructions in the error message
> (which don't
> work), and would still have gotten nowhere.
>
>
> N.
>
>
> On Fri, 15 Sep 2006 10:48:08 +0100, bails wrote
>> its come up before so i have to ask
>>
>> I have read the list archives and googled.
>>
>> 1. there is no reinstall option
>> 2. there is nothing in tools/
>>
>> If this is in CVS why hasnt it been fixed?
>>
>> Bails
>> _______________________________________________
>> Serusers mailing list
>> Serusers(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
6682
days inactive
6682
days old
3 comments
3 participants
participants (3)
-
bails -
Greg Fausak -
sip