Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 13:13

    ckm007 on develop

    modified dynamic field dml scri… Merge pull request #417 from dh… (compare)

  • 13:13
    ckm007 closed #417
  • 12:31

    AlokTechno on develop

    variable scope updated Merge branch 'develop' of https… rest method added and logger co… (compare)

  • 11:28
    neeharikatech opened #136
  • 10:38

    ckm007 on 1.1.5

    updated for 1.1.5 release Merge pull request #418 from ck… (compare)

  • 10:38
    ckm007 closed #418
  • 10:38
    ckm007 opened #418
  • 08:50
    dhanendra06 opened #417
  • 08:00

    ckm007 on master

    updated push trigger (compare)

  • 07:14
    lgtm-com[bot] commented #416
  • 07:12

    aranaravi on develop

    User to zone and center mapping… Merge pull request #416 from ar… (compare)

  • 07:12
    aranaravi closed #416
  • 06:54
    aranaravi opened #416
  • 04:23

    nayakrounak on master

    Added Bioextractor-Service Added heading Removed the error and 6 more (compare)

  • 04:23
    nayakrounak closed #110
  • 04:22

    nayakrounak on master

    Create Release-Notes-1.1.5.md … Merge pull request #111 from Ch… (compare)

  • 04:22
    nayakrounak closed #111
  • Apr 21 12:46
    lgtm-com[bot] commented #415
  • Apr 21 12:39

    Ajay1596 on develop

    MOSIP-11653 fixed two minor iss… Merge pull request #415 from ma… (compare)

  • Apr 21 12:39
    Ajay1596 closed #415
Uoc Nguyen
@uocnb

@almontasser unfortunately no, I did not managed to get rid of the invalid user error yet. Based on my investigation, it will need to manually create multiple file for masterdata upload including:

  • device
  • location
  • zone
  • user_detail
  • zone_user
  • registration_center

Depends on application, it will need to create new zone or use existing. I also observed that sample masterdata included in the mosip-common contain some invalid data which make some APIs not work as expect out of box.

Mahmoud Almontasser
@almontasser
@uocnb If you did not change the user details provided by mosip-infra, delete your .mosipkeys and db folders, and start the reg-client, login with username: 110127 password: Techno@123, after restart login with username: 110118 password: Techno@123
Uoc Nguyen
@uocnb
@almontasser yes, I often delete folders in the $HOME and reg-client to reset it, will try with that user next time.
Callum Mole
@callummole
My previous pre-reg ui automatic logout error was due to the pods not starting properly. Reinstalling with the Readiness probe field initialDelaySeconds set to larger values (e.g. 300) fixed this.
But I'm still having issues passing test/regproc/test_regproc.py. On the packet upload there is a 502 bad gateway error, despite nginx working and some other api calls working. Any suggestions for how to go about debugging this?
Callum Mole
@callummole
To be more specific, a POST request to http://dmzworker0.sb:30080/registrationprocesser/v1/packetreceiver/ causes a 502 error, but the a POST request to http://dmzworker0.sb:30080/registrationprocessor/v1/registrationstatus/ works fine. I wonder if there is a backend service that I'm unaware of that needs to be restarted after a reboot?
Uoc Nguyen
@uocnb
@callummole possibly caused by the server time is not correct. Some APIs required very small time different in the payload and server time. I have to deploy NTP server to all servers in order to keep them in sync with atomic clock.
Callum Mole
@callummole
@uocnb thanks so much for the suggestion. I'll check it out
Callum Mole
@callummole

@almontasser I'm encountering the same issue as you did earlier in the month, running the regclient version 1.1.3. I cannot login (110127;Techno@123) and the logs show:

2021-01-27T16:59:16Z - [io.mosip.registration.util.restclient.AuthTokenUtilService] - ERROR - AUTH_REFRESH_TOKEN_UTIL - REGISTRATION - REG - io.mosip.registration.exception.RegBaseCheckedException: REG-SDU-005 --> Auth token received from the authentication web-service is either null or empty

On the sandbox I can see my machine in the machine_master db (though the fields for sign_public_key and sign_key_index are empty). I added it by editing the master-machine_master.csv then using update_masterdb.sh.

How did you fix the issue?

