Ticket #265 (closed problem: fixed)

Opened 5 months ago

Last modified 4 days ago

Set up vso02 as a backup to vso03 at NSO

Reported by: niles Owned by: niles
Priority: highest Milestone:
Component: NSO Servers Version:
Severity: blocker Keywords:


The machine vso02.nispdc.nso.edu needs to be set up as a backup to vso03.nispdc.nso.edu at NSO. Hopefully this will allow vso03 enough downtime that it can move from SuSE to CentOS.

vso02 (which is the old NetDRMS machine from Tucson) has been racked and the patitions have been mounted, although not permanently.

Change History

comment:1 Changed 5 months ago by alisdair

  • Component changed from (unfiled) to NSO Servers

comment:2 Changed 5 months ago by niles

Actively working on this as of March 16. I have the RAIDs re-done VERY conservatively as the disks in them are old. Oracle is installed and the perl DBD::Oracle module is installed on a per-user basis. The Oracle database is starting to get updates.

I have to copy mysql over (it's fighting me) for the vso_catalogs database. I'm realizing that the way I've backed up the mysql database is not good.

After this, I get the perl going and then this can be a backup VSO node. Still have to get CVS and some other stuff across, too.

comment:3 Changed 4 months ago by alisdair

  • Owner changed from Niles to niles
  • Status changed from new to assigned

comment:4 Changed 3 months ago by niles

vso02.nispdc.nso.edu has an odd... feature... in that when it is rebooted after an upgrade, it takes *ages* for it to come back up. I leave it for about an hour. When it does come back, 'uptime' reports that it was up for that time, but it did not seem to have network access (I can't even ping it).

The console goes into some weird graphical blank mode when it does this. I can't tell what it's doing. Also when I can log in again I go to restart Oracle and I su to the oracle user and cat a README file in $HOME and it takes about a minute to do that the first time. Subsequent attempts are fine.

All of which is probably OK for an old dev machine, which is what this is. But it's worth noting.

comment:5 Changed 3 months ago by niles

vso02 seems to take ages to boot. Looking at it a bit this morning with Will Zajac, our new IT person. Very roughly, Will replaces David Edmeades. Booted Ubunutu off USB and the hardware seems OK at first glance from that platform. I'm setting Will up with an account to see what we can see...

comment:6 Changed 2 months ago by niles

Spent a while on this yesterday. It looks like the dbus service is not starting, which is disturbing. I'm going to look into it with Will.

comment:7 Changed 7 weeks ago by niles

It looks like vso02.nispdc.nso.edu is not stable enough to swing into use as a production machine. This stuffs up the plan to use it as a swing space while we get vso03.nispdc.nso.edu onto CentOS intead of SuSE. Also it could well be that we want to update the NSO data provider to use mysql instead of Oracle and make other changes. It could be that the netdrms machines could handle that load. Alisdair and I are looking at it.

comment:8 Changed 4 weeks ago by niles

This has taken a significantly different direction. Now looking into a re-write of the NSO data provider. Looking into what database to use (The DKI ST team uses postgres, and I'm now leaning that way) as well as what language/framework to use. Ed has a prototype system running essentially in python (under inline perl) and "Flask". I tried DJango but I'm still a bit puzzled as to how the pieces might fit together. Ed is likely to have a demo going soon which may well answer a lot of my questions. Also intrigued by the "handlebars" javaScript system that Jacob is using.

I'm going to try to get a "Flask" demo going out of the textbook, just so I can at least speak semi coherently about it at the next telecon.

I have a prototype "spider" to update a database with NSO data going. It's in perl but I don't see that as screamingly inappropriate for now.

comment:9 Changed 4 days ago by niles

Closing ticket as it is no longer what we want to do and it worked out to be too general anyway.

comment:10 Changed 4 days ago by niles

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.