顯示文章

這裡允許您檢視這個會員的所有文章。請注意, 您只能看見您有權限閱讀的文章。


文章 - netman

頁: [1] 2 3 ... 499
1
linux 的 NAT 有分兩種:SNAT(masqurating) 與 DNAT(port mapping)
如果你要單純做 SNAT,那用外面來 ping 是徒勞的。
ping 是 ICMP 協定的 echo request ,你需要用 DNAT 將相應的 icmp type/code 給 forward 到特定得 destination。
這不一定需要兩片網路卡。

我在 n 年前寫過一篇介紹 linux firewall 的文章,不妨參考看看:
https://www.slideshare.net/kennychennetman/linux-firewall-32337622
如果對 Part-V 的問題都能理解,應該就可以解決大部分問題了。

2
那外面 ping 不到是正常的。NAT 之後,外面的 ping 不進來的。

3
等等,你這裡的host是實體主機?

4
老實說,有點看不太懂你畫的圖。

如果是 bridge mode,我會畫成這樣附件那樣。(紅色爲 vm)

5
基本上,經過 NAT 之後, 外面是無法 PING 進來的。
除非你用 routing mode(不同subnet) 或用 bridge(相同subnet)
用 routing 的話, 那需要雙方設定 gateway 互相指向。

6
你可以用附件功能將圖貼上來哦

7
工作機會 / Re: KKStream 獨家工作機會
« 於: 2019-08-22 10:40 »
好工作!不做嗎?

8
可以畫個網路架構圖來看看嗎?

9
Linux 討論版 / Re: Cent 6.10搭建FTP服务器问题
« 於: 2019-08-20 22:13 »
1. 如果 chmod 777 可以的話,那幾乎可以排除是 selinux 的影響。
chown_uploads=YES
chown_username=SAS
anon_umask=077
因爲你使用了 chown,上傳後身份就改變了,所以 guest 會無法 ls / dir 那是正常的。
這其實也是匿名上傳的建議做法,沒啥不好,並非遇到問題了。

2. 在匿名上傳的 ftp 管理中,需要本機的管理員檢核過上傳的文件,再決定是否開放匿名 ftp 下載,若覺得可以,執行 chown vsftpd 修改允許之文件即可。

10
那不要直接用 ntfs 格式呢?
也就是先用 xfs 或 ext4 掛載到 centos,然後再於裏面創建虛擬硬盤給 windows,然後再格式化爲 NTFS 。

11
Study-Area 公開討論版 / Re: 新人报道
« 於: 2019-08-14 21:42 »
歡迎啊~

非常感謝您的意見!因爲網站好久沒維護了,不足之處還請多多包涵~~

12
Linux 討論版 / Re: root帳號修改密碼被限制
« 於: 2019-08-08 20:27 »
具體的 error 是什麼呢?

13
Runing a descheduler on your own K8S cluster

v1.0
2019-08-01


一,前言

當我們建置完成一個多 worker nodes 的 K8S cluster 之後,本身就能提供相當的容錯能力。也就是當其中一臺 worker 節點故障或是用 drain 命令排除的時候,運行其上的 pods 會自動轉移至其他良好的 worker 節點上。然而,當故障節點修復上線或用 uncordon 命令加回 cluster 之後,已經處於運行狀態的 pods 並不會自動轉移回康復節點, 只有新產生的 pods 才會被安排在其上運行。

有時候,不同的 node 或因資源不同或因工作量不同,會導致各自有不同的負載:有些節點很忙、有些則很閒。

爲解決上述情況,除了管理員人爲調配之外,我們也可以藉助一個名爲 DeScheduler 的工具來實現服務的自動化平衡調度。


二,關於 DeScheduler

如下爲 DeScheduler 的 GitHub:
   https://github.com/kubernetes-incubator/descheduler

有興趣的朋友可以先去瞭解它的設檔細節,尤其是其中的 Policy and Strategies:
  • RemoveDuplicates
  • LowNodeUtilization
  • RemovePodsViolatingInterPodAntiAffinity
  • RemovePodsViolatingNodeAffinity

這裏暫時不討論這 4 種基本策略的內容了,我們只需要將所要的策略配置爲 ConfigMap 即可(一個單一的 ConfigMap 可以配置多個策略)。


三,部署 DeScheduler

3.1 建立一個空白目錄:
代碼: [選擇]
mkdir descheduler-yaml
cd descheduler-yaml