Mahmoud Almontasser
@almontasser
@callummole you should fill sign_public_key and sign_key_index with the data public_key and key_index from .mosipkeys/readme.txt, because I inspected the code and it uses these two fields to find the machine. If this did not work for you, I have changed the code in syncdata-service, and uploaded my custom image to the server, If you want the changes I'll provide it for you.
Mahmoud Almontasser
@almontasser
In the file commons\kernel\kernel-syncdata-service\src\main\java\io\mosip\kernel\syncdata\service\impl\SyncAuthTokenServiceImpl.java I've modified the function validateRequestData as follows:
private Machine validateRequestData(byte[] header, byte[] payload, byte[] signature) {
        JWTParser jwtParser = new JWTParser();
        Header jwtheader = jwtParser.parseHeader(new String(header));

        if(Objects.nonNull(jwtheader.getKeyId())) {
            List<Machine> machines = machineRepository.findKeyIndexAndIsActive(jwtheader.getKeyId());

            if(Objects.isNull(machines) || machines.isEmpty())
                throw new RequestException(MasterDataErrorCode.MACHINE_NOT_FOUND.getErrorCode(),
                        MasterDataErrorCode.MACHINE_NOT_FOUND.getErrorMessage());

            return machines.get(0);

            // try {
            //     boolean verified = clientCryptoFacade.validateSignature(CryptoUtil.decodeBase64(machines.get(0).getSignPublicKey()),
            //             signature, payload, isTPMRequired);
            //     logger.info("validateRequestData verified : {}", verified);
            //     if(verified) {  return machines.get(0); }

            // } catch(ClientCryptoException ex) {
            //     logger.error("Failed to validate signature", ex);
            // }
        }
        throw new RequestException(SyncAuthErrorCode.INVALID_REQUEST.getErrorCode(),
                SyncAuthErrorCode.INVALID_REQUEST.getErrorMessage());
    }
and I've add the function to get machine by the public_key in the file commons\kernel\kernel-syncdata-service\src\main\java\io\mosip\kernel\syncdata\repository\MachineRepository.java as follows:
    @Query("From Machine m WHERE m.keyIndex = ?1 and (m.isDeleted is null or m.isDeleted =false) and m.isActive = true")
    List<Machine> findKeyIndexAndIsActive(String keyIndex);
Callum Mole
@callummole
@almontasser Thank you for your suggestions. I have done both (filled the sign_public_key and sign_key_index fields and also made the file edits). But still having the same error. I edited the files in mosip-infra/deployment/sandbox-v2/tmp/commons/.... Is this the right place to edit for the changes to work? You mentioned uploading a custom image to the server. Was that in addition to the file edits or was that as a method for getting the file edits incorporated into your sandbox?
Callum Mole
@callummole
My issue may also be not appropriately adding the machine to the master db. I can see it in machine_master, but earlier on in yours and @uocnb discussions there is mention about mapping the machine correctly. Does this mean that there are other databases I should be editing before my reg client application can get authenticated? Also, for the fields that were not specific to my machine (e.g. mspec_id, zone_code, rgcntr_id) I copied entries from the sample data found in the commons rep (e.g. using NTH from zone_code). Is this also what you did?
Mahmoud Almontasser
@almontasser
@callummole No, I cloned the commons repo, and modified it, and built the docker image, and uploaded it to docker hub, if you want to use my image:
almontasser/kernel-syncdata-service:1.1.3, edit the deployment of syncdata-service to use the modified image
Callum Mole
@callummole
Ah! Excellent. I'll try that.
Callum Mole
@callummole

@almontasser Using your image I get the following error in the logs for the syncdata-service pod when trying to login to the reg client. It's long but I've pasted enough to give you an idea of what is going on. Did you ever come across a similar error when getting your image working?

