Re: [Archivesspace_Users_Group] Database Migration Error on AS 2.6.0

[Blake Carver]

> In order to be sure, is there a way to migrate data manually to ensure that 
> schema matches and all the data gets migrated?

I'd say, probably not.

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Ludwig 
Possie 
Sent: Friday, May 14, 2021 2:10 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Database Migration Error on AS 2.6.0

Thank you for your recommendations.  I've imported the database from our 
production to  dev and changed the schema version as Megan had suggested, 
fortunately in this case it resolved the issue and allowed archivesspace to run 
as expected.  Our production environment is running on docker, but I doubt that 
would impact the schema version.  I completely understand what you're saying 
Blake and normally I would not want to mess with the schema version, however in 
this instance since the schema version seems to be completely off and not match 
any other version, it may be needed in order to get the DB in sync with the 
current version it should be on.  I'm crossing my fingers that moving forward 
it won't mess with things.  In order to be sure, is there a way to migrate data 
manually to ensure that schema matches and all the data gets migrated?

On Fri, May 14, 2021 at 10:50 AM Blake Carver 
mailto:blake.car...@lyrasis.org>> wrote:
I wouldn't recommend changing the schema_info, this can put you in a really bad 
place.

Your error:
""The schema info version should be 120 for ArchivesSpace version v2.6.0.  
However, your schema info version is set at 122"

Every release of ArchivesSpace has a  schema number . All recent releases have 
the  schema number  listed on the release notes. So the latest version 3.0 is  
147, and the previous release 2.8.1 is 138 and so on down the line. Those 
numbers are important and are set by the code. That's what the ArchivesSpace 
code looks at to know that the MySQL Database lines up with what it expects. 
Each version expects certain tables/rows/columns to be there and in a certain 
format. As ArchivesSpace starts each time it checks that shema_info number, and 
if it's wrong, it fails. So ArchivesSpace 3.0 starts up and says "Hey MySQL 
what ya got there?" and MySQL says "147" and ArchivesSpace says "Groovy, that's 
what I need to run" and then they high five and start getting down to business. 
If ArchivesSpace starts up and says "Hey MySQL, what ya got there?" and it says 
"122" and ArchivesSpace was expecting 120, ArchivesSpace says "That ain't 
right, I can't work with that" and starts telling you all about it in 
archivesspace.out.

So your version of ArchivesSpace is expecting schema_info to be 120 but it's 
actually 122, which is larger number and therefore a newer release.

Looking back at the old releases, schema_info on 2.7 is 126 and the release 
before that is 120 is 2.6.0, which means 122 is... I don't know what.

I'm not sure what to recommend here. From what I can see there is not any 
release that should have a schema version of 122, so I don't know how that got 
set like that.


From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Schanz, Megan mailto:schan...@msu.edu>>
Sent: Thursday, May 13, 2021 9:35 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Database Migration Error on AS 2.6.0

That should only happen when the setup-database script was run for a later 
version of ArchivesSpace. But if that isn't the case, you could try manually 
reverting the schema number in the database to see if that resolves your issue.

update schema_info set version = 120;

I've had to do that at one point in the past, but I can't recall what 
circumstances led to me having to do that.

- Megan

_

Megan Schanz
Application Developer & Systems Administrator
Michigan State University Libraries

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Ludwig Possie 
mailto:ludwigpos...@weber.edu>>
Sent: Wednesday, May 12, 2021 7:56 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Database Migration Error on AS 2.6.0

I'm in the process of moving our current version of Archivesspace 2.6.0 to a 
new server running Ubuntu 20.04.  I've installed Java 1.8, MySQL 8.0.25 and 
mysql connector 8.0.25 on the new server.

I successfully got Archivesspace 2.6.0 running on MySQL (New blank database) on 
the new server.  When I import our current production database and run the 
setup-database.sh script I get no err

Re: [Archivesspace_Users_Group] Call for participants to discuss the ASpace Digital Object module

[Hand, Sarit]

Happy Friday!

UPDATE: This group is FULL!  I am so excited with the response.

FYI-I discovered at least one person who signed up but for some reason their 
submission did not go through, so if that happened to you, I apologize, I do 
not know why, will have to blame the monkeys.