3.2 建置 ClusterRole & ServiceAccount:
代碼: [選擇]
cat > cluster_role.yaml << END
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: descheduler
  namespace: kube-system
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete"]
- apiGroups: [""]
  resources: ["pods/eviction"]
  verbs: ["create"]
END
kubectl apply -f cluster_role.yaml
kubectl create sa descheduler -n kube-system
kubectl create clusterrolebinding descheduler \
    -n kube-system \
    --clusterrole=descheduler \
    --serviceaccount=kube-system:descheduler

3.3 配置 ConfigMap:
代碼: [選擇]
cat > config_map.yaml << END
apiVersion: v1
kind: ConfigMap
metadata:
  name: descheduler
  namespace: kube-system
data:
  policy.yaml: |- 
    apiVersion: descheduler/v1alpha1
    kind: DeschedulerPolicy
    strategies:
      RemoveDuplicates:
         enabled: true
      LowNodeUtilization:
         enabled: true
         params:
           nodeResourceUtilizationThresholds:
             thresholds:
               cpu: 20
               memory: 20
               pods: 20
             targetThresholds:
               cpu: 50
               memory: 50
               pods: 50
      RemovePodsViolatingInterPodAntiAffinity:
        enabled: true
      RemovePodsViolatingNodeAffinity:
        enabled: true
        params:
          nodeAffinityType:
          - requiredDuringSchedulingIgnoredDuringExecution
END
kubectl apply -f config_map.yaml

#注意: 這裏我們將 RemoveDuplicates 策略設定爲啓用(enabled: true),如果不需要自動將 pods 分配到新成員節點的話,可以設定爲停用(enabled: false)。如果系統資源充足而達不到觸發條件,可以調低 LowNodeUtilization 策略的 thresholds 數值(cpu, momory, pod 數量,這三者要同時滿足才能觸發作動)。

3.4 配置 CronJob:
代碼: [選擇]
cat > cron_job.yaml << END
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: descheduler
  namespace: kube-system
spec:
  schedule: "*/30 * * * *"
  jobTemplate:
    metadata:
      name: descheduler
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: "true"
    spec:
      template:
        spec:
          serviceAccountName: descheduler
          containers:
          - name: descheduler
            image: komljen/descheduler:v0.6.0
            volumeMounts:
            - mountPath: /policy-dir
              name: policy-volume
            command:
            - /bin/descheduler
            - --v=4
            - --max-pods-to-evict-per-node=10
            - --policy-config-file=/policy-dir/policy.yaml
          restartPolicy: "OnFailure"
          volumes:
          - name: policy-volume
            configMap:
              name: descheduler
END
kubectl apply -f cron_job.yaml

# 注意:這裏設定的 CronJob 是每 30 分鐘執行一次,假如想在測試時更快驗證效果,可以調整爲更短的時間。


四,驗證

4.1 確認 CronJob:
代碼: [選擇]
kubectl get cronjobs -n kube-system確定可以看到類似如下的結果:
NAME          SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
descheduler   */30 * * * *   False     0         2m              32m


4.2 確認完成工作的 pods:
代碼: [選擇]
kubectl get pods -n kube-system | grep Completed會看到類似如下的結果:
descheduler-1564670400-67tqx                   0/1     Completed   0          1H
descheduler-1564670700-2vwhv                   0/1     Completed   0          32m
descheduler-1564671000-g69nc                   0/1     Completed   0          2m


4.3 檢查 logs:
代碼: [選擇]
kubectl -n kube-system logs descheduler-1564671000-g69nc如果沒觸發任何作動的話,最後一行會類似如下:
...
I0505 11:55:08.160964       1 node_affinity.go:72] Evicted 0 pods


4.4 排擠測試節點:
代碼: [選擇]
kubectl drain worker03.localdomain --ignore-daemonsets --delete-local-data  --grace-period=0 --force
kubectl get nodes worker03.localdomain
確認節點狀態類似如下:
NAME                   STATUS                     ROLES    AGE   VERSION
worker03.localdomain   Ready,SchedulingDisabled   <none>   71d   v1.15.0


