Hi Kurro,
if the production stores data that needs to be maintained in the DB, you need to do something more complex (like mapping the data globals in the new NS to the old DB.

If not the safest way to test and also migrate everything is what you are proposing:

  • make a backup of the original DB (freeze/thaw or the iris utility from management portal, restore to different location and keep an eye on NOT SETTING SWITCH 10 during restore https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls... online backup)
  • create a new NS copying from the old one
  • do the mapping accordingly
  • import the upgraded code in the new NS
  • disable all the producion pieces (BO / BP / BS) on the new production
  • disable the production part (brands) that needs to be migrated on the old version
  • enable them on the new version

If something on the new production goes bad, you can easily enable the disabled pieces on the old version, and disable them on the new one.

Pietro

Hi,
may be that you are connecting to the webserver port and not the superserver one?

Can you post an "iris list"?

You can also include the connection in a try/catch and check on iris in application error logs and audit database (the audit db probably is the one that you need to check first).

you can have a look at a script that i've made that basically implements a remote cli to iris

https://github.com/m0nt0/riris/blob/main/src/riris

i think that zauth will conflict with ldap integrated, but before switching off zauth, make sure that ldap works as expected using the "test ldap authentication" on the previous screen.

What i see from your screen is that you may have errors in the "hostname" and "search username dn".

Hostname should be the ip or fqdn of your AD domain servers (start with one and then add all the other).

Search username has to be specified in LDAPish way so something like
cn=ensemble Service,dc=osumc,dc=edu

never tried but worked with a lot of copy between versions and architectures (think that this isn't different).

The first error is from the restore, you are trying to restore a db on an existing one with different block size (8k vs 16k may be). Try to restore to a new database and this will be solved.

The other problem that you are facingis that replacing the mgr will result in a broken instance.
With the restore and also by copying the databases (more or less is the same thing), I would NEVER restore the default databases :

IRISSYS
IRISLIB
IRISLOCALDATA <-- probably could be replaced
IRISAUDIT <-- probably could be replaced
ENSLIB
HSCUSTOM
HSLIB
HSSYS

I'd say that if you can shut down both instances you can simply copy the iris.dat files in place from windows to container. This way you won't lose time in doing backup / restore

Keep in mind that every configuration done needs to be synced on the container (users, privileges, web applications, roles, namespaces,....).

Hi,
you could configure sudo like

irisusr ALL = NOPASSWD: /usr/bin/systemctl stop httpd.service

where irisusr is the user that runs iris.

For the other server you could do the same thing and setup ssh to authenticate via keys

On source server:
su - irisusr
ssh-copy-id this_is_the_other_web_server


but the real question is: why do you want to stop httpd?

You could configure webgateway to have the other server as a failover.

configure connection to server2
setup application to be server1 primary, server2 backup

yeah, i've read that and saw this in a lot of other SQL DB, but when it comes to reality with a large amount of insert/delete made to the table the index is corrupted and there's the need to rebuild it like once a week.

Have you got any experiece like this? I need to create an index and use it on a table that will costantly have insert and delete (transactional data, a list/queue of transactions that needs to be processed)

Thanks

Hi, to examine and kill a job i'll go via terminal in iris session, zn to %SYS and execute ^JOBEXAM that is a sort of "top" for linux.

in the process list you can push (or keep pushed) spacebar to update the screen and keep an eye on the column "globals" and "lines", the ones that will grow really fast are probably the jobs that you are looking for.

Using "n" and "p" you can go to "Next" or "Previous" page.

When you fins the process that in your opinion is the one that needs to be killed you can examine what it's doing pushing "E" to "Examine" and give the job number (the first column). Also in this case pressing spacebar will update the screen.

When you are sure that you want to kill that process proceed with "t" to "Terminate" the job followed by the number.

Doing so, you can easily find all the jobs that needs to be killed