.69 pre fix vrs .7+ rev User account problem

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

.69 pre fix vrs .7+ rev User account problem

Master_Mirage
We have spent alot of time trying to understand a potental problem with registerd users accounts.
In .69 pre and post fixes all currently reg. users can log in just fine. B4 the migration to .69+ revs there were 55 reg. users. After migration 10 more users signed up and all are working fine in .69+ revs but.
In order to evavluate .7+ rev's we cloned the working mysql with all 65 users from the currently working rev.
to find that only 55 (pre-migration) accounts can log into the test grid running .7+.
When the other 10 try, it says thay have no account. Looking at the DB data i see the user's accounts there but there is a mis-match between users and useraccount, one shows 55 the other 65.
Im not shure how to repair this or what exactly is going on that causes the problem.
Users continue to sign up to use our grid at .69+ without issues but if we eventualy goto .7+ it looks like only the orginal 55 would be able to log into it.
It loads .7+ and shows no migrations needed is the odd part. If i knew where to look or change would be excellent info if anyone knows.
(We will mantis this should this look like a problem with core but cant tell whats what to know that yet)

Tnx
Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Diva Canto
That sounds like the tool that is creating the new accounts is not
working correctly or is writing the data in the old tables. That is
outside OpenSim, it's your tool.

Master_Mirage wrote:

> We have spent alot of time trying to understand a potental problem with
> registerd users accounts.
> In .69 pre and post fixes all currently reg. users can log in just fine. B4
> the migration to .69+ revs there were 55 reg. users. After migration 10 more
> users signed up and all are working fine in .69+ revs but.
> In order to evavluate .7+ rev's we cloned the working mysql with all 65
> users from the currently working rev.
> to find that only 55 (pre-migration) accounts can log into the test grid
> running .7+.
> When the other 10 try, it says thay have no account. Looking at the DB data
> i see the user's accounts there but there is a mis-match between users and
> useraccount, one shows 55 the other 65.
> Im not shure how to repair this or what exactly is going on that causes the
> problem.
> Users continue to sign up to use our grid at .69+ without issues but if we
> eventualy goto .7+ it looks like only the orginal 55 would be able to log
> into it.
> It loads .7+ and shows no migrations needed is the odd part. If i knew where
> to look or change would be excellent info if anyone knows.
> (We will mantis this should this look like a problem with core but cant tell
> whats what to know that yet)
>
> Tnx
>
> -----
> Our New Web Page
> Http://www.TritonGrid.com
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Master_Mirage
Ty, its the same tool that has allways been used for over a year and a 1/2 now and continues to work fine in .69 post and pre-fixes for all reg users currently. What we couldent figuer out is why only 10 do not show up in .7+ but the orgianal 55 do useing the same tool. The mysql DB is an exact clone thats run on its own instance. I would have expected .7+ to use them all not just some of them or at least see that it needed to migrate the additional accounts as it did with the older 55 accounts.
What DB is actualy going tobe used for accounts? And how do i take the additional 10 and fix them ?. At somepoint this will need tobe done as there active accounts.
The tool its selph dosent point to the clone beta grid we run in par. with our .69 (.7 is only using what data there allready is), not adding to it. We do know a new tool will have tobe made for .7 but never got that far yet. Its only intened to use current user's data that allready exists and works in .69 but only some work in .7 (pre .69 ones). Mostly were tying to evaluate what changes we will need to make when the time comes and what to do with the 10 that arnt working that were created in .69 but not in .68+ (the problem 10).
All the user account data that uses .69 type looks consistant with all the others.
Making new accounts in .69 works fine but dont show up in .7. All .68 accounts do show up as active in all 3.
Tnx again

Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Diva Canto
I don't know the particulars of your situation, and that's besides the
point. The main point, stated here several times, is that the database
schema has changed considerably in 0.7; the tools for user registration
that work pre-0.7 will not work in 0.7. Specifically for user accounts,
pre-0.7 uses the table users, while 0.7 uses the new table useraccounts.
You will need to change your tool to use the new tables; or use a new
user registration app altogether.