等待片刻,確認所有 running pods 都只運行在其他 workers 上面:
web-6fc4fb46d-k5pzr              1/1     Running   0          88s     10.47.0.23   worker01.localdomain   <none>           <none>
web-6fc4fb46d-l9h4j              1/1     Running   0          52s     10.39.0.24   worker02.localdomain   <none>           <none>
web-6fc4fb46d-mqwqv              1/1     Running   0          85s     10.47.0.26   worker01.localdomain   <none>           <none>
web-6fc4fb46d-phr8r              1/1     Running   0          71s     10.47.0.8    worker01.localdomain   <none>           <none>
web-6fc4fb46d-t5ct7              1/1     Running   0          80s     10.47.0.27   worker01.localdomain   <none>           <none>
web-6fc4fb46d-vq4mk              1/1     Running   0          5m38s   10.39.0.8    worker02.localdomain   <none>           <none>
web-6fc4fb46d-ww2nq              1/1     Running   0          6m8s    10.47.0.10   worker01.localdomain   <none>           <none>
web-6fc4fb46d-wz8vl              1/1     Running   0          58s     10.39.0.22   worker02.localdomain   <none>           <none>
web-6fc4fb46d-xvk48              1/1     Running   0          5m25s   10.39.0.11   worker02.localdomain   <none>           <none>
web-6fc4fb46d-xxr5q              1/1     Running   0          5m56s   10.47.0.16   worker01.localdomain   <none>           <none>
web-6fc4fb46d-zcg6l              1/1     Running   0          2m29s   10.47.0.18   worker01.localdomain   <none>           <none>
web-6fc4fb46d-zh7zv              1/1     Running   0          11m     10.39.0.19   worker02.localdomain   <none>           <none>
web-6fc4fb46d-zldt7              1/1     Running   0          5m31s   10.39.0.4    worker02.localdomain   <none>           <none>
web-6fc4fb46d-zxrxw              1/1     Running   0          31m     10.39.0.7    worker02.localdomain   <none>           <none>


4.4 將節點復原:
代碼: [選擇]
kubectl uncordon worker03.localdomain
kubectl get nodes
確認所有節點都處於 ready 狀態:
NAME                   STATUS   ROLES    AGE   VERSION
master01.localdomain   Ready    master   71d   v1.15.0
master02.localdomain   Ready    master   71d   v1.15.0
master03.localdomain   Ready    master   71d   v1.15.0
worker01.localdomain   Ready    <none>   71d   v1.15.0
worker02.localdomain   Ready    <none>   71d   v1.15.0
worker03.localdomain   Ready    <none>   71d   v1.15.0


觀察 CronJob 剛有執行最近一次工作:
代碼: [選擇]
kubectl get pods -n kube-system | grep Completed看到類似如下的結果:
descheduler-1564671600-spl42                   0/1     Completed   0          1h
descheduler-1564671900-2sn9j                   0/1     Completed   0          30m
descheduler-1564672200-sq5zw                   0/1     Completed   0          77s


再次檢查 logs:
代碼: [選擇]
kubectl -n kube-system logs descheduler-1564672200-sq5zw將會發現有相當數量的 pods 被 evicted 了:
...
I0801 15:11:00.012104       1 node_affinity.go:72] Evicted 20 pods


確認 pods 被重新分配回節點:
web-6fc4fb46d-n687t              1/1     Running   0          87s     10.42.0.17   worker03.localdomain   <none>           <none>
web-6fc4fb46d-nzdrs              1/1     Running   0          91s     10.42.0.16   worker03.localdomain   <none>           <none>
web-6fc4fb46d-qrn6n              1/1     Running   0          2m8s    10.47.0.14   worker01.localdomain   <none>           <none>
web-6fc4fb46d-qxd8v              1/1     Running   0          2m1s    10.39.0.15   worker02.localdomain   <none>           <none>
web-6fc4fb46d-rpw8b              1/1     Running   0          70s     10.42.0.11   worker03.localdomain   <none>           <none>
web-6fc4fb46d-rxxrn              1/1     Running   0          2m3s    10.47.0.19   worker01.localdomain   <none>           <none>
web-6fc4fb46d-svts8              1/1     Running   0          2m6s    10.47.0.15   worker01.localdomain   <none>           <none>
web-6fc4fb46d-v9q9c              1/1     Running   0          2m4s    10.47.0.17   worker01.localdomain   <none>           <none>
web-6fc4fb46d-x5vrs              1/1     Running   0          110s    10.39.0.21   worker02.localdomain   <none>           <none>
web-6fc4fb46d-xfrnh              1/1     Running   0          76s     10.42.0.8    worker03.localdomain   <none>           <none>
web-6fc4fb46d-xmz64              1/1     Running   0          7m11s   10.42.0.4    worker03.localdomain   <none>           <none>
web-6fc4fb46d-z2xhw              1/1     Running   0          7m9s    10.42.0.7    worker03.localdomain   <none>           <none>
web-6fc4fb46d-zkv95              1/1     Running   0          7m12s   10.42.0.2    worker03.localdomain   <none>           <none>
web-6fc4fb46d-zltxl              1/1     Running   0          105s    10.47.0.6    worker01.localdomain   <none>           <none>



