Hi - We only support Artifactory (or syntactically similar). If you need to upload to another repository you will need to customize the upload script yourself. Make sure your repo is compliant with how microk8s and IFS Cloud downloads artifacts as well.
You should not change individual pod’s memory size - that is form a support perspective hardcoded. If you need more resources you start a second pod with the replicas parameter
Be aware that if you lower memory size (using scale) in a test or dev environment it might not be possible to test production size reports or connect messages.There is no single answer on how much memory a pods will use when it is scaled down.the formula is is:memory= minMem + addMem*(scale/100)The minMem and addMem is set per pod - minMem is what is required to get the pod running without and load/request sent to it. By adding addMem it becomes production grade. Scale can add a degree of the addMem...if you know how you will find these in the values.yaml in each subchart of the IFS Cloud helm chart.
Deleting is the mother of all housekeeping! :)If you need the data for historical reports move it to a data warehouse.Don’t try to join huge tables of old data in the IFS Cloud DB.There is a data archive concept in IFS Cloud to move/delete old data:https://docs.ifs.com/techdocs/23r2/030_administration/050_data_management/020_data_archiving/IFS Cloud is a OLTP db not a data warehouse - you should delete or move old transactional data.
Read about it here:https://docs.ifs.com/techdocs/23r2/070_remote_deploy/010_installing_fresh_system/030_preparing_server/54_log_monitoring/There are no preconfigured dashboards that i know of… it might come one day! :)The last 25Mb of the log is also available in the ifsapp-proxy stdout/log.> kubectl logs svc/ifsapp-proxyThe ingress controlle will always have the full log (you probably don’t need the "ifsappproxy.accessLogEnabled" as you can view the > kubectl -n ifs-ingress logs svc/ingress-ingress-nginx-controllerOr view the more persisted ingress controller logs through Kibana GUI.
I think all this might be technicalities on how BuildPlace changes configuration… The Build_home do not have a dependecy to where the build_home is deployed.But if Buildplace changes their build_home that is the one you should use to install. The Build_home in BuildPlace is always the master.
Hi - Yes, it should work - you specify the “LinuxUserName” in main_config.json
It is possible to setup Apps10 and IFS Cloud with Oracle TCPS connection. Both sides need to be configured to use certificate on the TCPS connection. I.e. Both Oracle listener and the client jdbcURL need to point to the certificate (wallet). Someone followed this once and got it working.https://docs.oracle.com/en/cloud/paas/data-safe/admds/create-wallet-or-certificates-tls-connection.html#GUID-87A6335A-E403-4007-9C2A-A07BA25AE064
No - Most of IFS business logic is written in Oracle PL/SQL. There are other databases that are almost compliant with Oracle PL/SQL, but the difference is still to big. IFS Cloud is stuck with Oracle in the foreseeable future.
Just to be sure here the global.scale parameter is not set to a lower value than default (100) ?If so increase to 100Dividing the load on more pods will lower the memory requirements on the pods.If ifsapp-connect and ifsapp-odata craches due to out of memory even on single requests, then there is probably a arcitectural problem on your side in how big messages are sent/recieved. Try splitting them in smaller chunks.
The intention is to increase replicas on the pod you want to scale up.e.g in ifscloud-values.yamlifsappodata: replicas: 2 /H
Not sure you understand how big that list will be :)This is not what you asked for, but this is how it works:https://docs.ifs.com/techdocs/23r2/070_remote_deploy/040_upgrading_system/040_deploying_upgrade/040_clean_drop_scripts/if you search for *cl.sql and *dr.sql from the top of the database folder in a build_home You will get all old objects no longer required for your version of IFS Cloud.
Yes - we have seen this.The root cause is that something (other than IFS) add cookies to the requests sent to IFS.You can record a HAR file in you browser when the error happens. There you can see which cookies are large. Try to figure out which ones comes from non IFS origin (e.g loadbalancer cookies and network identity cookies)IFS cloud in later SU’s later than 6months or so should be able to handle 16k of headers older version only handle 8k which is enough to handle the IFS cookies.We have also seen that if the Remote infrastucture is old, then the patch to increase from 8k to 16k don’t get fully applied. Helm version on management server need to be > ~3.10look in the ingress config:kubectl get ingress ifs-sticky-ingress -o yaml -n <namespace>you should find: nginx.ingress.kubernetes.io/server-snippet: | large_client_header_buffers 4 16k;
I don’t remember the details around “PL/SQL Access Provider configuration test” - it might have been showing the wrong status at some point… not sure. Only thing i know is that the PL/SQL Access Provider is not using the wallet since around UPD7.
Just as information - from Apps10 ~UPD7 the wallet is not used by the plsqlap. It uses Oracle AQ to send messages to the MWS. I hope there is very few customer installations still on such low Apps10 UPD that the wallet is used… e.g. I guess Oracle Weblogic has applied a ton of security patches since UPD7. Also a lot of IFS MWS bugfixes has been created from IFS for the MWS Linux handling the last year’s. At least one IFS component (that i know of) requires a later UPD to even compile properly on Oracle 19.
I think whenever possible use the HTTP API - spending time doing new sql integrations is not future proof. Even if ifsinfo might work for now. Eventually these integrations will most likely be deprecated.
The solutionset should only be modified when a new custom component is created .. typically CMOD.This is the only change that should be done as part of a delivery. And this would only be done as part of the onboarding. Normally i think customers have all their custom additions in the CMOD component.Any other change of the solutionset e.g. enabling RnD components is forbidden. This need to be done by ordering the component from IFS and the refetch the solutionset from Thor. All components will the be rebuilt to reflect the new solutionset.
In-Memory Acceleration is not used by many customers (if any), so if the customer is not super experienced in using in-memory option, i would suggest not to use it.Some standard settings are there to be activated in Solution Manager. If other are required, then these need to be added as customization .ins files. (find the RnD ones to use as templates)
Have you tried a complete reinstall 😁If e.g. a cert expires i have not found a way of renewing them… !?I guess the same goes for “corrupted” certs.You better wipe out any traces of the old mk8s before reinstalling on a server.sudo snap remove --purge microk8ssudo snap remove --purge kubectlsudo rm -R /root/snap/microk8ssudo rm -R /home/ifs/microk8ssudo rm -R /home/ifs/snapsudo rm -R /home/ifs/remote-scriptssudo rm /home/ifs/install-k8s.shsudo reboot
I don’t work with this at all, but isn’t the TAR scripts used for this?https://docs.ifs.com/techdocs/ale/020_lifecycle/050_working_with_environments/030_test_data/They can be run towards any env manually? But are automatically run in dev envs?
My guess as Apps9 is out of support now for quite a while and has not done any updates for a long time, is that a Windows update has updated the .Net runtime libraries. Here? C:\Windows\Microsoft.NET\FrameworkWhat you need to do is to try to force the old Aps9 access provider to use equally old .Net frameworks… Also tell the customer it is dangerous to run unsupported products… :)
Hi - The java used by IFS tools use the Java that don’t require licensing.The Java that requires licensing is only used by the Weblogic part of MWS and is paid as part of the OEM license of Weblogic.
Have you tried from a CMD - where there are no configurable privilege's that can be affecting. I personally never use PS… unless a ps1 script requires it.Just because main.ps1 need to run in a PS doesn’t mean the installer.cmd need to.
This is HTTP config - there is no dependency to IFS here, so we don’t have any recommendations.RnD updates the ciphers when we think they are too old. But setting a general set of ciphers is harder than setting one/two strong ciphers the way an individual customer can given the knowledge of the clients that need to connect. It is pretty complicated to get a good set of ciphers that all get A on the https://www.ssllabs.com/ test but still covers older browsers and mobile devices…
Hi,Both Apps10 and IFS Cloud have configurable Ciphers to meet specific customer needs.https://docs.ifs.com/techdocs/23r1/070_remote_deploy/010_installing_fresh_system/200_installing_ifs_cloud/035_ifs_cloud_ifsinstaller/030_installation_parameters/#general_parametershttps://docs.ifs.com/techdocs/Foundation1/020_installation/020_installing_fresh_system/040_installing_ifs_applications/030_deploy_middle_tier/hidden_itd/040_webserver_configuration.htm?nobanner=true
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