Info about registration apps not working:
https://lists.berlios.de/pipermail/opensim-users/2010-March/004017.html

Info about DB changes:
https://lists.berlios.de/pipermail/opensim-dev/2010-January/008248.html

On 5/5/2010 8:44 AM, Master_Mirage wrote:

> Ty, its the same tool that has allways been used for over a year and a 1/2
> now and continues to work fine in .69 post and pre-fixes for all reg users
> currently. What we couldent figuer out is why only 10 do not show up in .7+
> but the orgianal 55 do useing the same tool. The mysql DB is an exact clone
> thats run on its own instance. I would have expected .7+ to use them all not
> just some of them or at least see that it needed to migrate the additional
> accounts as it did with the older 55 accounts.
> What DB is actualy going tobe used for accounts? And how do i take the
> additional 10 and fix them ?. At somepoint this will need tobe done as there
> active accounts.
> The tool its selph dosent point to the clone beta grid we run in par. with
> our .69 (.7 is only using what data there allready is), not adding to it. We
> do know a new tool will have tobe made for .7 but never got that far yet.
> Its only intened to use current user's data that allready exists and works
> in .69 but only some work in .7 (pre .69 ones). Mostly were tying to
> evaluate what changes we will need to make when the time comes and what to
> do with the 10 that arnt working that were created in .69 but not in .68+
> (the problem 10).
> All the user account data that uses .69 type looks consistant with all the
> others.
> Making new accounts in .69 works fine but dont show up in .7. All .68
> accounts do show up as active in all 3.
> Tnx again
>
>
>
> -----
> Our New Web Page
> Http://www.TritonGrid.com
>    

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Master_Mirage
Ty diva for your fast answer, i will pass this on to our users, as there seems tobe no solution really. Users vote on potental changes and im shure donot want to loose there current working accounts but we leave that up to them to say as its there hard work at risk anyway.

Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Diva Canto
I'm not sure you're understanding what I'm saying. One last attempt,
this is my last email on this thread: user account migration works fine,
as you very well reported. Your previously-existing accounts are all
fine in 0.7. What does not work well is the tool that you have there
that creates new accounts. That tool seems to be creating accounts in
the old users table which is not used by 0.7 code. So you either need to
fix your tool or wait for the new crop of web apps that are coming that
are compatible with 0.7. Examples: SimianGrid frontend and my own Wifi,
among, I'm sure, lots of others in the making.

On 5/5/2010 10:08 AM, Master_Mirage wrote:

> Ty diva for your fast answer, i will pass this on to our users, as there
> seems tobe no solution really. Users vote on potental changes and im shure
> donot want to loose there current working accounts but we leave that up to
> them to say as its there hard work at risk anyway.
>
>
>
> -----
> Our New Web Page
> Http://www.TritonGrid.com
>    

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Master_Mirage
Yes .68 users migrated just fine to .7 .69 users accounts dont. The same tool was use for both .68 and .69. we allready know the tool will not work in .7 for new users. Its not really about the tool as these accounts ALLREADY exist in .69 and work fine in .69..
Sry to bother yah


Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Robert L martin
On Wed, May 5, 2010 at 3:01 PM, Master_Mirage <[hidden email]> wrote:
>
> Yes .68 users migrated just fine to .7 .69 users accounts dont. The same tool
> was use for both .68 and .69. we allready know the tool will not work in .7
> for new users. Its not really about the tool as these accounts ALLREADY
> exist in .69 and work fine in .69..
> Sry to bother yah
>
>
given that you seem to have hit an edge case bug would is be possible
to dump the db that has the "missing" members and then flip the
entries to the "correct" field??

(also you may want to try doing an IAR dump of the inventory for each
then recreating the accounts)

--
Robert L Martin
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Master_Mirage
Robert L martin wrote
On Wed, May 5, 2010 at 3:01 PM, Master_Mirage <mirage123@verizon.net> wrote:
>
> Yes .68 users migrated just fine to .7 .69 users accounts dont. The same tool
> was use for both .68 and .69. we allready know the tool will not work in .7
> for new users. Its not really about the tool as these accounts ALLREADY
> exist in .69 and work fine in .69..
> Sry to bother yah
>
>
given that you seem to have hit an edge case bug would is be possible
to dump the db that has the "missing" members and then flip the
entries to the "correct" field??