For the time being, I have closed the sign up but will post with a new generic 
one for future meetings on different topics. Thank you everyone who signed up, 
tried to or otherwise.

Have a great weekend!
Cheers

[cid:image007.png@01D748EC.1CB20730]

Sarit Hand
Digital Archivist
AP Corporate Archives

200 Liberty Street
New York, NY 10281
T 212.621.7035

sh...@ap.org
ap.org
[cid:image008.png@01D748EC.1CB20730]


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Hand, 
Sarit
Sent: Monday, May 10, 2021 4:52 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Call for participants to discuss the 
ASpace Digital Object module


[EXTERNAL]
Hello,

UPDATE:
The first meeting has been set for May 20th at 2:30 PM ET. If you are 
interested and have not signed up, there are still a couple more spots. If 
there is interest or more people than max, I will host additional meetings as 
needed. In the meantime, please use the survey link to add your name to the 
list.
https://www.surveymonkey.com/r/MRW9RGV

Thank you to those who have signed up and will be joining this conversation!

Regards,

[cid:image003.png@01D748EC.1CA2C4F0]

Sarit Hand
Digital Archivist
AP Corporate Archives
200 Liberty Street
New York, NY 10281
T 212.621.7035

sh...@ap.org
ap.org
[cid:image004.png@01D748EC.1CA2C4F0]


From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Hand, Sarit
Sent: Friday, April 30, 2021 11:58 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Call for participants to discuss the 
ASpace Digital Object module


[EXTERNAL]
Hi All,

Before we go into the weekend, I just wanted to let you know the survey is 
still open (see below).

Happy weekend!
Be well.
Cheers

[cid:image003.png@01D748EC.1CA2C4F0]

Sarit Hand
Digital Archivist
AP Corporate Archives
200 Liberty Street
New York, NY 10281
T 212.621.7035

sh...@ap.org
ap.org
[cid:image004.png@01D748EC.1CA2C4F0]


From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Hand, Sarit
Sent: Monday, April 26, 2021 7:46 PM
To: 'archivesspace_users_group@lyralists.lyrasis.org' 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Call for participants to discuss the 
ASpace Digital Object module


[EXTERNAL]
Hello,

I hope this finds everyone doing well.

I am looking for fellow ArchivesSpace users to join me in an informal, 
peer-to-peer discussion about using the Digital Object module for digital 
records in ASpace, both simple and complex. I will host this discussion via a 
Zoom meeting and schedule the date and time once I have a group assembled. I am 
limiting this to 15 people to allow for ease of conversing on Zoom.

**This is not a workshop, webinar, training, or a presentation of how-to. This 
is independent of Lyrasis and ArchivesSpace as well as my own company.

Please complete this survey 
https://www.surveymonkey.com/r/MRW9RGV

Re: [Archivesspace_Users_Group] 'Sign In' swap with SSO login

[Blake Carver]

You can probably just override that here:

https://github.com/archivesspace/archivesspace/blob/82c4603fe22bf0fd06043974478d4caf26e1c646/frontend/app/views/welcome/index.html.erb



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Ben 
Fisher 
Sent: Friday, May 14, 2021 11:15 AM
To: archivesspace_users_group@lyralists.lyrasis.org 

Subject: [Archivesspace_Users_Group] 'Sign In' swap with SSO login

Hello,

I'm in the process of implementing the Oauth plugin to comply with a recent 
security audit. The plugin itself is now configured and working correctly, but 
I would like to close the door to local sign-in, at least during normal 
circumstances.

Ideally, I would like to swap the 'Sign In' button target from local sign-in to 
the SSO link. Does anyone know how we could accomplish this? An acceptable 
alternative could be removing the Sign In button entirely, leaving only the SSO 
link. All suggestions are welcome.

Thank you,

--

Ben Fisher | IT Coordinator