五,結論

透過 DeScheduler 我們可以實現動態的服務應用自動化配置,將負載平均到所有的 worker 節點,可確保 cluster 資源消費的合理化,有助於提升容錯性與服務穩定性。值得一試。

14
Building a K8S load balancer yourself

v1.0
2019-07-30


一、前言

看網絡上許多關於 K8S 的文章,談到服務(Service)導出方法的時候,若不想手動操作 expose 或使用 NodePort 的話,其中有一個選項是 LoadBalancer。聽起來是非常 cool 的方式,可惜大部分都是雲端服務商才能提供的服務。這對於一般入門者來說,消費雲端服務是一項奢侈品項,或是單純練習並想花那些成本。

然而,對於成功自架 K8S Cluster 的朋友來說,可以安裝 MetalLB 這個產品提供 local 的負載平衡器,實在是一大福音!


二、安裝步驟

2.1 直接用 kubectl 部署:
kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml

成功的話,會多出一個 metallb-system 的 name space,裏面會運行如下兩種 pod:
代碼: [選擇]
controller
speaker

2.2 配置 ConfigMap
請以文字編輯器編輯一份 yaml (metallb_configmap.yml),其內容如下:
代碼: [選擇]
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: my-ip-space
      protocol: layer2
      addresses:
      - 192.168.100.240-192.168.100.249

請注意:將 ip range 修改爲設當的網段:可以連線也不會造成 IP 位置衝突即可。

完成後套用 ConfigMap:
kubectl apply -f metallb_configmap.yml

沒錯,就這麼簡單!這樣我們的 MetalLB 就已經設定完成了。


三、測試

如下,我們透過一個簡單的 nginx 服務來測試 LoadBalancer 是否可以運作。

3.1 建立 nginx deployment 設定檔(nginx.yaml),其內容如下:
代碼: [選擇]
apiVersion: v1
kind: Namespace
metadata:
  name: metallb-test
  labels:
    app: metallb
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: metallb-test
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-deployment
  namespace: metallb-test
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer

這裏我們獨立建一個 metallb-test 的 name space 以便我們測試用。

3.2 執行部署:
kubeclt apply -f nginx.yaml

3.3 假如部署沒有問題,我們就可以執行如下命令來檢查結果:
kubectl -n metallb-test get svc -o wide

應該看到類似如下這樣的 EXTERNAL-IP :
代碼: [選擇]
NAME               TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)        AGE     SELECTOR
nginx-deployment   LoadBalancer   10.103.250.239   192.168.100.240   80:16656/TCP   2m51s   app=nginx

這就代表 MetalLB 這個 LoadBalancer 是可以 work 的!

3.4 清除部署:
kubeclt delete -f nginx.yaml


四、結論
MetalLB 可以說是窮人的 K8S LoadBalancer,設定非常簡單,部署上沒有太高難度。非常適合自架練習 K8S 服務使用。

15
Using Ceph RBD Storage Classes in K8S

Author: netman<netman@study-area.org>
Date: 2019-07-25


一,前言

K8S 中可以使用的 volume 種類非常多,同時也提供 Storage Class 的方式讓管理員更方便的調用定義好的儲存種類。有興趣的話可以參考官方文件:
   https://kubernetes.io/docs/concepts/storage/volumes/
   https://kubernetes.io/docs/concepts/storage/persistent-volumes
   https://kubernetes.io/docs/concepts/storage/storage-classes/

本篇文章僅以簡單的實作形式來說明如何在 K8S 中使用 Ceph RBD 這一儲存資源。


二,前提條件

在展開實作之前,我們假設如下環境已經建置完成並且正常運作中:
Ceph Storage (monitors: 192.168.100.21-23)
K8S Cluster (用 kubeadm 部署)
這裏不再討論如何建置上述系統了,請另行參考其他文章。