(also you may want to try doing an IAR dump of the inventory for each
then recreating the accounts)

--
Robert L Martin
_______________________________________________
Opensim-users mailing list
Opensim-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-users
Robert, I am in the process of  making an totaly new clone Mysql instance of the current working .69 one all 65 users) in the off chance that the test clone got messed up somehow. Its a rather lengthy process as were at 25+ gigs.  The use of iar' for the effected acounts is a problem as well, as i have to know each users password and as a rule we never ask ppl for that. Asuming that we did that im not shure what will happen with there inworld sim developments that are used by all. There work spans well over 30 of our 100+ regions. While we could save the regions in oar's i dont think the ownership of there in world content will return to them after the oar and iar restores.
I will offer that as a possable solution should thay feel .7 is what thay want vrs staying with .69 and branch the core code off from there.
 Right now none of this is critical as what were running now is working well for them and our beta test grid is only used for them to have a fwd look into whats next and if thay want it.
Anyway thx everyone for your suggestions so far.

Tnx
Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Master_Mirage
In reply to this post by Master_Mirage
Yaaahhh :)
Ok i found a solution that worked.
1st droped table 'useraccounts' (.7 dident initaly see this was gone and did not re-make it)
2and droped table 'migrations' (.7 did see this was gone)

Re-start robust (takes a long time as it starts at 1)
then
Re-start opensim.exe (also takes awhile)

Result: Useraccounts and migration tables were recreated and the orginal existing user accounts (all of them) were added into the DB. ALL current active accounts can now log in (all 65).

This as robert pointed out is probabley an edge case problem and should not be done unless your real real shure everything has a backup!
For us we could risk it failing as this was done on a clone of our normal production servers DB, not directly to the master so a recovery procedure could be tested safely.

Tnx for all the input and hopefully others wount run into this but if you do we hope it helps.
Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Master_Mirage
Sub Notes:
 We did try 1st to drop just 'useracounts' table and re-launch robust and opensim.exe. It didnot see the table was gone and loaded completly anyway. It did not make a new one.

Next (after putting the orginal table back) Droped the migrations table. It did see it wasent there and redid just the migrations table but not fix usersacounts table (problem remained the same).

We had to drop both tables at the same time then it did remake both correctly and used the orginal un-touched 'user' table data.
Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Diva Canto
The migrations table is the one that keeps information about which
migrations have been run. So if you run migrations once over a data
resource table (useraccounts or any other) the last migration number
will be stored, and migration will not happen again.

I don't recommend dropping the migrations table entirely -- that's
calling for trouble. When migrations go wrong for whatever reason, I
recommend deleting only the row in the migrations table that corresponds
to the data resource in question -- in this case the UserAccount row in
that table. Leave the other rows alone.

Master_Mirage wrote:

> Sub Notes:
>  We did try 1st to drop just 'useracounts' table and re-launch robust and
> opensim.exe. It didnot see the table was gone and loaded completly anyway.
> It did not make a new one.
>
> Next (after putting the orginal table back) Droped the migrations table. It
> did see it wasent there and redid just the migrations table but not fix
> usersacounts table (problem remained the same).
>
> We had to drop both tables at the same time then it did remake both
> correctly and used the orginal un-touched 'user' table data.
>
> -----
> Our New Web Page
> Http://www.TritonGrid.com
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: .69 pre fix vrs .7+ rev User account problem

Master_Mirage
Diva Canto wrote
The migrations table is the one that keeps information about which
migrations have been run. So if you run migrations once over a data
resource table (useraccounts or any other) the last migration number
will be stored, and migration will not happen again.

I don't recommend dropping the migrations table entirely -- that's
calling for trouble. When migrations go wrong for whatever reason, I
recommend deleting only the row in the migrations table that corresponds
to the data resource in question -- in this case the UserAccount row in
that table. Leave the other rows alone.

