perfSONAR User Q&A and Other Discussion

[Mike Robbert <>]

I did a little more research since my message yesterday. I found that the reason my services weren’t starting is due to SELinux. I’ve disabled that for now and will dig into that issue later. More to the point of the issue that I’m really trying to solve I did find the source of the plpythonu error. It is a procedural language extension that is configured to get loaded from the backup file that came from CentOS 7. Since that extension isn’t available in EL 8 or 9 it appears that an import from that backup file will always fail on the new OS. The backup file also included plpython3u which is the new version, so I commented out the old version and manually imported my database. Unfortunately, after doing that I still have none of my previously configured tests in the dashboard and therefore no old graph data.

Am I misunderstanding what the migrate scripts are supposed to do, or did I miss something when I manually imported the database? Has anybody been able to do a migration of tests and data from CentOS 7 to EL 8 or 9?

 

Mike Robbert

Cyberinfrastructure Specialist, Cyberinfrastructure and Advanced Research Computing

Information and Technology Solutions (ITS)

303-273-3786 |   

 

On 5/14/24, 11:47, "" <> wrote:

 

I have a couple of standalone (no mesh) perfSONAR Toolkit nodes that have been running CentOS 7 and I would like to upgrade them to Rocky 9. I found documentation for the move from CentOS 6 to 7 on some old perfSONAR 4 documentation pages (https://docs.perfsonar.net/release_candidates/4.0rc2/install_migrate_centos7.html). It looks like those scripts changed names in the current release of perfSONAR, but they are still there just not documented anywhere I can find. I made a backup of one of my servers and did a fresh install of Rocky 9.4 and got the perfSONAR toolkit installed on the new install, but now the restore operation is failing to run and has caused many of the perfSONAR services to fail. Here are the errors that I’m seeing when doing the restore:

 

===========================================

Restoring pScheduler from backup:

  Unpacking backup... Done.

Warning: The unit file, source configuration file or drop-ins of httpd.service changed on disk. Run 'systemctl daemon-reload' to reload units.

  Restoring configuration... Done.

  Restoring database...

 

Database restore failed:

set_config

------------

 

(1 row)

 

set_config

------------

 

(1 row)

 

ERROR:  could not open extension control file "/usr/share/pgsql/extension/plpythonu.control": No such file or directory

 

Restoring prior database... Done.

Job for pscheduler-ticker.service failed because the control process exited with error code.

See "systemctl status pscheduler-ticker.service" and "journalctl -xeu pscheduler-ticker.service" for details.

Unable to restore pScheduler configuration

===========================================

 

Has anybody seen this before or know where I can look to attempt to fix it?

I do see that plpythonu.control does not exist, but that it was replaced with plpython3u.control in Rocky9, but so far I haven’t been able to figure out where that is getting called/referenced and probably wouldn’t know how to fix it if I found it.

 

Thanks in advance for any help you can provide.

 

Mike Robbert

Cyberinfrastructure Specialist, Cyberinfrastructure and Advanced Research Computing

Information and Technology Solutions (ITS)

303-273-3786 |   

Attachment: smime.p7s
Description: S/MIME cryptographic signature