三,實作步驟

3.1 於 ceph 上面建立專用的 pool 並設定帳號權限:
代碼: [選擇]
ceph osd pool create kube 32 32    # 具體的 PG number 請根據現況調整
ceph osd pool application enable 'kube' 'rbd'
ceph auth get-or-create client.kube mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=kube'

3.2 記錄如下 base64 編碼值( K8S 設定 secrets 需要一致):
代碼: [選擇]
ceph auth get-key client.admin | base64    # 輸出將對應到 k8s 的 ceph-secret-admin secret
ceph auth get-key client.kube | base64     # 輸出將對應到 k8s 的 ceph-secret-kube secret

3.3 在 k8s cluster 中的 worker nodes 上面安裝 ceph-common, 並將 ceph monitor 中的 admin key 檔案複製過來:
代碼: [選擇]
yum install -y ceph-common
scp 192.168.100.21:/etc/ceph/ceph.client.admin.keyring /etc/ceph/

3.4 在 k8s 的操作主機(已經設定好context並能順利執行kubectl, 同時也能執行git命令)建立一個專用工作目錄:
代碼: [選擇]
mkdir ~/kube-ceph
cd ~/kube-ceph

3.5 建立 secrets yaml:
代碼: [選擇]
cat > kube-ceph-secret.yaml << END
apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret-admin
type: "kubernetes.io/rbd"
data:
  key: QVFEYzF0SmNMaVpkRmhBQWlKbUhNbndaR2tCdldFcThXWDhaaXc9PQ==
---
apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret-kube
type: "kubernetes.io/rbd"
data:
  key: QVFDSFdUaGROcC9LT2hBQUpkVG5XVUpQUOYrZGtvZ2k3S0Zwc0E9PQ==
END

3.6 建立 Storage Class yaml:
代碼: [選擇]
cat > kube-ceph-sc.yaml << END
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: ceph-rbd
#provisionen: kubernetes.io/rbd
provisioner: ceph.com/rbd
parameters:
  monitors: 192.168.100.21:6789,192.168.100.22:6789,192.168.100.23:6789
  adminId: admin
  adminSecretName: ceph-secret-admin
  adminSecretNamespace: default
  pool: kube
  userId: kube
  userSecretName: ceph-secret-kube
  userSecretNamespace: default
  imageFormat: "2"
  imageFeatures: layering
END

3.7 建立 Persistent Volume Claim (PVC) yaml:
代碼: [選擇]
cat > kube-ceph-pvc.yaml << END
metadata:
  name: ceph-k8s-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ceph-rbd
  resources:
    requests:
      storage: 1Gi
END

3.8 因爲透過 kubeadm 部署 k8s 的原因,其內建的 provider 並沒有提供 rbd 的支援(provisioner: kubernetes.io/rbd),會遇到如下 error:
persistentvolume-controller     Warning   ProvisioningFailed  Failed to provision volume with StorageClass "ceph-rbd": failed to create rbd image: executable file not found in $PATH, command output:

我們需要另行下載並部署延伸支援(provisioner: ceph.com/rbd, 上面的 Storage Class yaml 已經修改爲延伸支援了):
代碼: [選擇]
git clone  https://github.com/kubernetes-incubator/external-storage
cd external-storage/ceph/rbd/deploy/rbac/
kubectl apply -f ./

3.9 確認 rbd-provisioner pod 有正常運作:
代碼: [選擇]
kubectl get pods# 確定可以看到類似如下的 pod 在 Running 的狀態:
rbd-provisioner-9b8ffbcc-bwzvr   1/1     Running   0          58s

3.10 套用 ceph rbd 並將 ceph-rbd Storage Class 設定爲 default:
代碼: [選擇]
cd ~/kube-ceph
kubectl apply -f ./
kubectl patch storageclass ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

3.11 驗收成果
代碼: [選擇]
kubectl get StorageClass# 確認 ceph-rbd 是唯一的 default
NAME                 PROVISIONER    AGE
ceph-rbd (default)   ceph.com/rbd   31s


代碼: [選擇]
kubectl get pvc# 確認 pvc 有正確的 bound 起來
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ceph-k8s-claim   Bound    pvc-00840751-aedf-11e9-8a7d-525400b83b04   1Gi        RWO            ceph-rbd       75s


