銀河の歴史がまた1ページ(日記)

Last Update (2018/01/17 23:04:21)
1997.09.06から数えて counter 番目のアクセスです。

ミラーサイト [www.ceres.dti.ne.jp] [yk.rim.or.jp]

[ホームページ] [日記] [読んでいる日記] [FreeBSD] [FreeBSD LINK] [検索]

ページ内目次


■ 宇宙暦 2018.01.17

http://www.ceres.dti.ne.jp/~george/jdiaryB80101.html#20180117

2018.01.17(水) GUN RCS を解除するシェル

もうじきFreeBSDからGNU RCSが標準では含まれなくなる(pkgでインストールするようになる)らしいので、 GNU RCSを使っているファイル(自分の環境では設定ファイル)をロック付きでチェックアウトしておくシェルを作成。

function f_gnu_rcs_remove() {
    if [ $# -ge 1 ]; then
        FILE_LIST="$@"
    else
        FILE_LIST=$( find . -name "*,v" -type f )
    fi
    for i in $FILE_LIST
    do
        j=${i%%,v}
        if [ -w $j ]; then
            echo $j is write able.
            /bin/rm -f $i
        else
            co -l $j
            if [ $? -ne 0 ]; then
                echo checkout failed. $i abort.
                return 1
            fi
            /bin/rm -f $i
        fi
    done
    return 0
}

# 実験その1
f_gnu_rcs_remove ./aliases,v

# 実験その2
f_gnu_rcs_remove ./.xinitrc,v

# 一気に行く
f_gnu_rcs_remove


■ 宇宙暦 2018.01.07

http://www.ceres.dti.ne.jp/~george/jdiaryB80101.html#20180107

2018.01.07(日) バーチャルYouTuber

ニコニコ動画のまとめ動画で知ったバーチャルYouTuber。

バーチャルYouTuberの動画いくつか見たけど、それほど面白くない回もあるので、これこそまとめ動画の需要あるんじゃないかなー。

(バーチャルネットアイドルちゆ12さいの方がネタ的には毎回飛ばしてた気がする。)

p.s.

最近のニコ動は無料会員でもシークバー動かせるようになって良かった良かった。 ただ、本当は動画主にゴッソリお金入るようにしてあげないと、YouTuberの方が格上のままだゾ。

p.p.s.

なんか偶然記事になってたww

p.p.p.s.

とりあえず覚えたチャンネルは以下。

さらに追加。歌うバーチャルユーチューバー


■ 宇宙暦 2018.01.04

http://www.ceres.dti.ne.jp/~george/jdiaryB80101.html#20180104

2018.01.04(木) Intel CPUにバグがあって他人の仮想メモリが見物できるという噂

元は4chanの書き込みらしい。それがredditに転載されてちょっとだけ祭りになりつつあるようだ。

元の4chanの書き込みは以下とのこと。

Copying from the thread on 4chan

There is evidence of a massive Intel CPU hardware bug (currently under embargo) that directly affects big cloud providers like Amazon and Google. The fix will introduce notable performance penalties on Intel machines (30-35%).

People have noticed a recent development in the Linux kernel: a rather massive, important redesign (page table isolation) is being introduced very fast for kernel standards... and being backported! The "official" reason is to incorporate a mitigation called KASLR... which most security experts consider almost useless. There's also some unusual, suspicious stuff going on: the documentation is missing, some of the comments are redacted (https://twitter.com/grsecurity/status/947147105684123649) and people with Intel, Amazon and Google emails are CC'd.

According to one of the people working on it, PTI is only needed for Intel CPUs, AMD is not affected by whatever it protects against (https://lkml.org/lkml/2017/12/27/2). PTI affects a core low-level feature (virtual memory) and has severe performance penalties: 29% for an i7-6700 and 34% for an i7-3770S, according to Brad Spengler from grsecurity. PTI is simply not active for AMD CPUs. The kernel flag is named X86_BUG_CPU_INSECURE and its description is "CPU is insecure and needs kernel page table isolation".

Microsoft has been silently working on a similar feature since November: https://twitter.com/aionescu/status/930412525111296000

People are speculating on a possible massive Intel CPU hardware bug that directly opens up serious vulnerabilities on big cloud providers which offer shared hosting (several VMs on a single host), for example by letting a VM read from or write to another one.

まとめると以下のような噂話。

細かい話は見えてこないが、回避策の一つとしては、Knernel Page Table Isolation(PTI)を使うとか。

Intel CPUのバグ対処なら他のOSでもパッチ適用祭りになりそう。 (F0 0F freeze 祭りの時は聞いたこともないようなマイナーOSからもパッチが提供されてた。)

現在は正月休み中ということもあり、大手ニュースサイトでの裏取りできないけど、実際どうなんだろ?

2018.01.04(木) 更新調査ページちょっと変更

読んでいる日記 の取得方法をちょっと変更。

perlを読むのがキツくなったので、Javaでつるっと取得するように変更。

秋葉原値段系のリンクもこちらに統合。

nginxだとHTTPヘッダにLast-Modified返却してくれないのつらみ。

過去に取得したHTTPボディ内容と比較するという悲惨なコトをしているw


■ 宇宙暦 2018.01.02

http://www.ceres.dti.ne.jp/~george/jdiaryB80101.html#20180102

2018.01.02(火) PCのリセットスイッチの取り付け

PCの側面パネルを外してリセットスイッチのピンをマザーに差し込む。 ASUSの場合は、マザーボードのマニュアルPDFが公開されていたので、POWER SWのピン位置はそこで確認。

ケース外面には新たなスイッチをつける箇所がないので、とりあえず5inchベゼルからそのままスイッチをぶらさげる。 data/nikotara.png 328bytes


■ 宇宙暦 2018.01.01

http://www.ceres.dti.ne.jp/~george/jdiaryB80101.html#20180101

2018.01.01(月) あけましておめでとうございます

本年もよろしくお願いいたします data/rei.png 335bytes


■ 宇宙暦 2017.12.30

http://www.ceres.dti.ne.jp/~george/jdiaryB71201.html#20171230

2017.12.30(土) タイガー餃子館で某所の忘年会

その前に、秋葉ヨドバシでMX ERGO MXTB1s(トラックボールマウス)(12,040円)とかHDMI切り替え機(サンワサプライ SW-UHD41H)(8,670円)購入。 MX ERGOは値段見ないで手に取って会計まで持って行ったんだけど、合計金額見てびびったww1万円超えるのか・・・。

あと、IvyBridge機の電源スイッチが壊れたので電源スイッチ購入。さて、どうやって取り付けるかな...。

(このIvyBridge機は色々壊れる不幸艦で、SeagateのHDDとIntelのSSDとAMDのビデオカードが壊れて交換済み。だんだん元々のパーツが無くなりつつあるwww)

最新型のiPad Pro 10.5inchはApple最速CPUを積んでいるので(デレマスとかタイミングがシビアな)スマホゲーム機として有能とか。あと書籍ビューア。

なるほど。

ウチのiPad Pro 10.5inchもあまり出番が無くて家で寝てることがほとんどなので、活用方法をなんとか見つけてやらんとなぁ。 リモートログイン用のターミナルとしては画面が大きいので有能なんだけどね。それ安いWindowsタブでも良くね?という話はあるので。


■ 宇宙暦 2017.12.25

http://www.ceres.dti.ne.jp/~george/jdiaryB71201.html#20171225

2017.12.25(月) iPhoneが突然動かなくなった時に一番最初にしてほしいこと。

tag:iphone

iPhone 6s Plus がいきなり文鎮化して焦る。

電源ボタンとホームボタンを10秒長押し強制リセットでなんとか復活。

ふぅ。まだ2年経ってないんだぜ。


■ 宇宙暦 2017.12.22

http://www.ceres.dti.ne.jp/~george/jdiaryB71201.html#20171222

2017.12.22(金) Apple バッテリーがへたったiPhone6,6s(plus)の速度低下は意図的

バッテリーの寿命は充電回数で判定かな?まだ情報出てないけど。

iPhoneはみんな大事に扱うから中古が大人気だったけど、潰しにきたみたいね。

オレのiPhone 6s PlusもiOS 11アップデートで超遅くなって泣ける。 Geek Benchmark 4.1走らせてみたけど、まだバッテリー由来の速度低下は来てなかったようだけど。

ちなみに、Android機はAndroid 8.1 OLEOに入れ替えたら高速になってあまりの格差に笑うwww

こちらはGeek Benchの作者が明らかにした統計情報。 iOS 11のマイナーバージョンアップによって、iPhone 7でもCPUクロックが制限されるようになった姿がみえる。


■ 宇宙暦 2017.12.21

http://www.ceres.dti.ne.jp/~george/jdiaryB71201.html#20171221

2017.12.21(木) GKEを使ってみる part 3 お値段

tag:gke

5日間くらい走行させてみた結果のお値段が以下。

jdiaryB71221.jpg 166,387bytes

5日で1500円くらい。このままいけば一カ月で9000円くらいかな。

GKEアカウントを取ってすぐ試したので無料トライアル分が残っており請求は0円。

Network Internet Egress from Americas to China と表示されているのはなんだろう? 百度の検索エンジンでも来たかな・・・?

個人でシングルWebサービスを起動して遊ぶにはちょいと高いかしら。


■ 宇宙暦 2017.12.17

http://www.ceres.dti.ne.jp/~george/jdiaryB71201.html#20171217

2017.12.17(日) Google Kubernetes Engine (GKE) 使ってみた (part 3)

Google Kubernetes Engine (GKE) 使ってみた (part 3)

tag:gke

公式ドキュメントに沿って遊んでみる...途中から外れるけど。

Persistent Diskの使用例はいきなり英語になっててワロタw

原文の英語版が凄い勢いで変化するから翻訳するの大変だけどさ。

GKEではvolumeとかsecretsを使う場合は、manifestファイル(APIで送るJSON内容)は手書きか。

実際にGKEを使う人はなんかツール使って自動生成するんだろうけど、あまり人力でやりたくないモノだなぁ。

以下はチュートリアルから離れて俺のwiki向けの操作に改変してある。

  1. Kubernetesクラスタ作る(数分かかる)(diskサイズはGCEの無料枠30GBにしてある。指定しない場合は100GBとなる。)
    gcloud container clusters create persistent-disk-tutorial --zone us-central1-a --machine-type n1-standard-1 --num-nodes 1 --disk-size 30
  2. persistent disk の表示。
    gcloud compute disks list
    以下実行例
    NAME ZONE SIZE_GB TYPE STATUS
    gke-persistent-disk-tuto-default-pool-xxxxxxxx-xxxx us-central1-a 30 pd-standard READY
  3. 現在選択中のコンテキスト名を表示。例:gke_{PROJECT_ID}_{zone}_persistent-disk-tutorial
    kubectl config current-context
  4. メモリの消費量をチェック。いきなり3.75GBノードの半分食われてるように見えるが・・。
    kubectl top node
    以下表示例
    NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
    gke-persistent-disk-tuto-xxxxxxx-xxxx-xxxxxxxx-xxxx 58m 6% 1432Mi 54%
  5. クラスタ情報を表示。GKEは色々動いている。minikubeの場合は1個しか動いていない。
    kubectl cluster-info
    以下表示例
    Kubernetes master is running at https://xx.xxx.xxx.xxx
    GLBCDefaultBackend is running at https://xx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/default-http-backend/proxy
    Heapster is running at https://xx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/heapster/proxy
    KubeDNS is running at https://xx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/kube-dns/proxy
    kubernetes-dashboard is running at https://xx.xxx.xxx.xxx/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
  6. storageclassの存在チェック。GKEはstorageClassName: standardが使えるのね。
    kubectl get storageclasses
    以下表示例。
    NAME PROVISIONER
    standard (default) kubernetes.io/gce-pd

以前のチュートリアルでkubectl run でdocker imageを直接走行させていた時は、自動生成されていたdeployment設定。 今回はvolume周辺の設定が増えているので、残念ながら手動生成となる。 (これくらいの内容ならkubectlで自動生成してくれても良さそうなものだが。)

ここでは、「claim-kjwikigdockerという名前のpersistent volume claimをvolumeとして使う。dockerコンテナからのmount位置は/var/lib/kjwikigdockerだ。」 という記述になっている。

元々のチュートリアル( https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk )では、「volumeとしてgcePersistentDiskを使う」と直接記述している。

これやるとminikubeとか別の環境で動かなくなるので後で面倒くさい感ある。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: kjwikigdocker-deployment
  labels:
    app: kjwiwikigdocker
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kjwikigdocker
  template:
    metadata:
      labels:
        app: kjwikigdocker
    spec:
      containers:
      - name: kjwikigdocker-container
        image: georgesan/kjwikigdocker:latest
        ports:
        - name: kjwikigdocker
          containerPort: 8080
        volumeMounts:
        - name: kjwikig-data-volume
          mountPath: /var/lib/kjwikigdocker
      volumes:
        - name: kjwikig-data-volume
          persistentVolumeClaim:
            claimName: claim-kjwikigdocker

上で「claim-kjwikigdocker」という名前のpersistent volume claimをvolumeとして使う、と言っていた中身を作成。

persistent volume claimという形式を使って、 「Read/Write可能な1GBのディスクが欲しい。ディスクの種類はstandardで良い。1ノードから使えればいい。」 という抽象的な記述になっている。

元々のチュートリアル( https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk )にあるように、 別途GCEに物理ディスクを用意してpersistent volumeとする手もあるのだが、 storageClassName: standardの場合は物理ディスクは自動的に要求(claim)に応じたディスクが用意される。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim-kjwikigdocker
spec:
  # if you ommit storageClassName, standard is default.
  # storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

以前のチュートリアルでは kubectl expose で行っていた操作。serviceの作成。 deployment.yamlを手動で生成してしまったので、自動生成できない。 というわけで手動でAPI用のJSONを作成する。

typeのところは、置く場所(GKE, minikube, ...etc)によって記述が異なる。 standard みたいなデフォルトは無いようだ。

kind: Service
apiVersion: v1
metadata:
  name: kjwikigdocker
  labels:
    app: kjwikigdocker
spec:
  # type ClusterIP(default) / NodePort(for minikube) / LoadBalancer(for GKE)
  type: LoadBalancer
  selector:
    app: kjwikigdocker
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080

操作の続き。

  1. persistent volume claim の作成
    kubectl apply -f kjwikigdocker-standard-pvc.yaml
  2. persistent disk の表示。
    gcloud compute disks list
    以下表示例。1GBで別領域が作られてる。
    NAME ZONE SIZE_GB TYPE STATUS
    gke-persistent-disk-tu-pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx us-central1-a 1 pd-standard READY
    gke-persistent-disk-tuto-default-pool-xxxxxxxx-xxxx us-central1-a 30 pd-standard READY
  3. deployment の作成
    kubectl apply -f kjwikigdocker-deployment.yaml
  4. serviceの作成。GCEの有料オプションであるLoadBalancerを指定している。(俺のwikiはPod増やすと正常動作しなくなるから、ロードバランサー不要だけどなー)
    kubectl apply -f kjwikigdocker-service.yaml
  5. アプリの外部 IP アドレス(EXTERNAL-IP)をコピー。(ちょっと時間がかかる。Pendingならしばらく待ってもう一度。)
    kubectl get service kjwikigdocker
  6. アプリを表示(EXTERNAL-IP を前のステップで取得した外部 IP アドレスに置き換える)。
    http://EXTERNAL-IP:8080/
  7. メモリの消費量をチェック。(アプリが起動した状態。ここでは2112Miほど。79%。)
    kubectl top node
  8. 作成したサービスを削除して、サービスを提供するようにプロビジョニングされた負荷分散リソースを削除します。
    kubectl delete svc/kjwikigdocker deploy/kjwikigdocker-deployment
  9. サービスが停止するまで待ちます。
    kubectl get all,svc
  10. メモリの消費量をチェックします。
    kubectl top node
  11. サービスが終了するまで数分待ってから、次のコマンドを使用して作成したクラスタを削除します。
    gcloud container clusters delete persistent-disk-tutorial --zone us-central1-a
  12. persistentVolumeClaimに応じて別領域に作られたディスクの表示
    gcloud compute disks list
  13. persistentVolumeClaimに応じて別領域に作られたディスクの削除
    gcloud compute disks delete gke-persistent-disk-tu-pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx --zone us-central1-a

このまま1週間くらい動かしてGKEの課金額の推移みてみるか。 ログがどんな風にstack driverに出てくるのかも見物したいし。

しかし、上の手順、かなり多いよなww VPS(Virtual Private Server)でroot権もらってtomcatインストールした方が手数少なくない?と思わないでもないwww


old day diaries...


日記ファイルリスト最新100件


Copyright(c) 1996-2018 George(小濱 純). All rights reserved.
私の作成したページへのリンクはご自由にどうぞ。
このページに間違いや要望などがありましたら george@yk.rim.or.jp まで御連絡ください。
メール本文に 6020-5440-3372 と書いて頂くと、ウチのSPAMフィルタを通過できます(2009-06-14から2018-12-31まで)。

[ホームページ] [日記] [読んでいる日記] [FreeBSD] [FreeBSD LINK] [検索]

home: <george@yk.rim.or.jp> or <george@ceres.dti.ne.jp>
(I am using white list SPAM filter. To avoid it, please write 6020-5440-3372 in mail body. This key word is valid since 2009-06-14 until 2015-12-31.)