{@timestamp":"2021-01-28T15:33:46.882Z","@version":"1","message":"Failed to get auth tokens","logger_name":"io.mosip.kernel.syncdata.service.impl.SyncAuthTokenServiceImpl","thread_name":"http-nio-8089-exec-5","level":"ERROR","level_value":40000,"stack_trace":"java.nio.BufferUnderflowException: null\n\tat java.base/java.nio.Buffer.nextGetIndex(Buffer.java:642)\n\tat java.base/java.nio.HeapByteBuffer.get(HeapByteBuffer.java:165)\n\tat tss.InByteBuf.readByte(InByteBuf.java:38)\n\tat tss.InByteBuf.readInt(InByteBuf.java:59)\n\tat tss.InByteBuf.readArrayOfInts(InByteBuf.java:81)\n\tat tss.tpm.TPMT_PUBLIC.initFromTpm(TPMT_PUBLIC.java:102)\n\tat tss.tpm.TPMT_PUBLIC.fromTpm(TPMT_PUBLIC.java:131)\n\tat io.mosip.kernel.clientcrypto.service.impl.TPMClientCryptoServiceImpl.asymmetricEncrypt(TPMClientCryptoServiceImpl.java:199)\n\tat io.mosip.kernel.clientcrypto.service.impl.ClientCryptoFacade.encrypt(ClientCryptoFacade.java:106)\n\tat io.mosip.kernel.syncdata.service.impl.SyncAuthTokenServiceImpl.getAuthToken(SyncAuthTokenServiceImpl.java:119)\n\tat java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n\tat java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\n\tat java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tat java.base/java.lang.reflect.Method.invoke(Method.java:566)\n\tat org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:223)\n\tat org.springframework.cloud.context.scope.GenericScope$LockedScopedProxyFactoryBean.invoke(GenericScope.java:494)\n\tat org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185)\n\tat org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)\n\tat io.mosip.kernel.syncdata.service.impl.SyncAuthTokenServiceImpl$$EnhancerBySpringCGLIB$$2bd67aa2.getAuthToken(<generated>)\n\tat io.mosip.kernel.syncdata.controller.SyncAuthTokenController.getTokenWithUserIdPwd(SyncAuthTokenController.java:29)\n\tat java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n\tat java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\n\tat java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\n\tat java.base/java.lang.reflect.Method.invoke(Method.java:566)\n\tat org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:209)\n\tat org.spring....

Mahmoud Almontasser
@almontasser

@callummole You should also turn off TPM in the config, if you changed the ansible script to use local-config repo, then ssh to the console.sb server, then cd /srv/nfs/mosip/mosip-config/sandbox, edit the file kernel-mz.properties (probably at line 381) change mosip.syncdata.tpm.required from true to false, then add the changes and commit, the config-service will update it self with the changes.

if you've not set local config repo, I don't know if the script creates the pod or not, see if the config-server got created, execute a bash into the pod, cd to /tmp/, and you'll find a directory named config-repo-[some numbers], and apply the mentioned changes above to kernel-mz.properties

Callum Mole
@callummole
Thanks for your continued help @almontasser, I really appreciate it. I'm struggling to keep the changes by executing a bash into the pod as they seem to get overwritten by another process fairly quickly. I'll try editing the ansible script to point to the local-config repo and implement the change that way.
Mahmoud Almontasser
@almontasser
@callummole try this directory in the config-server /var/lib/config_repo
Callum Mole
@callummole
@almontasser that directory doesn't exist on my pod. I was able to edit kernel-mz.properties in tmp/config-repo-XX/sandbox/, but after a few mins the edits reset from false to true.
I haven't tried using a local-config repo, I'll do that next
Callum Mole
@callummole
:tada: Success! I can now login successfully.
Thanks so much @almontasser
Callum Mole
@callummole

I'm having issues with the regproc-registration-status-service pod when restarting the sandbox. It logs that it cannot resolve mzworker0.sb when attempting to retrieve the iam_adapter_url_env at http://mzworker0.sb:30080/artifactory/libs-release-local/io/mosip/kernel/kernel-auth-adapter.jar. Other services on the dmzcluster resolve the mzworker0.sb fine, and the coredns seems to be functioning properly.

Has anyone else come across this sort of error before?

Screenshot 2021-02-01 at 09.48.46.png

