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
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.
- there is no reinstall option
- there is nothing in tools/
If this is in CVS why hasnt it been fixed?
Bails _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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.
- there is no reinstall option
- there is nothing in tools/
If this is in CVS why hasnt it been fixed?
Bails _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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.
- there is no reinstall option
- there is nothing in tools/
If this is in CVS why hasnt it been fixed?
Bails _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
bails -
Greg Fausak -
sip