{"componentChunkName":"component---src-templates-tutorial-js","path":"/en/tutorial/FAQ/","result":{"data":{"markdownRemark":{"html":"

FAQ

\n
    \n
  1. \n

    How to solve the problem when the database in Oracle could not connect with SuperMap iDesktop?

    \n

    Answer: Please create a new database in Oracle, and use the new one. Follow the steps below to create a new database:

    \n

    (1) Click Database > Oracle > Name(The name of your database) > oracle > Command Pad on the iManager to enter Oracle comnmand pad.

    \n

    (2) Create a folder named ‘supermapshapefile’ under the ‘u01/app/oracle/oradata’ directory(If you already have a folder, skip this step). Execute:

    \n
    mkdir -p /u01/app/oracle/oradata/supermapshapefile
    \n

    (3) Change the folder owner to oracle. Execute:

    \n
    chown oracle /u01/app/oracle/oradata/supermapshapefile
    \n

    (4) Enter Oracle. Execute:

    \n
    sqlplus / as sysdba
    \n

    (5) Fill in the username and password of Oracle. You can view account information by clicking Database > Oracle > Name > Account on the iManager page.

    \n

    (6) Create a tablespace, the size is 200M(you can set the size of tablespace according to your requirement). Execute:

    \n
    create tablespace supermaptbs datafile '/u01/app/oracle/oradata/supermapshapefile/data.dbf' size 200M;
    \n

    (7) Create a new user of the tablespace. For example, username: supermapuser; password: supermap123. Execute:

    \n
    create user supermapuser identified by supermap123 default tablespace supermaptbs;
    \n

    (8) Grant new user permission. Execute:

    \n
    grant connect,resource to supermapuser;\ngrant dba to supermapuser;
    \n
    2. \n
  2. \n

    If you redeploy or adjust spec immediately after deploying or adjusting spec, the license assign failed, how to solve the problem?

    \n

    Answer: After redeploying or adjusting spec, please make sure the services have been assigned the license successfully, then do others operations like redeploy or adjust spec.

    \n
    3. \n
  3. \n

    When viewing monitoring statistic charts, the charts do not display data or the time of data can not match the real time, how to solve the problem?

    \n

    Answer: Please make sure the time settings of local machine and Kubernetes node machines are same.

    \n
    4. \n
  4. \n

    How to use the https protocol?

    \n

    Answer: Both of Keycloak and iManager support https protocol, please do the following operations to achieve https protocol:

    \n

    (1) Go to the iManager installation directory(the directory in which you executed ./startup or ./start command to start iManager) and find out the file named values.yml, execute the following command:

    \n
    sudo vi values.yml
    \n

    (2) Modify the value of “deploy_keycloak_service_protocol” to “https” when you want to use Keycloak https protocol; Modify the value of “deploy_imanager_service_protocol” to “https” when you want to use iManager https protocol.

    \n

    (3) Save the setting and restart iManager:

    \n
    sudo ./startup.sh
    \n
    5. \n
  5. \n

    How to replace the security certificate in iManager for K8s?

    \n

    Answer: There are two kinds of security certificates in iManager for K8s, one is for security center(Keycloak), another one is for access entrance. Please follow the steps below to replace two security certificates separately:

    \n

    Replace the Security Certificate for Keycloak

    \n

    (1) Executes the following command on Kubernetes Master machine to find the volume of the security certificate(<namespace> in the command is the namespace of iManager, it is ‘supermap’ by default. Please replace to the actual namespace if you have any change):

    \n
    kubectl -n <namespace> describe pvc pvc-keycloak | grep Volume: | awk -F ' ' '{print $2}' | xargs kubectl describe pv
    \n

    (2) Stores your new security certificate to the volume in step (1);

    \n
    \n

    Notes:
    \nThe security certificate includes certificate and private key, the certificate should be renamed to tls.crt, the private key should be renamed to tsl.key.

    \n
    \n

    (3) Logs in to iManager and redeploys the Keycloak service in Basic Services.

    \n

    Replace the Security Certificate for Access Entrance

    \n

    (1) Executes the following command on Kubernetes Master machine to find the volume of the security certificate(<namespace> in the command is the namespace of iManager, it is ‘supermap’ by default. Please replace to the actual namespace if you have any change):

    \n
    kubectl -n <namespace> describe pvc pvc-imanager-dashboard-ui | grep Volume: | awk -F ' ' '{print $2}' | xargs kubectl describe pv
    \n

    (2) Stores your new security certificate to the volume in step (1);

    \n
    \n

    Notes:
    \nThe security certificate includes certificate and private key, the certificate should be renamed to ‘certificate.crt’, the private key should be renamed to ‘private.key’.

    \n
    \n

    (3) Logs in to iManager and redeploys the imanager-dashboard-ui service in Basic Services.

    \n
    6. \n
  6. \n

    How to create the resource with the same name as the Secret when configuring the image pull secret?

    \n

    Answer: When configuring the Secret, you need to create a resource with the same name as the Secret in iManager namespace of Kubernetes. You also need to create a resource with the same name as the secret value in namespace ‘istio-system’ when enabling Service Mesh(Istio). And create a resource with the same name as the secret value in namespace ‘kube-system’ when enabling metrics server. Please enter the following command in Kubernetes Master machine to create the resource:

    \n
    kubectl create secret docker-registry <image-pull-secret> --docker-server="<172.16.17.11:5002>" --docker-username=<admin> --docker-password=<adminpassword> -n <supermap>
    \n
    \n

    Notes:

    \n
      \n
    1. The contents in the command with symbol ”<>” need to be replaced according to your actual environment(Delete the symbol ”<>” after replacing).\n<image-pull-secret> is the name of your Secret;\n<172.16.17.11:5002> is your registry address;\n<admin> is the namespace of your registry;\n<adminpassword> is the password of your namespace;\n<supermap> is the namespace of iManager(replace <supermap> to ‘istio-system’ or ‘kube-system’ when you create the resource in the namespace istio-system or kube-system).
      2. \n
    2. If the namespace istio-system does not exist, execute ‘kubectl create ns istio-system’ in the machine of Kubernetes master node to create.
      3. \n
    \n
    \n
    7. \n
  7. \n

    How to solve the error “Error: UPGRADE FAILED: cannot patch “pv-nfs-grafana” with kind StorageClass: StorageClass.storage.k8s.io “pv-nfs-grafana” is invalid …” when you restart iManager?

    \n

    Answer: The error occurs because Kubernetes patch operation does not support to update the provider of storageClass. The error has no negative influence on iManager, please ignore the error.

    \n
    8. \n
  8. \n

    How to refresh the certificate of Kubernetes?

    \n

    Answer: The validity period of Kubernetes certificate is one year, you need to refresh the certificate when expired. Please follow the steps below to refresh the certificate of Kubernetes:

    \n

    (1) Enter the /etc directory of the master machine of Kubernetes, backup the files in /kubernetes directory:

    \n
    cd /etc\ncp -r kubernetes kubernetes.bak
    \n

    (2) Create a new configuration file ‘kubeadm.yaml’:

    \n
    vi kubeadm.yaml
    \n

    (3) Configure kubeadm.yaml file(The IP ‘10.10.129.26’ below is the IP of Kubernetes Master node, please replace it by the IP of your Kubernetes Master node):

    \n
    kind: MasterConfiguration\napiVersion: kubeadm.k8s.io/v1beta1\nkubernetesVersion: v1.14.0\napi:\n advertiseAddress: 10.10.129.29
    \n

    (4) Issue a new certificate by the configuration file:

    \n
    kubeadm init phase certs all --config=kubeadm.yaml
    \n

    (5) Regenerate the configuration file:

    \n
    kubeadm init phase kubeconfig all --config kubeadm.yaml
    \n

    (6) Restart the containers kube-apiserver, kube-controller-manager, kube-scheduler, and etcd:

    \n
    docker ps |grep -E 'k8s_kube-apiserver|k8s_kube-controller-manager|k8s_kube-scheduler|k8s_etcd_etcd' | awk -F ' ' '{print $1}' |xargs docker restart
    \n

    (7) Check the expiration date of the new certificate:

    \n
    openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text |grep ' Not '
    \n

    (8) Check the status of Work nodes(use the command kubectl get nodes), if the status of Work nodes are ‘NotReady’, execute the following command to regenerate the configuration file of Work nodes:

    \n
    mv /var/lib/kubelet/pki /var/lib/kubelet/pki.bak\nsystemctl daemon-reload && systemctl restart kubelet
    \n

    (9) Check the status of Work nodes again, if the status of Work nodes are still ‘NotReady’, copy the /etc/kubernetes/pki/ca.crt file from Master node and plaste to the same directory of Work nodes, then restart kubelet(use the command systemctl restart kubelet to restart kubelet, you need to wait for 3 miniutes after restarting kubelet).

    \n
    9. \n
  9. \n

    How to configure local storage for built-in HBase environment?

    \n

    Answer: The NFS volume will impact the write/read ability of HBase, you can optimize the ability by the following way:

    \n

    (1) Modify the value of deploy_disable_hbase_nfs_volume to true in the configuration(values.yaml).

    \n
    deploy_disable_hbase_nfs_volume: true
    \n

    (2) Please refer to the hbase-datanode-local-volume.yaml file, and modify the file according to the actual situation:

    \n
    apiVersion: v1\nkind: PersistentVolume\nmetadata:\n labels:\n   type: icloud-native\n name: icloud-native-hbase-datanode-volume-0  #Point 1\nspec:\n storageClassName: local-volume-storage-class\n capacity:\n   storage: 10Ti\n accessModes:\n   - ReadWriteMany\n local:\n   path: /opt/imanager-data/datanode-data  #Point 2\n persistentVolumeReclaimPolicy: Delete\n nodeAffinity:\n   required:\n     nodeSelectorTerms:\n       - matchExpressions:\n         - key: kubernetes.io/hostname\n           operator: In\n           values:\n             - node1   #Point 3
    \n

    The places need to be modified are marked by ’#’ on the above:

    \n\n

    Use the command below to create directory on the node(replace the path by your actual setting):

    \n
    mkdir -p /opt/imanager-data/datanode-data
    \n\n

    (3) Execute the command on the Kubernetes master node after modifying:

    \n
    kubectl apply -f hbase-datanode-local-volume.yaml
    \n
    \n

    Notes:

    \n
      \n
    1. The number of PVs should be the same as the number of dataNodes in HBase environment, the default is 3. If you scaled the node, please created the the same number of PVs.
      2. \n
    2. The PV could be created on any node of Kubernetes(specified by #Third), recommended to create on different nodes.
      3. \n
    3. The PV could be created before opening/scaling the HBase, or after opening/scaling the HBase.
      4. \n
    \n
    \n
    10. \n
  10. \n

    How to solve the problem that the system is hanging, and the log of system has the error “echo 0 > /proc/sys/kernel/hungtasktimeout_secs” disables this message.”?

    \n

    Answer: The reason of system hangs is the rising loading when system is running, the dirty data of files system can not be written into the disk in the stipulated time. Please refer to the following steps to solve the problem:

    \n

    (1) Edit the file ‘sysctl.conf’ in ‘/etc’ derectory. Set the method of processing dirty data and the timeout of writting dirty data:

    \n
    # When the system dirty data reach to the ratio, the system start to process\nvm.dirty_background_ratio=5\n# When the system dirty data reach to the ratio, the system must process \nvm.dirty_ratio=10\n# The timeout of writing dirty data, the value is 120 second by default, 0 mean no limit\nkernel.hung_task_timeout_secs=0
    \n

    (2) Force restart, execute the command:

    \n
    reboot -n -f
    \n
    11. \n
  11. \n

    How to solve the problem that a worker node server breakdown in Kubernetes cluster?

    \n

    Answer: If your Kubernetes cluster is made up by three or more than three servers(include Master node server), when a worker node server breakdown, the services which are running in the worker node server will emmigrate to other worker node servers automatically. If your Kubernetes cluster is made up by two servers, when the worker node server breakdown, please follow the steps below to recover services:

    \n

    (1) Check the servers name in Master node server:

    \n
    kubectl get nodes
    \n

    (2) Change the name of Master node server:

    \n
    hostnamectl set-hostname <newhostname>
    \n
    \n

    Notes:
    \n<newhostname> in the command is the new name of Master node server, the new name supports customization.

    \n
    \n

    (3) Enter the directory /etc/kubernetes/manifests:

    \n
    cd /etc/kubernetes/manifests
    \n

    (4) Edit the file ‘etcd.yaml’, modify the old name of Master node server in the file to the new name(as the screenshot below, there are two places to modify). Execute the command to edit ‘etcd.yaml’ file:

    \n
    vi etcd.yaml
    \n

    \n \n \n \n \n \n \n \n \n \n

    \n

    (7) Edit ‘kubeadm-config ConfigMap’ in the namespace of kube-system, modify the old name of Master node server to the new name(as the screenshot below, there is only one place to modify):

    \n
    kubectl -n kube-system edit configmap kubeadm-config
    \n

    \n \n \n \n \n \n \n \n \n \n

    \n

    （8）Generate certificate for new server, replace the old certificate. Execute the following operation:

    \n
    cd /etc/kubernetes/pki/\nmkdir -p ~/tmp/BACKUP_etc_kubernetes_pki/etcd/\nmv apiserver.crt apiserver-etcd-client.key apiserver-kubelet-client.crt front-proxy-ca.crt front-proxy-client.crt front-proxy-client.key front-proxy-ca.key apiserver-kubelet-client.key apiserver.key apiserver-etcd-client.crt ~/tmp/BACKUP_etc_kubernetes_pki/.\nmv etcd/healthcheck-client.* etcd/peer.* etcd/server.* ~/tmp/BACKUP_etc_kubernetes_pki/etcd/\nkubeadm init phase certs all\n\ncd /etc/kubernetes\nmkdir -p ~/tmp/BACKUP_etc_kubernetes\nmv admin.conf controller-manager.conf kubelet.conf scheduler.conf ~/tmp/BACKUP_etc_kubernetes/.\nkubeadm init phase kubeconfig all\n\nmkdir -p ~/tmp/BACKUP_home_.kube\ncp -r ~/.kube/* ~/tmp/BACKUP_home_.kube/.\ncp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    \n

    (9) Apply the ‘node.yaml’ file of Worker node server which is modified in step (6):

    \n
    kubectl apply -f node.yaml
    \n

    (10) Delete the old Worker node server:

    \n
    kubectl delete node <old-nodeName>
    \n

    (11) Restart kubelet and docker services:

    \n
    systemctl daemon-reload && systemctl restart kubelet && systemctl restart doker
    \n
    12. \n
","frontmatter":{"title":"Tutorial","next":null,"prev":null},"fields":{"path":"content/tutorial/FAQ.en.md","slug":"/en/tutorial/FAQ/","langKey":"en"}}},"pageContext":{"slug":"/en/tutorial/FAQ/"}}}