Girma Alemu
@girmish_gitlab
Hi everybody, i run kernel-auth-service successfully. when i try to access the url "localhost:8091/authmanager/swagger-ui.html" it needs credentials to login. how do i know username and password?
Callum Mole
@callummole
Hi mosip community. Has anyone successfully deployed the mosip-mock-services? I have an instance of the reg client on a windows VM, on which I have deployed the mock service to support registration. In the logs I see that the mock service device data in found when the reg client scans for devices, but it isn't validate. I've tried to add the mock device info into our sandbox but there was a bit of guesswork involved, and it seems that I haven't done this correctly. Has anyone successfully acheived this, that could advise?
Abdirahman Mohamed
@abdihakx
fatal: [console]: FAILED! => {"changed": false, "msg": "Destination /tmp/mosip/partner-management-services/db_scripts/mosip_pmp/mosip_pmp_deploy.properties does not exist !", "rc": 257}
I am getting this error when running the ansible installation script
The folder has /tmp/mosip/partner-managementservices/db_scripts/mosip_pms/mosip_pms_deploy.properties
Not sure if pmp is supposed to be pms (a typo)?
Callum Mole
@callummole
@abdihakx yes, I would agree with you.
Abdirahman Mohamed
@abdihakx
@callummole any idea on where I could change things?
I tried changing the pms playbook parameters to pmp but this did not help.
Callum Mole
@callummole
I'm not sure where the mosip_pmp is coming from. What version are you using?
I would check the version of the repo partner-management-services your sandbox is pointed to in group_vars/all.yml (repos.pms.src).
Callum Mole
@callummole
Also you need to isolate where the error is coming from. Try running the playbooks individually (e.g. pms.yml) to see whether the error happens when trying to deploy pms or later on
note that it's this repo: https://github.com/mosip/partner-management-services that gets copied to /tmp/
Abdirahman Mohamed
@abdihakx
@callummole I am using the default version under the master branch
Okay, let me try and isolate where it is coming from
Abdirahman Mohamed
@abdihakx
Can the issue be that I am running an older version under the master branch? I can see v1.1.5 is much newer. I thought the master branch would default to the latest version.
Abdirahman Mohamed
@abdihakx
@callummole So, the error is triggered when running the postgres.yml playbook
repo.pms points to master as shown below:
repos:
  commons:
    src: https://github.com/mosip/commons
    dest: '{{tmp_dir}}/commons'
    tag: 1.0.9
  prereg:
    src: https://github.com/mosip/pre-registration
    dest: '{{tmp_dir}}/pre-registration'
    tag: master
  regproc:
    src: https://github.com/mosip/registration
    dest: '{{tmp_dir}}/registration'
    tag: master
  ida:
    src: https://github.com/mosip/id-authentication
    dest: '{{tmp_dir}}/id-authentication'
    tag: 1.0.9
  pms:
    src: https://github.com/mosip/partner-management-services
    dest: '{{tmp_dir}}/partner-management-services'
    tag: master

# DBs
#
databases:
  mosip_kernel:
    sql_path: '{{repos.commons.dest}}/db_scripts'
  mosip_master:
    sql_path: '{{repos.commons.dest}}/db_scripts'
  mosip_iam:
    sql_path: '{{repos.commons.dest}}/db_scripts'
  mosip_audit:
    sql_path: '{{repos.commons.dest}}/db_scripts'
  mosip_idrepo:
    sql_path: '{{repos.commons.dest}}/db_scripts'
  mosip_idmap:
    sql_path: '{{repos.commons.dest}}/db_scripts'
  mosip_prereg:
    sql_path: '{{repos.prereg.dest}}/db_scripts'
  mosip_regprc:
    sql_path: '{{repos.regproc.dest}}/db_scripts'
  mosip_ida:
    sql_path: '{{repos.ida.dest}}/db_scripts'
  mosip_pmp:
    sql_path: '{{repos.pms.dest}}/db_scripts'
Callum Mole
@callummole
@abdihakx no, MOSIP don't have the master as the most up-to-date version. I would use at least v1.1.3 of the sandbox (I haven't tried v1.1.4 or v.1.1.5).
Abdirahman Mohamed
@abdihakx
Thanks @callummole
Will minibox installation of MOSIP result in a difference in functionality as compared to the standard installation?
Abdirahman Mohamed
@abdihakx

fatal: [console]: FAILED! => {"changed": false, "msg": "Destination /tmp/mosip/partner-management-services/db_scripts/mosip_pmp/mosip_pmp_deploy.properties does not exist !", "rc": 257}

By the way, fixed this by replacing mosip_pmp with mosip_pms in group_vars/all.yml

Callum Mole
@callummole
@abdihakx I think it depends how much you use it. I have had no capacity limit issues with the minibox but I've only used it for testing.