同時,在 ceph 那邊也能看到新的 rbd image 被自動建立起來:
代碼: [選擇]
rbd list -p kube# 可以看到類似如下的結果:
kubernetes-dynamic-pvc-755378b8-aedf-11e9-984f-16b92f357547

3.12 將 pvc 實作於 pod 內:
代碼: [選擇]
cat > kube-ceph-pod.yaml << END
apiVersion: v1
kind: Pod
metadata:
  name: kube-ceph-pod       
spec:
  containers:
  - name: ceph-busybox
    image: busybox         
    command: ["sleep", "60000"]
    volumeMounts:
    - name: ceph-volume       
      mountPath: /usr/share/ceph-rbd
      readOnly: false
  volumes:
  - name: ceph-volume 
    persistentVolumeClaim:
      claimName: ceph-k8s-claim
END

16
Linux 討論版 / Re: ssh login 認證加密問題
« 於: 2019-07-16 20:38 »
有具體的錯誤訊息或log嗎?

17
Linux 討論版 / Re: dns備援伺服器的設定
« 於: 2019-07-08 21:15 »
named[7962]: zone XXX.edu/IN: loaded serial 158
上面這行就看得到 serial 是 158
或是,簡單些,你修改 master 上面的 record,然後將 dns server 指定 slave 看看是否能看到?

18
firewall?
netstat 看到的 port 是 listen 在 0.0.0.0 上面嗎?

19
Linux 討論版 / Re: 用户组权限
« 於: 2019-07-07 22:20 »
logout 再 login 一次呢?

20
Linux 討論版 / Re: dns備援伺服器的設定
« 於: 2019-07-07 22:18 »
如果 zone 有載入,且 serail 有跟 master 同步,那就是OK了。

21
節省哥好! 歡迎光臨^_^

22
MIS 討論區 / Re: 打造個人雲端系統
« 於: 2019-06-27 19:29 »
可以說說怎麼做嗎?

23
Linux 討論版 / Re: 關於dns反解問題
« 於: 2019-06-27 19:28 »
我猜應該是保留給 private network 的就不能 delegate 了...
雖然我沒再去測試了,我猜 16 之於 172.in-addr.arpa 應該也是如此。

24
Linux 討論版 / Re: 關於dns反解問題
« 於: 2019-06-26 16:28 »
嗯.... 看來真如大大猜測那樣,似乎是 bind 的限制。
我針對 192.in-addr.arpa 測試如下 PTR:
1.100.168 IN PTR node1.test.lab.
1.100.111 IN PTR node1.test.lab.
1.100 IN PTR node1.test.lab.
1 IN PTR node1.test.lab.
就只有第一筆查不到,其他都可以... Orz

25
Linux 討論版 / Re: 關於dns反解問題
« 於: 2019-06-26 16:18 »
忍不住動手裝了一個 bind 來測試...

看起來似乎不允許超過一個小數點的 PTR record?
我再試試其他方法...

26
Linux 討論版 / Re: 關於dns反解問題
« 於: 2019-06-26 16:06 »
OK, 那把 zone file 搬回來吧...
暫時把 slave 的  NS 拿掉,保持單一環境來測試
然後再確定 log 跟  dig

27
Linux 討論版 / Re: 關於dns反解問題
« 於: 2019-06-25 20:09 »
不對啊,你上次的 log 就是 168.192.in-addr.arpa 這個 zone 了呢...

你修改回昨天的,但將 twcc.wan.192 移到別處(讓bind抓不到)
重新啓動後用 dig 查一下  NS 跟 SOA ?

28
Linux 討論版 / Re: 關於dns反解問題
« 於: 2019-06-24 20:22 »
;; AUTHORITY SECTION:
168.192.in-addr.arpa.   86400   IN      SOA     168.192.in-addr.arpa. . 0 28800 7200 604800 86400

SOA 不對阿...
先看看 log 有沒載入正確的 zone ?

29
Linux 討論版 / Re: 關於dns反解問題
« 於: 2019-06-22 16:17 »
與 class 無關,如果你的反解 zone 是 172.in-addr.arpa.
那你第一筆的 record 要這樣設:
161.79.17 IN PTR your.forward.dns.name.
(請注意有沒有結尾的小數點)

30
將 redirection 的命令寫進 carte.sh 裏面呢?

頁: [1] 2 3 ... 499