go to post Pietro Montorfano · Jan 31, 2024 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
go to post Pietro Montorfano · Jan 16, 2024 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
go to post Pietro Montorfano · Sep 9, 2023 no no for the testldap don't remove it. Test ldap will run the query as it will do on the login giving you the output of the search for debugging. May be how samacountname is written? On an AD installation i got it as "sAMAccountName"...
go to post Pietro Montorfano · Sep 7, 2023 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 : IRISSYSIRISLIBIRISLOCALDATA <-- probably could be replacedIRISAUDIT <-- probably could be replacedENSLIBHSCUSTOMHSLIBHSSYS 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,....).
go to post Pietro Montorfano · Sep 7, 2023 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 - irisusrssh-copy-id this_is_the_other_web_serverbut 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 server2setup application to be server1 primary, server2 backup
go to post Pietro Montorfano · Mar 6, 2023 unfortunately unless you got a very very high log set in the instance and a very long journal history you can't discover that. If you got the info you can find in the journal the global change, get the process info and search the log for them. But usually is something that you can spot in the near time or something that happens on a regular basis, something spot is really difficult to find in that way.
go to post Pietro Montorfano · Feb 28, 2023 Hi, never done that, always installed production under linux. Respecting the allocation size it will be good to match the same size so if you are using only 8k, it should be better to have 8k also on fs so 1 unit for db should also be 1 unit for fs and it won't be split in 2 fs operation. 8k should be fine because you can accept that if you are using a mixed db allocation size for 8k and 16k it will always be beneficial also for 16k chunks. On this argument always remember to align the partition and the fs dropping the first bytes as per ms best practice so that also the disk (if on a raid) could match the writes https://support.microsoft.com/en-us/topic/recommendations-and-guidelines...
go to post Pietro Montorfano · Feb 10, 2023 Hi,the error is quite generic and it basically says that you can't login but you don't know why. Check that the superserver port is the same used in studio, Check the license on the instance. If the everything is fine, fire up the management portal, go tosystem administration -> security -> auditing -> enable auditingand check that the auditing is enabled. After that go tosystem administration -> security -> auditing -> configure system eventsand check that%System/%Login/LoginFailureis enabled. If not click on "change status". Try to login again with studio and check the audit databasesystem administration -> security -> auditing -> view audit databaseand see what error comes up Pietro