Master_Mirage wrote:
> Sub Notes:
>  We did try 1st to drop just 'useracounts' table and re-launch robust and
> opensim.exe. It didnot see the table was gone and loaded completly anyway.
> It did not make a new one.
>
> Next (after putting the orginal table back) Droped the migrations table. It
> did see it wasent there and redid just the migrations table but not fix
> usersacounts table (problem remained the same).
>
> We had to drop both tables at the same time then it did remake both
> correctly and used the orginal un-touched 'user' table data.
>
> -----
> Our New Web Page
> Http://www.TritonGrid.com
_______________________________________________
Opensim-users mailing list
Opensim-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-users
Ahh.. ty, ill have a look at it. At somepoint ill need to re-do the master's data but for now allready reg. users can explore the coolness of .7 with out harm. Its run as a beta test grid like LL tends todo as a 1st look type thing.  As the master data base is still using .69 and has no problems i think were ok to wait untill .7 is adopted.
Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Save the Trees !!?

drwhiet@spacefriends.de
HI,

today there was a TREE thread (and to stay green) .. I just tried the tree
module on
the latest osgrid OpenSim 0.6.9 (RC1) 0.6.9-post-fixes 768a7c0: 2010-04-27
(interface6)

even with trees enabled in the .ini  ( or while trying Whitestars way on the

osgrid.org - Tree Population link
http://osgrid.org/forums/viewtopic.php?f=9&t=1225&start=0
by startin it manually in the console

it does not start growing. If somebody is interested

In the console i do

tree activate true 21:34:27 - [TREES]: Activating Trees
tree load tree.xml 21:33:02 - [TREES]: Loaded copse: ATPM:
stefan; 500; 50.0; 20.0; 200.0; Kelp1; <
                                        128, 128, 0>; <5, 5, 5>; <15, 15,
15>; <2.5, 2.5, 2.5>;

tree plant name1 New tree planting for copse name1
tree statistics Region (WordfromtheWise Sandbox) # tree
statistics
                                        21:35:50 - [TREES]: Activity State:
True;  Update Rate: 1000
                                        21:35:50 - [TREES]: Copse name1; 0
trees; frozen False
If i try again to plant 21:36:45 - [TREES]: Copse name1 has already
been planted ..


Even when rezzed all trees and bushes inworld before nothing changes ..
Nothing grows
Also tree remove and replanting does not work ..

Back in 2009 there was already a thread i will post the mailarcjive link for
reference here:
http://www.mail-archive.com/opensim-users@.../msg00332.html

And here the link to the osgrid console commands:
http://opensimulator.org/wiki/Console_Commands

If somebody wants to follow answer me here in the list or keep an eye on the
osgrid thread i
mentioned before (where i post this info as well) .. If more green people
cant get the trees
To grow i file a MANTIS ..

best regards and (hopefully) happy planting for a greener inworld ..

Wordfromthe Wise

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Save the Trees !!?

Master_Mirage
Last i tryed it was in rev .68+ and worked ok, just so happens i need to do it again with .69 rc2 so i can see if its broken somehow. One thing its allways been is picky about Cap's (case sensitive) and dident use to say anything when it dident understand the command. It also tends to at 1st not seem to work but after waiting awhile thay start todo there thing. Anyway i need some kelp for some newly added regions. I have used it many times in the past so ill know fairly quickly if its become borked somehow in .69+ rev's.



Our New Web Page
Http://www.TritonGrid.com
Reply | Threaded
Open this post in threaded view
|

Crash when creating outfit

j_jamesk
In reply to this post by Master_Mirage

Just wondering if anyone else gets the following error, when I right click
on my avatar and choose "appearance" and I use the make outfit option my
client (linden one) freezes then crashed and I see the following in the
opensim console window:


14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
66c41e39-38f9-f75a-024e-585989bfaba9
14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
77c41e39-38f9-f75a-024e-585989bfabc9
14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
d342e6c1-b9d2-11dc-95ff-0800200c9a66
14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
77c41e39-38f9-f75a-0000-585989bf0000
14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
77c41e39-38f9-f75a-0000-5859892f1111

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Crash when creating outfit

Robert L martin
On Sat, Jul 31, 2010 at 9:59 AM, j_jamesk <[hidden email]> wrote:
>
> Just wondering if anyone else gets the following error, when I right click
> on my avatar and choose "appearance" and I use the make outfit option my
> client (linden one) freezes then crashed and I see the following in the
> opensim console window:
>
just as a point of reference exactly which Linden viewer are you using
since there are about a dozen different linden viewers "in the wild"??
(lets see we have 1.22 1.23  2.0 2.1 and then we have Snowglobe 1.23
1.4 2.0 2.1)

--
Robert L Martin
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Crash when creating outfit

j_jamesk

The client is "Second Life 1.23.5 (136262) Oct 14 2009 12:08:26"

I believe I have narrowed the issue down to the default shape, skin, eyes
and hair; it seems that if you are wearing any of the defaults it fails to
make a copy of them into an "outfit" folder when you try to use the "make
outfit" in the appearance menu.

As a test I created a new skin, new shape and new eyes but left the default
hair and the client still crashed but there where less errors in the
console.

Comparing the last errors to the second crash, the following three items
where listed again,

15:26:00 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
d342e6c1-b9d2-11dc-95ff-0800200c9a66

15:26:00 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
77c41e39-38f9-f75a-0000-585989bf0000

15:26:00 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
77c41e39-38f9-f75a-0000-5859892f1111

Now I guess it's a case of finding where these items are in the database
(under what table) and to have a look at them.



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Robert Martin
Sent: 31 July 2010 15:20
To: opensim-users
Subject: Re: [Opensim-users] Crash when creating outfit

On Sat, Jul 31, 2010 at 9:59 AM, j_jamesk <[hidden email]> wrote:
>
> Just wondering if anyone else gets the following error, when I right click
> on my avatar and choose "appearance" and I use the make outfit option my
> client (linden one) freezes then crashed and I see the following in the
> opensim console window:
>
just as a point of reference exactly which Linden viewer are you using
since there are about a dozen different linden viewers "in the wild"??
(lets see we have 1.22 1.23  2.0 2.1 and then we have Snowglobe 1.23
1.4 2.0 2.1)

--
Robert L Martin
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Crash when creating outfit

Adric R
In reply to this post by j_jamesk
We've been following this crash in Imprudence for a while, and it's definitely OpenSim-specific. Last we checked, we weren't able to repro it on Wright Plaza, though. Was there a fix for this that was pushed then reverted?

-- McCabe Maxsted

http://imprudenceviewer.org

On Sat, Jul 31, 2010 at 6:59 AM, j_jamesk <[hidden email]> wrote:

Just wondering if anyone else gets the following error, when I right click
on my avatar and choose "appearance" and I use the make outfit option my
client (linden one) freezes then crashed and I see the following in the
opensim console window:


14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
66c41e39-38f9-f75a-024e-585989bfaba9
14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
77c41e39-38f9-f75a-024e-585989bfabc9
14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
d342e6c1-b9d2-11dc-95ff-0800200c9a66
14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
77c41e39-38f9-f75a-0000-585989bf0000
14:55:08 - [LOCAL INVENTORY SERVICES CONNECTOR]: Could not find item with id
77c41e39-38f9-f75a-0000-5859892f1111

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users



--
"Work is love made visible." — Kahlil Gibran

"We will not walk in fear, one of another. We will not be driven by fear into an age of unreason if we dig deep in our history and doctrine and remember that we are not descended from fearful men, not from men who feared to write, to speak, to associate and to defend causes which were for the moment unpopular. We can deny our heritage and our history, but we cannot escape responsibility for the result. There is no way for a citizen of the Republic to abdicate his responsibility." -- Edward R. Murrow, March 9, 1954

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Crash when creating outfit

Robert L martin
Its a bit of a hack but could this be solved by simply including a
complete set of assets in the default inventory (heck if we really
wanted to get fancy we could do both a male and female set)?

Deep sea Code fishing could be done after we solve the surface problem.
--
Robert L Martin
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users