University of Arkansas at Little Rock | Information Technology Services
501.916.3011 | 
btfish...@ualr.edu | 
ualr.edu/itservices

 
[https://docs.google.com/uc?export=download&id=0Bz9cuMeqg1TDZ3FCTmp0SGtoWHM&revid=0Bz9cuMeqg1TDTC82aDhXejYvWStpc2VrZWdwaWNsTmlheUQwPQ]

Reminder:  IT Services will never ask for your password over the phone or in an 
email. Always be suspicious of requests for personal information that comes via 
email, even from known contacts.  For more information or to report suspicious 
email, visit http://ualr.edu/itservices/security/

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Database Migration Error on AS 2.6.0

[Blake Carver]

I wouldn't recommend changing the schema_info, this can put you in a really bad 
place.

Your error:
""The schema info version should be 120 for ArchivesSpace version v2.6.0.  
However, your schema info version is set at 122"

Every release of ArchivesSpace has a  schema number . All recent releases have 
the  schema number  listed on the release notes. So the latest version 3.0 is  
147, and the previous release 2.8.1 is 138 and so on down the line. Those 
numbers are important and are set by the code. That's what the ArchivesSpace 
code looks at to know that the MySQL Database lines up with what it expects. 
Each version expects certain tables/rows/columns to be there and in a certain 
format. As ArchivesSpace starts each time it checks that shema_info number, and 
if it's wrong, it fails. So ArchivesSpace 3.0 starts up and says "Hey MySQL 
what ya got there?" and MySQL says "147" and ArchivesSpace says "Groovy, that's 
what I need to run" and then they high five and start getting down to business. 
If ArchivesSpace starts up and says "Hey MySQL, what ya got there?" and it says 
"122" and ArchivesSpace was expecting 120, ArchivesSpace says "That ain't 
right, I can't work with that" and starts telling you all about it in 
archivesspace.out.

So your version of ArchivesSpace is expecting schema_info to be 120 but it's 
actually 122, which is larger number and therefore a newer release.

Looking back at the old releases, schema_info on 2.7 is 126 and the release 
before that is 120 is 2.6.0, which means 122 is... I don't know what.

I'm not sure what to recommend here. From what I can see there is not any 
release that should have a schema version of 122, so I don't know how that got 
set like that.


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Schanz, 
Megan 
Sent: Thursday, May 13, 2021 9:35 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Database Migration Error on AS 2.6.0

That should only happen when the setup-database script was run for a later 
version of ArchivesSpace. But if that isn't the case, you could try manually 
reverting the schema number in the database to see if that resolves your issue.

update schema_info set version = 120;

I've had to do that at one point in the past, but I can't recall what 
circumstances led to me having to do that.

- Megan

_

Megan Schanz
Application Developer & Systems Administrator
Michigan State University Libraries

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Ludwig 
Possie 
Sent: Wednesday, May 12, 2021 7:56 PM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Database Migration Error on AS 2.6.0

I'm in the process of moving our current version of Archivesspace 2.6.0 to a 
new server running Ubuntu 20.04.  I've installed Java 1.8, MySQL 8.0.25 and 
mysql connector 8.0.25 on the new server.

I successfully got Archivesspace 2.6.0 running on MySQL (New blank database) on 
the new server.  When I import our current production database and run the 
setup-database.sh script I get no error and an 'All Done' message at the end.  
However when I attempt to run archivesspace.sh I get a Database Migration 
Error, with the following recommendation, "The schema info version should be 
120 for ArchivesSpace version v2.6.0.  However, your schema info version is set 
at 122
Please ensure your migrations have been run and completed by using the 
setup-database script."
I've ran the script various times but I keep getting the same results.  Has 
anyone experienced an issue like this?  Please advise.  Thank you.

--
Ludwig Possié
Systems Admin
Stewart Library
Weber State University
801-626-8093
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Database Migration Error on AS 2.6.0

[Ludwig Possie]

Thank you for your recommendations.  I've imported the database from our
production to  dev and changed the schema version as Megan had
suggested, fortunately in this case it resolved the issue and
allowed archivesspace to run as expected.  Our production environment is
running on docker, but I doubt that would impact the schema version.  I
completely understand what you're saying Blake and normally I would not
want to mess with the schema version, however in this instance since the
schema version seems to be completely off and not match any other version,
it may be needed in order to get the DB in sync with the current version it
should be on.  I'm crossing my fingers that moving forward it won't mess
with things.  In order to be sure, is there a way to migrate data manually
to ensure that schema matches and all the data gets migrated?

On Fri, May 14, 2021 at 10:50 AM Blake Carver 
wrote:

> I wouldn't recommend changing the schema_info, this can put you in a
> really bad place.
>
> Your error:
> ""The schema info version should be 120 for ArchivesSpace version
> v2.6.0.  However, your schema info version is set at 122"
>
> Every release of ArchivesSpace has a  schema number . All recent releases
> have the  schema number  listed on the release notes. So the latest
> version 3.0 is  147, and the previous release 2.8.1 is 138 and so on down
> the line. Those numbers are important and are set by the code. That's what
> the ArchivesSpace code looks at to know that the MySQL Database lines up
> with what it expects. Each version expects certain tables/rows/columns to
> be there and in a certain format. As ArchivesSpace starts each time it
> checks that shema_info number, and if it's wrong, it fails. So
> ArchivesSpace 3.0 starts up and says "Hey MySQL what ya got there?" and
> MySQL says "147" and ArchivesSpace says "Groovy, that's what I need to
> run" and then they high five and start getting down to business. If
> ArchivesSpace starts up and says "Hey MySQL, what ya got there?" and it
> says "122" and ArchivesSpace was expecting 120, ArchivesSpace says "That
> ain't right, I can't work with that" and starts telling you all about it in
> archivesspace.out.
>
> So your version of ArchivesSpace is expecting schema_info to be 120 but
> it's actually 122, which is larger number and therefore a newer release.
>
> Looking back at the old releases, schema_info on 2.7 is 126 and the
> release before that is 120 is 2.6.0, which means 122 is... I don't know
> what.
>
> I'm not sure what to recommend here. From what I can see there is not any
> release that should have a schema version of 122, so I don't know how that
> got set like that.
>
> --
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
> Schanz, Megan 
> *Sent:* Thursday, May 13, 2021 9:35 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Database Migration Error on AS
> 2.6.0
>
> That *should* only happen when the setup-database script was run for a
> later version of ArchivesSpace. But if that isn't the case, you could try
> manually reverting the schema number in the database to see if that
> resolves your issue.
>
> update schema_info set version = 120;
>
>
> I've had to do that at one point in the past, but I can't recall what
> circumstances led to me having to do that.
>
> - Megan
>
> _
>
> Megan Schanz
> Application Developer & Systems Administrator
> Michigan State University Libraries
> --
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
> Ludwig Possie 
> *Sent:* Wednesday, May 12, 2021 7:56 PM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] Database Migration Error on AS
> 2.6.0
>
> I'm in the process of moving our current version of Archivesspace 2.6.0 to
> a new server running Ubuntu 20.04.  I've installed Java 1.8, MySQL 8.0.25
> and mysql connector 8.0.25 on the new server.
>
> I successfully got Archivesspace 2.6.0 running on MySQL (New blank
> database) on the new server.  When I import our current production database
> and run the setup-database.sh script I get no error and an 'All Done'
> message at the end.  However when I attempt to run archivesspace.sh I get a
> Database Migration Error, with the following recommendation, "The schema
> info version should be 120 for ArchivesSpace version v2.6.0.  However, your
> schema info version is set at 122
> Please ensure your migrations have been run and completed by using the
> setup-database script."
> I've ran the script various times but I keep getting the same results.
> Has anyone experienced an issue like this?  Please advise.  Thank you.
>
> --
> Ludwig Poss

[Archivesspace_Users_Group] 'Sign In' swap with SSO login

[Ben Fisher]

Hello,

I'm in the process of implementing the Oauth plugin to comply with a recent
security audit. The plugin itself is now configured and working correctly,
but I would like to close the door to local sign-in, at least during normal
circumstances.

Ideally, I would like to swap the 'Sign In' button target from local
sign-in to the SSO link. Does anyone know how we could accomplish this? An
acceptable alternative could be removing the Sign In button entirely,
leaving only the SSO link. All suggestions are welcome.

Thank you,

-- 


*Ben Fisher | IT Coordinator*

University of Arkansas at Little Rock | Information Technology Services
501.916.3011 <%28501%29%20916-3011> | btfish...@ualr.edu | ualr.edu/it
services



Reminder:  IT Services will never ask for your password over the phone or
in an email. Always be suspicious of requests for personal information that
comes via email, even from known contacts.  For more information or to
report suspicious email, visit http://ualr.edu/itservices/security/
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group