Verification of Installation, Back- Up and Clean Up Steps necessary for Successful install of v1.8 #196
Comments
|
I would make number 1 "back up database". For the others, I'll ask @coderReview to confirm. |
|
@cflottorp Since step 4 will delete the database, the migration step (1) won't do any good. If you want I can remove the database removal from the v2 script. I don't know what is the script in step 2. In my opinion, if you want to keep the data for the next version, you will need to: 1- Run the database migration Otherwise you will need to: 1- Run the 0100_fit_v2 script |
|
The script in step 2 was to clean up the ISS FIT database to remove duplication in the database. With the first recommendation to run the migration, 0100_fit_v2 script , will that include cleaning up the database to remove the duplicates? |
|
@coderReview we need to push to resolve this as soon as possible - please confirm. |
|
@cflottorp can you confirm if you want to keep the current data? From the other issue I understood you would like to start fresh. |
|
With the V1 and v2 scripts there is no need to run the clean up script in step 2 that was received previously? This was a script to remove duplicates in the database. https://drive.google.com/file/d/0B3nmbMgH4_oxWVV6bFdVZkRGWmM/view |
|
We will be doing a fresh re-load, so we should only need to be running the 0100_fit_v2 script. Then we will use Admin Tool to upload a Food CSV file and keep the checkbox "mark all food as removed" checked and also a User Data CSV file for user log in. Correct? |
|
Correct. You may just want to make a backup of the existing data for historical reason. I've sent the command on how to do that some time ago. Do you need me to send again? @rsial2 since the old data won't be kept the script is good to go for testing. |
|
We need @szwart to confirm if the old data is needed or not. |
|
Yes, we use the "pg_dump -h $' IP address' -p xxxxx -U pl_fit_db -W -Fc -f pl_fit.bak pl_fit" |
|
We are good with a total wipe and reload. We get reports down every week so we have all of the historical data we need. |
|
I attempted the latest installation instructions provided by Cheryl and they were no joy. I started with LS1 loaded with the FIT version installed in the LS1 Fajita SP. I then ran the The first error was bash refused to run the script because it's a Windows style file format. I converted the file to Unix file format and proceeded. The next error was a series of errors related to one topic and that is that multiple commands fail due to a missing directory structure. These three lines throughout the script have non zero exit code: The problem comes from a combination of these two variables definitions and the FIT app zip file (
The zip file no longer encodes the directory name " I do not have a suggested fix for these issues. That's what I have to report at this time. I'm fairly certain the FIT installer made it about 40 % through the installation process before exiting out with these errors. No other errors to report for this first part of the script ( |
|
@coderReview please treat this as high priority :) |
|
@rsial2 will look into this. But just to remember that the v2 of the script must be applied to a system that had v1 of the script already applied. Thanks |
|
@briandmartin can you confirm that the above script was run first? |
|
FIT was installed on LS1 by the Fajita Service Pack and this SP was deploy On-orbit ~May 2016. I don't have the SP with me now but I think the installer filename was |
|
Brian,
|
|
I'm not sure I understand your question, Cheryl. Let me post directory listings of what I installed (both in Fajita SP and yesterday's v. 1.8 failed installation attempt). |
|
Just to confirm folks, the V1 script must be run first, followed by V2. If the V1 script fails, please send the errors. If it passes, please continue to the V2 script. If V2 fails, please send the errors. Thanks! |
|
I had sent Cheryl the V1 deploy errors previously. I will look for that Email and post the errors to this thread. |
|
Awesome, thanks Brian! |
|
Directory listing of installation files for FIT version installed by Fajita Service Pack (Released to Operations May 2016, deployed On-orbit June 2016): ssc_system/trunk/linux/chroot_os/os_build/build_scripts_ls1/service_pack/fajita$ find . -type f -exec md5sum {} ; FIT v. 1.8 installation files directory listing: ├── kimchi 418d58d280fdffd189b8bbe1b4eee76e ./kimchi/build_scripts/0100_fit_v2 Also there is the 0100_fit_v1 script. Per the direction I was told, this was not installed yesterday. It's MD5 checksum is 5c83a236277be7396bed0a444d3ee213. There was a previous installation attempt of Fajita + V1 + V2. I look for the error report from that attempt and post the info. |
|
Here's the Fajita SP + V1 + V2 errors from the failed attempt on 05/26/2017: Copy the required installation order of Fajita FIT, 0100_fit_v1 and then 0100_fitv2. I tested that install order and the 0100_fit_v1 script is failing on the copy command in this series of three UUID OSSP install commands:
The error is: |
|
@coderReview please review and provide feedback. |
|
@rsial2 the error is at line 202 of the 0100_fit_v1 script. It looks like the database has already been created before the script is run. I created V1 for the enchilada image. And used the same image for the V2. Is it possible to share this new image with me? |
|
@cflottorp & @briandmartin please confirm. |
|
Brain - is it possible to send a copy of image of via LFT? |
|
Sending a newer LS1 load presents hurdles with export compliance issues. Also, the issue will arise again with future FIT updates. Because of these reasons we are going to integrate FIT on to its own VM that will be run on one of our On-orbit hypervisors. The VM will run the 64-bit version of Debian Jessie. Though the VM will be only for FIT, it will still be built in a secure manner as far as permissions go and only opening up firewall rules that are necessary. We'll begin building the base VM now, send it to you when it's ready so you can install FIT and update your installation script. We'll be using the stable version of Debian packages available in the Jessie repo. I don't have all the version numbers yet since we're just starting the VM build now but the Jessie version is 8.9 and the Postgresql version is 9.4+165+deb8u2. For Node.JS we'll want to use a stable version compatible with Jessie (I don't know if there's a Debian package for that). For LS1, the SSC team will build a deactivation script for LS1 that stops FIT and points DNS to the new FIT VM. The time estimate is a couple of weeks for providing the FIT team with the baseline FIT VM. |
|
Sounds good, thanks. |
|
@rsial2 can we create a new VM in Amazon? I can start finding out what packages should we use and migrate the current web system to this new VM. |
|
I think we should wait for @briandmartin to get the VM setup first. |
|
@RSIAL @codereview OK thank you for your flexibility. I'll give you an update when we have the VM ready for your use and the Export Compliance is approved. |
|
sounds good, thanks @briandmartin |
|
@coderReview I sent you the initial FIT VM and documentation today so you can use it for updating the FIT application/installer. There should be an email inviting you to join the NASA NOMAD large file transfer service (sent to the email address pvmagacho@gmail.com). Then a second link to download the VM and documentation. |
|
@briandmartin, confirming receipt of the VM. We will start working on the updates shortly. |
|
@rsial2 downloaded the data. Started to work creating the new scripts |
|
Awesome, thanks Paulo. |
|
@briandmartin can you give me a hand on how to connect using ssh to the VM? It's seems the ssh configuration is not default one. |
|
The primary IP address of the FIT VM is 192.168.65.102. Assign a NIC on your dev machine with an IP address on the 192.168.65.x subnet. Any number for x will work fine except for 102 since that address is in use by the FIT VM. Then you should have SSH access to the FIT VM and can SSH and login to the sscadmin account. Let me know if that does not work and then we can troubleshoot the issue. |
|
@briandmartin had to run |
|
OK great. Let me know if you have more questions. |
|
@briandmartin have you changed in the new VM the authentication method from SASL to LDAP? |
|
@rsial2 I have the script ready but I had to remove the site authentication because it's not using SASL anymore. |
|
@briandmartin can you confirm if that's ok? Once you do, we'll send the script over. |
|
Hi @briandmartin and @cflottorp, the new script is ready. The following MUST be done manually before running the script:
The site authentication has been removed because SASL is not being used as authentication method anymore. To download the new script, please click here: https://drive.google.com/file/d/0B3nmbMgH4_oxOXdFNTdEUlJCMjQ/view?usp=sharing |
No, I think LDAP is only scarred in for future use. For now, we still want to use Apache basic auth over SASL. I'll double check LDAP is still planned for future use. @coderReview |
|
@rsial2
Copy thanks. I've downloaded the ZIP file from Google Drive and will evaluate the install on the FIT VM. |
|
Hi @briandmartin & @cflottorp, how did this go? |
|
@RSIAL we have not started the evaluation due to development on other projects. We estimate early the week of Oct 16th we'll be able to evaluate the latest FIT delivery. |
|
Hey @briandmartin and @cflottorp, just checking in on this. Please let us know. CC @nasarader and @szwart |
|
@rsial2 and @cflottorp, we expect to do the load developer evaluation tomorrow, Wed 10/25. Getting the Kimchi Delta Service Pack ready for CM has been holding this activity up but we expect to complete that CM activity today to be freed up to do this evaluation. |
Need to confirm the order for the installation, back up of the existing pl_fit-db and clean up of database using the various scripts. Due to the various scripts that have been delivered, the order of the recommended deployment needs to be verified. Please confirm the following order or update as needed for a "clean", rebuild of the ISS FIT for version 1.8.
The text was updated successfully, but these errors were encountered: