- 投稿日：2019-12-05T21:34:13+09:00
Fedora31 でビデオを見る
ちょっと暇ができたので、前に使っていて、画面にひびが入ってしまったノートパソコン（dynabook T3/68JW) に fedora31 を入れ直しました。
僕は、パソコンを買ったらまず入っていた OS を削除して Linux を入れるのですが、このノートパソコンは、なぜか起動しなくなっていて、それを、また別の Dell のノートパソコンから外したハードディスクを付け直していたのでした。
また別に使っている 17インチのノートパソコンで Fedora31 デスクトップをダウンロードして、brasero で焼いて LiveDVD を作成し、この dynabook に挿入して、Fedora をインストールしたのでした。
メモリは、8G とけっして多くはない（普段使っている 17インチのノートパソコンは 32G）のですが、資源を有効利用するにはいいと思います。
まずは、dnf update コマンドを実行してパッケージ群を最新にします。そして、Video を見ようと思ったのですが、firefox のエラーになって、うまくいきません。
これは何の問題なのか、wayland を /etc/gdm/custom.conf で無効にしてみたり、flash を入れてみてもダメです。
そこで、うまく見られている 17インチのノートパソコンで、yum list | grep fusion とすると、mplayer というのがインストールされているようです。
以下のコマンドを実行して、rpm-fusion リポジトリを有効にしました。
（参考）
https://docs.fedoraproject.org/en-US/quick-docs/setup_rpmfusion/$ sudo dnf install \ https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpmそして、以下のコマンドを実行しました。
$ sudo dnf install mplayermplayer をインストール後は、Fedora31 でビデオが見られるようになりました。
ここで、インストールされているパッケージのうち、feodora や anaconda 以外のものを表示してみました。
$ less yum_list_installed | grep -v anaconda|grep -v fedora|grep -v updates インストール済みパッケージ adobe-release-x86_64.noarch 1.0-1 @System librtmp.x86_64 2.4-15.20190330.gitc5f04a5.fc31 @rpmfusion-free mplayer.x86_64 1.4-3.fc31 @rpmfusion-free mplayer-common.x86_64 1.4-3.fc31 @rpmfusion-free opencore-amr.x86_64 0.1.5-8.fc31 @rpmfusion-free rpmfusion-free-release.noarch 31-1 @@commandline rpmfusion-nonfree-release.noarch 31-1 @@commandline vo-amrwbenc.x86_64 0.1.3-10.fc31 @rpmfusion-free x264-libs.x86_64 0.157-12.20190717git34c06d1.fc31 @rpmfusion-free x265-libs.x86_64 3.1.2-2.fc31 @rpmfusion-free xvidcore.x86_64 1.3.5-6.fc31 @rpmfusion-freeあ、non-free リポジトリもインストールしていたようです。
ともかく、ビデオがみられるようになってよかったぁ。
- 投稿日：2019-12-05T19:52:12+09:00
Windows10 , CentOSのデュアルブート
はじめに
仮想環境だとリソースが不足しそうなのでデュアルブート構成にして動くようにしたかったのだけど、調べてみると Windowsが新しくなってからは修正適用で起動できなくなるなどのトラブルがある様です。デュアルブート部分を仮想環境で試してみます。
環境
ホスト
- Windows 10 Home
仮想環境
- Virtual Box 6.0
- Windows 10 Enterprise Evaluation
- CentOS 8.0
仮想環境でうまく動いたらホストをデュアルブートにします。
ホストの環境確認と事前準備
UEFIが有効かをPowerShellで確認します。*管理者での起動が必要です。
パーティションをPCの管理メニューから確認するだけでもできます。有効な場合はUEFI用のパーティションがあります。Confirm-SecureBootUEFIPS C:\WINDOWS\system32> Confirm-SecureBootUEFI True PS C:\WINDOWS\system32>この設定にあわせて Virtual BoxのVM設定を変更します。
デュアルブートだとトラブルが多いようなので、Windowsの設定項目から「高速スタートアップ」を無効にしておきます。
デュアルブートインストール
- VMにWindows10を入れる
- 同じVMにディスクを追加する
- CentOSを入れる
CentOSインストール時にパーティションの設定で追加したディスクが Boot Deviceになっていることを確認します。なっていない場合、Set as Boot Deviceボタンを押します。
CentOSを入れたばかりなので、GRUB2が起動します。何度か試しましたが、リブートだと直前に起動したOSが起動してきます。シャットダウンだとDISK1にれたWindowsが起動します。普段はWindowsなのでLinuxが起動してきたときにもデフォルトではWindowsが起動するように GRUB2を変更します。
このメニューだと上から3番目なので、0,1,2 で 2を指定します。
# grub2-set-default 2DISK2の CentOS を起動させるときはBIOSで選択する必要があるので、BIOSメニューを表示するキーを覚えておくといいです。Virtual BoxだとF12です。
メモ
UEFIが有効な場合 MBRやPBRのddでの抜き出しでのファイル登録はする必要はありませんでした。別ディスクにして起動時にBIOSで選べる環境ならこの方法がトラブルもなさそうです。
参考
- 投稿日：2019-12-05T16:58:35+09:00
CentOS7でGuestAdditionsを導入し、マウスの統合と解像度の自動リサイズを有効にする。
どんな方に向けての記事か
CentOS7とVirtualBoxを使い仮想環境を作ってみたけど、ホストキー押さないとポインタが元OSに戻ってこれない、画面の調整の仕方がわからない方に向けた記事です。
動作環境
Windows10,64bit
Oracle VirtualBox 6.0.14
CentOS-7x86_64-DVD-1908 linux redhat64bit記事を書いた理由
先日、CentOS7を使ってlinuxの仮想環境を作ったのですが、ポインタの操作や画面サイズが使いにくいと感じたので、調べたとこところマウスの統合と解像度の自動リサイズのタブを有効にすれば解決できることを知りました。これらを有効にするにはGuestAdditonを仮想環境に入れることで解決できるようです。これはvirtualboxのタブにある、デバイス>GuestAddtions CD イメージの挿入から実行できます。しかし、これを行っても変更が反映されなかったので同じように詰まった方の助けになればと思い、記事を書きました。
行ったこと
https://youtu.be/EdX-2ci1XtQ を参考にインストールを行いました。
$su $ping -c 3 www.google.com $uname -a $yum update kernel -y $reboot $su $yum install gcc kernel-devel kernel-headerここまで行ったところでGuestAddtions CD イメージの挿入を行います。
virtualboxのタブにある、デバイス>GuestAddtions CD イメージの挿入から実行できます。
ポップアップの実行を押すと実行されます。
$rebootそして再び再起動すると設定変更できるようになっています。
- 投稿日：2019-12-05T16:54:07+09:00
App Service 小ネタ集
※この記事は Microsoft Azure Tech Advent Calendar 2019 の 5 日目の記事です。
Azure App Service で時々耳にする質問を少しピックアップしてまとめましたので、ご参考にしていただければ。
その 1: 「PremiumV2 にスケールアップできない！」
# あまり最近は聞かないですが。
マルチテナント(ASE 以外) のApp Service のスケールにはいくつかスペックのグレードが存在し、その最上位のスペックは PremiumV2 プランです。
PremiumV2 プランが選択可能かどうかで、利用できる機能に差があります。
その一つが、App Service の新しい VNet 統合（「リージョン VNet 統合」と呼ばれます）です。リージョン VNet 統合を使うために、その App Service が PremiumV2 で動作している必要はありません。
ですが、PremiumV2 プランをサポートしたスケール ユニット上にデプロイされている必要があります (Azure ポータルの [スケール アップ] のブレードにて、PremiumV2 へのスケール アップが可能かどうか)。
- リージョン VNet 統合 - アプリと Azure 仮想ネットワークを統合する - Azure App Service | Microsoft Docs
https://docs.microsoft.com/ja-jp/azure/app-service/web-sites-integrate-with-vnet#regional-vnet-integrationこの機能は、PremiumV2 の App Service プランをサポートする新しい App Service スケール ユニットからのみ使用できます。
スケール ユニットについては、こちらに説明があるので、参考にしていただきたいのですが、実は、PremiumV2 プランが利用できるかどうかは、App Service がデプロイされたスケール ユニットに関係しており、そして そのスケール ユニットは最初のデプロイ時に決定します。
ですので、後から PremiumV2 (もしくはそれに関連した機能) が必要になりそうであれば、最初のデプロイ時に PremiumV2 プランを選びましょう。
確実に PremiumV2 が利用可能なスケール ユニットにデプロイされます。
# デプロイに失敗したら、慌てずリトライしてください。なおデプロイが完了後、PremiumV2 を維持する理由は特にないのであれば、サクっと Standard などにスケール ダウンしておきましょう。
その 2: 「Linux 版の App Service で Web ジョブを使いたい！」
Windows 版の App Service には、Web ジョブという機能があり、バックグラウンドで定期的な処理を実行することができます。
ログ ファイルの移動とかで使われている方がいるかと思います。一方で、App Service には Linux 版 (App Service on Linux) もありますが、残念ながらこちらには Web ジョブのような仕組みは用意していません。
ですが、App Service on Linux では Docker コンテナー 1 上でスタートアップ スクリプトを介して Web アプリケーションを起動することができるので、ちょっとした追加であれば、スタート アップ スクリプトを工夫することで、前処理の処理が可能です。
このスタート アップ スクリプトの仕組みを使って、Web アプリケーションの起動のタイミングで cron をインストールし、適当なジョブを設定してみます。
cron の追加インストール＆起動手順
既定のスタートアップ スクリプト
/opt/startup/startup.shをコピーする。cp /opt/startup/startup.sh /home/start.sh多くの場合コピーしたスクリプト
/home/start.shの最後の行が Web アプリケーションの起動コマンドになるので、最後の行を残して削除し、その直前に追加の処理 (cron のインストールや追加設定など) を記載する。/home/start.shapt update && apt install cron -y # cron のインストール service cron start # cron の起動 echo "*/5 * * * * sh /home/job.sh" | crontab # cron のスケジュール設定 npm start # Web アプリケーションの起動 (node.js の場合)※
/home/job.shは実行させたい処理を記載したシェル スクリプトAzure ポータルより、1. で作成した
/home/start.shを "スタートアップ コマンド" として設定して、再起動する
正常に動作すると、以下のようなプロセス ツリーになります。
ProcessTree/home# pstree -a bash /opt/startup/init_container.sh sh /home/start.sh |-cron |-sshd (snipped) | `-startup.sh /opt/startup/startup.sh `-sh /home/start.sh `-npm (snipped)cron のプロセスや、既定の
/opt/startup/startup.shの下にカスタムのスタートアップ スクリプト/home/start.sh、さらにその下に、Web アプリケーション起動コマンド (npm) が確認できます。上記の例は、cron を入れて Web ジョブもどき実現する方法ですが、同じようにスタートアップ スクリプトでその他にも Web アプリケーションの起動前に各種の設定値を編集することもできます。
例えば、下記のブログには、PHP の Docker イメージをベースとして、X-Powered-By ヘッダーを表示しないように、起動前に設定ファイルを編集する方法が記載されています。
- Custom Startup script for PHP – Azure App Service Linux – HTTP Stack and other fun things I support
http://jsandersblog.azurewebsites.net/2019/08/06/custom-startup-script-for-php-azure-app-service-linux/
前処理として、外部からソースをダウンロードしてコンパイル、みたいなこともやろうと思えばできるかもしれませんが、あまり重たい前処理を入れると、初回リクエストの起動処理に時間がかかってしまいますので、お勧めはしません。
その場合は、カスタム コンテナーと Web App for Containers の利用も検討してください。以上、Azure App Service の小ネタでした。
App Service on Linux は、マイクロソフトから提供される各ランタイム言語向けの Docker イメージ (Blessed Images) をベースとした Docker コンテナーを起動しています ↩
- appsvc's Profile - Docker Hub
https://hub.docker.com/u/appsvc- Azure App Service - GitHub
https://github.com/Azure-App-Service
- 投稿日：2019-12-05T15:35:59+09:00
Linux上でLiveUSB作成
- PCにUSBを接続したら
lsblk -fでUSBのパスを確認コピペumount /USBのパスでUSBをアンマウントsudo dd bs=4M if=/ISOの保存場所 of=/USBのパス status=progress && sync- records in records out の文字が出たら完了
- 投稿日：2019-12-05T14:27:58+09:00
DataCore vFilOのShareをNFS4.2でマウントしてみる
さっそくやってみます。
vFilOの準備と確認
IPアドレスの確認
まずはvFilO側の確認。
Cluster floating IPs: [192.168.4.200/24, 10.10.107.200/21]
この行のIPでマウントします。2個目のアドレスはマネジメントなので使いません。admin@anvil3.datacore.jp> cluster-view ID: （削除） Name: CLUSTER3 State: High Availability IP: 10.10.107.200/21 Cluster floating IPs: [192.168.4.200/24, 10.10.107.200/21] Portal floating IPs: [192.168.5.200/24] Since: 2019-12-04 08:27:26 UTC Timezone: Asia/Tokyo VVOL support: true EULA accepted date: 2019-12-04 08:29:26 UTC Online activation support: true License expiration date: 2020-01-03 08:27:26 UTC NAS volume capacity: [Total: 959.7GB, Used: 6.8GB, Free: 952.9GB] Share space (quota): [Total: 1TB, Used: 0B, Free: 1TB] Data directors: [Object type: DATA_SPHERE, Node name: anvil4.datacore.jp, Role: SECONDARY, Oper state: UP, Admin state: UP] [Object type: DATA_SPHERE, Node name: anvil3.datacore.jp, Role: PRIMARY, Oper state: UP, Admin state: UP] admin@anvil3.datacore.jp>今回の構成とノード一覧
ちなみに今回のクラスターはAnvilのメタデータはVNMeを、DSXのデータは生SSDをパスするーでアタッチしています。
ネットワークインターフェイスは全てSR-IOVで25Gb NICのVFを直接見せています。vSwitchは通していません。admin@anvil3.datacore.jp> node-list total 6 Name: anvil4.datacore.jp Type: Product Internal ID: 1073741829 ID: f0b912a2-4a39-5a6a-98e3-57fd9b371664 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.204/21 SW version: 4.2.1-41 Name: anvil3.datacore.jp Type: Product Internal ID: 1073741832 ID: be9d4b3a-3db8-5231-abda-f551a9481425 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.203/21 SW version: 4.2.1-41 Name: dsx1-1.datacore.jp Type: Product Internal ID: 1073741836 ID: eb6da562-672f-5a0e-a2aa-7793bfad5ce4 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.211/21 SW version: 4.2.1-41 Name: dsx2-1.datacore.jp Type: Product Internal ID: 1073741840 ID: b460f7e9-19b5-5d2f-b9e7-765d60468438 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.221/21 SW version: 4.2.1-41 Name: dsx1-2.datacore.jp Type: Product Internal ID: 1073741845 ID: 04ef7678-a610-52ff-8fda-873c5cbfc4ab HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.212/21 SW version: 4.2.1-41 Name: dsx2-2.datacore.jp Type: Product Internal ID: 1073741861 ID: 035fead9-9f57-5be7-9de9-48db15f81990 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.222/21 SW version: 4.2.1-41Shareの確認
GUIで適当に作ります。今回はshare1にしました。
確認コマンド
admin@anvil3.datacore.jp> share-list --name share1 ID: 9eb6084e-98d1-4995-a2c1-1d1385476f76 Name: share1 Internal ID: 2 State: PUBLISHED Path: /share1 All applied objectives: [ID: be321c5e-0edd-4e4d-8fff-2406daa87c52, Internal ID: 536870912, Name: keep-online] [ID: 3b0e981f-6f21-4b5a-80fa-d7f94681bb9c, Internal ID: 536870914, Name: optimize-for-capacity] [ID: d45d8170-44ae-4b99-8b85-e935d9f3fcc6, Internal ID: 536870915, Name: delegate-on-open] [ID: bc945b58-e3d7-4cac-9f29-0387a6dde0bc, Internal ID: 536870916, Name: layout-get-on-open] [ID: 5d30faed-b46a-4a0a-9db3-b2c3a3734be9, Internal ID: 536870918, Name: durability-1-nine] [ID: 0b0e149d-3bf2-46dc-b2f6-5dc767f1ec38, Internal ID: 536870922, Name: availability-1-nine] [ID: 0e685071-2730-4cda-96dc-705edb321bf7, Internal ID: 536870919, Name: durability-3-nines] Active objectives: [ID: 3b0e981f-6f21-4b5a-80fa-d7f94681bb9c, Internal ID: 536870914, Name: optimize-for-capacity] [ID: d45d8170-44ae-4b99-8b85-e935d9f3fcc6, Internal ID: 536870915, Name: delegate-on-open] Size: 1TB Warn when size crosses: 90% Size limit state: NORMAL Export options: [Subnet: *, Access permissions: RW, Root-squash: false] Participant ID: 0 Replication participants: ID: 00bba667-737a-47de-a715-dbe2072dc3b8 Participant share internal ID: 2 Participant site name: CLUSTER3 Participant site management address: 10.10.107.200 Participant site data address: 192.168.4.200 Participant ID: 0 admin@anvil3.datacore.jp>NFSクライアントの準備
適当に好きなLinuxをインストールします。
今回はCentOS7を使いました。# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core ドライバ更新 # yum install /tmp/kmod-qlgc-fastlinq-8.42.9.0-1.rhel7u7.x86_64.rpm （略） # nmcli ens192: 接続済み to ens192 "QLogic FastLinQ QL45000" ethernet (qede), 00:0C:29:13:59:0C, hw, ポート 000e1ed3db68, mtu 1500 inet4 192.168.4.101/24 route4 192.168.4.0/24 inet6 fe80::97f3:ab5c:4725:2edc/64 route6 fe80::/64 route6 ff00::/8 # # yum install nfs-utils （略） # mount -t nfs -o v4.2 192.168.4.200:/share1 /mnt # # mount （略） 192.168.4.200:/share1 on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.4.101,local_lock=none,addr=192.168.4.200) # # df -h ファイルシス サイズ 使用 残り 使用% マウント位置 192.168.4.200:/share1 932G 0 932G 0% /mnt早速のぞいてみます。
# ls /mnt # ls /mnt/.snapshot/ current # ls /mnt/.snapshot/current/ # ls /mnt/.collections/ all live open silent-access assimilation-failed misaligned permanent-data-loss snapshot backup not-selected replication-collision undelete do-not-move not-selected2 scan volatile durable offline selected errored online selected2ファイルは何もありませんが、NFSだといろいろと見れますね。
工夫して使ってみて下さい。書き込みを試してみます。
# vi /etc/security/limits.conf * soft nofile 65536 * hard nofile 65536 # ulimit -n 65536 # cd /tmp # echo {1..1000} | tee testfile{0..65535}約4KBのファイルが約6万個作られます。
次回に続く。
参考文献
http://akishin.hatenablog.jp/entry/20130213/1360711554
https://qiita.com/kainos/items/5d8c47e64b5b06a60d0e
- 投稿日：2019-12-05T14:27:58+09:00
DataCore vFilOのShareをNFS4.2(pNFS)でマウントしてみる
さっそくやってみます。
vFilOの準備と確認
IPアドレスの確認
まずはvFilO側の確認。
Cluster floating IPs: [192.168.4.200/24, 10.10.107.200/21]
この行のIPでマウントします。2個目のアドレスはマネジメントなので使いません。admin@anvil3.datacore.jp> cluster-view ID: （削除） Name: CLUSTER3 State: High Availability IP: 10.10.107.200/21 Cluster floating IPs: [192.168.4.200/24, 10.10.107.200/21] Portal floating IPs: [192.168.5.200/24] Since: 2019-12-04 08:27:26 UTC Timezone: Asia/Tokyo VVOL support: true EULA accepted date: 2019-12-04 08:29:26 UTC Online activation support: true License expiration date: 2020-01-03 08:27:26 UTC NAS volume capacity: [Total: 959.7GB, Used: 6.8GB, Free: 952.9GB] Share space (quota): [Total: 1TB, Used: 0B, Free: 1TB] Data directors: [Object type: DATA_SPHERE, Node name: anvil4.datacore.jp, Role: SECONDARY, Oper state: UP, Admin state: UP] [Object type: DATA_SPHERE, Node name: anvil3.datacore.jp, Role: PRIMARY, Oper state: UP, Admin state: UP] admin@anvil3.datacore.jp>今回の構成とノード一覧
ちなみに今回のクラスターはAnvilのメタデータはVNMeを、DSXのデータは生SSDをパスするーでアタッチしています。
ネットワークインターフェイスは全てSR-IOVで25Gb NICのVFを直接見せています。vSwitchは通していません。admin@anvil3.datacore.jp> node-list total 6 Name: anvil4.datacore.jp Type: Product Internal ID: 1073741829 ID: f0b912a2-4a39-5a6a-98e3-57fd9b371664 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.204/21 SW version: 4.2.1-41 Name: anvil3.datacore.jp Type: Product Internal ID: 1073741832 ID: be9d4b3a-3db8-5231-abda-f551a9481425 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.203/21 SW version: 4.2.1-41 Name: dsx1-1.datacore.jp Type: Product Internal ID: 1073741836 ID: eb6da562-672f-5a0e-a2aa-7793bfad5ce4 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.211/21 SW version: 4.2.1-41 Name: dsx2-1.datacore.jp Type: Product Internal ID: 1073741840 ID: b460f7e9-19b5-5d2f-b9e7-765d60468438 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.221/21 SW version: 4.2.1-41 Name: dsx1-2.datacore.jp Type: Product Internal ID: 1073741845 ID: 04ef7678-a610-52ff-8fda-873c5cbfc4ab HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.212/21 SW version: 4.2.1-41 Name: dsx2-2.datacore.jp Type: Product Internal ID: 1073741861 ID: 035fead9-9f57-5be7-9de9-48db15f81990 HW state: OK Node state: MANAGED Node mode: ONLINE Management IP: 10.10.107.222/21 SW version: 4.2.1-41Shareの確認
GUIで適当に作ります。今回はshare1にしました。
確認コマンド
admin@anvil3.datacore.jp> share-list --name share1 ID: 9eb6084e-98d1-4995-a2c1-1d1385476f76 Name: share1 Internal ID: 2 State: PUBLISHED Path: /share1 All applied objectives: [ID: be321c5e-0edd-4e4d-8fff-2406daa87c52, Internal ID: 536870912, Name: keep-online] [ID: 3b0e981f-6f21-4b5a-80fa-d7f94681bb9c, Internal ID: 536870914, Name: optimize-for-capacity] [ID: d45d8170-44ae-4b99-8b85-e935d9f3fcc6, Internal ID: 536870915, Name: delegate-on-open] [ID: bc945b58-e3d7-4cac-9f29-0387a6dde0bc, Internal ID: 536870916, Name: layout-get-on-open] [ID: 5d30faed-b46a-4a0a-9db3-b2c3a3734be9, Internal ID: 536870918, Name: durability-1-nine] [ID: 0b0e149d-3bf2-46dc-b2f6-5dc767f1ec38, Internal ID: 536870922, Name: availability-1-nine] [ID: 0e685071-2730-4cda-96dc-705edb321bf7, Internal ID: 536870919, Name: durability-3-nines] Active objectives: [ID: 3b0e981f-6f21-4b5a-80fa-d7f94681bb9c, Internal ID: 536870914, Name: optimize-for-capacity] [ID: d45d8170-44ae-4b99-8b85-e935d9f3fcc6, Internal ID: 536870915, Name: delegate-on-open] Size: 1TB Warn when size crosses: 90% Size limit state: NORMAL Export options: [Subnet: *, Access permissions: RW, Root-squash: false] Participant ID: 0 Replication participants: ID: 00bba667-737a-47de-a715-dbe2072dc3b8 Participant share internal ID: 2 Participant site name: CLUSTER3 Participant site management address: 10.10.107.200 Participant site data address: 192.168.4.200 Participant ID: 0 admin@anvil3.datacore.jp>NFSクライアントの準備
適当に好きなLinuxをインストールします。
今回はCentOS7を使いました。# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core ドライバ更新 # yum install /tmp/kmod-qlgc-fastlinq-8.42.9.0-1.rhel7u7.x86_64.rpm （略） # nmcli ens192: 接続済み to ens192 "QLogic FastLinQ QL45000" ethernet (qede), 00:0C:29:13:59:0C, hw, ポート 000e1ed3db68, mtu 1500 inet4 192.168.4.101/24 route4 192.168.4.0/24 inet6 fe80::97f3:ab5c:4725:2edc/64 route6 fe80::/64 route6 ff00::/8 # # yum install nfs-utils （略） # mount -t nfs -o v4.2 192.168.4.200:/share1 /mnt # # mount （略） 192.168.4.200:/share1 on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.4.101,local_lock=none,addr=192.168.4.200) # # df -h ファイルシス サイズ 使用 残り 使用% マウント位置 192.168.4.200:/share1 932G 0 932G 0% /mnt # lsmod | grep nfs_layout_flexfiles nfs_layout_flexfiles 43542 1 nfsv4 583218 2 nfs_layout_flexfiles nfs 261876 4 nfsv3,nfsv4,nfs_layout_flexfiles sunrpc 354099 19 nfs,rpcsec_gss_krb5,auth_rpcgss,lockd,nfsv3,nfsv4,nfs_layout_flexfiles,nfs_acl早速のぞいてみます。
# ls /mnt # ls /mnt/.snapshot/ current # ls /mnt/.snapshot/current/ # ls /mnt/.collections/ all live open silent-access assimilation-failed misaligned permanent-data-loss snapshot backup not-selected replication-collision undelete do-not-move not-selected2 scan volatile durable offline selected errored online selected2ファイルは何もありませんが、NFSだといろいろと見れますね。
工夫して使ってみて下さい。書き込みを試してみます。
# vi /etc/security/limits.conf * soft nofile 65536 * hard nofile 65536 # ulimit -n 65536 # cd /tmp # echo {1..1000} | tee testfile{0..65535}約4KBのファイルが約6万個作られます。
次回に続く。
参考文献
http://akishin.hatenablog.jp/entry/20130213/1360711554
https://qiita.com/kainos/items/5d8c47e64b5b06a60d0e
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/storage_administration_guide/nfs-pnfs
- 投稿日：2019-12-05T09:23:23+09:00
Linuxとかの、/etcとか/var/logとかいうディレクトリってなんだ？
はじめに
Linux等の、*Nix系OSを使い始めた人向けに。
Linuxを初めて触った時や、まだ慣れない時に、「なにがどこにあるかよくわからない」とか「そもそもなにがあるかわからない」とか、「ログを読め」とか言われるけどログってどこにあるの？？？とか思うことがあると思います。
で、慣れてくると「なんかログは
/var/logディレクトリにあるらしい」とか、「設定ファイルは/etcにあるらしい」とかをなんとなく知ったり、覚えたりしていきます。このディレクトリについてのお話。
Filesystem Hierarchy Standard
これ、「Filesystem Hierarchy Standard」という名前で標準化されています。
Filesystem Hierarchy Standard / Wikipedia
Wikipediaより。
Filesystem Hierarchy Standard(ファイルシステム・ヒエラルキー・スタンダード、FHS、ファイルシステム階層標準）は、Linuxを含むUNIX系オペレーティングシステムでの主なディレクトリとその内容を定めたものである。
現在のFilesystem Hierarchy Standardのバージョンは、3.0です。
Filesystem Hierarchy Standard Specifications Archive
The Filesystem Hierarchy Standard (FHS)
バージョン 3.0の仕様から、いくつか見てみましょう。
Filesystem Hierarchy Standard Version 3.0
/… ルートファイルシステム The Root Filesystem/home… ユーザーのホームディレクトリ User home directories (optional)/etc… 設定ファイルを置くディレクトリ Host-specific system configuration/bin… すべてのユーザーで必要となるコマンドを置くディレクトリEssential user command binaries (for use by all users)/usr/bin… 多くのユーザーが使うコマンドを置くディレクトリ Most user commands/var/log… ログファイルを置くディレクトリ Log files and directoriesなどなど。
この仕様書の目次（の他にも、Wikipediaなど）に書かれているディレクトリをさらっと眺めてみるだけでも、「このディレクトリ、見たことある」といった印象を持ったりするのではないでしょうか？
また、
yumやaptといった、各Linuxディストリビューションのパッケージマネージャーを使ってインストールされるパッケージなどもFilesystem Hierarchy Standardに従ったものが多いので、これに慣れるとなんとなく「設定ファイルは/etc/fooにあるんだろう」とか、「ログは/var/log/barにあるんだろう」といった推測が立てられるようになり、理解が早くなりますね。自分でファイルを置いたり作ったりする場合も、このあたりのディレクトリ構成を意識するようにすると、他の人が後から見ても意図が伝わりやすかったりするでしょう。
環境変数
PATHここからは、少しオマケ的に。
よく「
PATHを通す」とか言われるやつですね。この環境変数に:区切りで設定したディレクトリ内にあるコマンドは、シェルがパスを解決することができます。例えばVagrantで起動した仮想マシン（CentOS 7）ですが、環境変数
PATHの内容を表示してみます。$ echo $PATH /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/vagrant/.local/bin:/home/vagrant/binこれを見ると、
/usr/local/binや/usr/local/sbin配下にもパスが通っていて、デフォルトではこれらのディレクトリ内にはなにもないのですが、ユーザーがコマンドを配置することで全体で使える共通的なコマンドをインストールすることができます。$ ll /usr/local/bin total 0
docker-composeとかが、/usr/local/binディレクトリを使ったインストール例になっていますね。$ sudo curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose一般ユーザーに、どのようなパスが設定されるのかは
$HOME/.bashrc、$HOME/.bash_profile、/etc/bashrc、/etc/profileなどを見ることになります。ところで、
rootユーザーだと環境変数PATHに設定されている内容が、少し変わります。# echo $PATH /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/binこのあたりですね。
/sbinこれは、
/sbinがシステム管理者用のコマンドを置くディレクトリだからですね。あとは、
/usr/local/sbinが/usr/local/binの前にあるなど、細かく違ったりもします。/usr/local/sbin:/usr/local/bin
systemctl/journalctlでサービスの状態やログを見るログファイルを見る以外にも、サービス（デーモンプロセス）の状態を確認したり、システムのログを確認したりすることが
systemctl、journalctlを使って行うことができます。サービスの状態を確認する。
$ sudo systemctl status [ユニット名]サービスやOSの出力したログを確認する。
# サービスユニットを指定してログを見る $ sudo journalctl -u [ユニット名] # カーネルログを見る $ sudo journalctl -k # 全ログを出力 $ sudo journalctlこのあたりの情報を押さえつつ、ログを見たりしつつ、少しずつLinuxに慣れて強くなっていくとよいでしょう。
そして、より強い相手に立ち向かっていきましょう。
- 投稿日：2019-12-05T09:23:23+09:00
/etcとか/var/logとかいうディレクトリってなんだ？
はじめに
Linux等の、*Nix系OSを使い始めた人向けに。
Linuxを初めて触った時や、まだ慣れない時に、「なにがどこにあるかよくわからない」とか「そもそもなにがあるかわからない」とか、「ログを読め」とか言われるけどログってどこにあるの？？？とか思うことがあると思います。
で、慣れてくると「なんかログは
/var/logディレクトリにあるらしい」とか、「設定ファイルは/etcにあるらしい」とかをなんとなく知ったり、覚えたりしていきます。このディレクトリについてのお話。
Filesystem Hierarchy Standard
これ、「Filesystem Hierarchy Standard」という名前で標準化されています。
Filesystem Hierarchy Standard / Wikipedia
Wikipediaより。
Filesystem Hierarchy Standard(ファイルシステム・ヒエラルキー・スタンダード、FHS、ファイルシステム階層標準）は、Linuxを含むUNIX系オペレーティングシステムでの主なディレクトリとその内容を定めたものである。
現在のFilesystem Hierarchy Standardのバージョンは、3.0です。
Filesystem Hierarchy Standard Specifications Archive
The Filesystem Hierarchy Standard (FHS)
バージョン 3.0の仕様から、いくつか見てみましょう。
Filesystem Hierarchy Standard Version 3.0
/… ルートファイルシステム The Root Filesystem/home… ユーザーのホームディレクトリ User home directories (optional)/etc… 設定ファイルを置くディレクトリ Host-specific system configuration/bin… すべてのユーザーで必要となるコマンドを置くディレクトリEssential user command binaries (for use by all users)/usr/bin… 多くのユーザーが使うコマンドを置くディレクトリ Most user commands/var/log… ログファイルを置くディレクトリ Log files and directoriesなどなど。
この仕様書の目次（の他にも、Wikipediaなど）に書かれているディレクトリをさらっと眺めてみるだけでも、「このディレクトリ、見たことある」といった印象を持ったりするのではないでしょうか？
また、
yumやaptといった、各Linuxディストリビューションのパッケージマネージャーを使ってインストールされるパッケージなどもFilesystem Hierarchy Standardに従ったものが多いので、これに慣れるとなんとなく「設定ファイルは/etc/fooにあるんだろう」とか、「ログは/var/log/barにあるんだろう」といった推測が立てられるようになり、理解が早くなりますね。自分でファイルを置いたり作ったりする場合も、このあたりのディレクトリ構成を意識するようにすると、他の人が後から見ても意図が伝わりやすかったりするでしょう。
環境変数
PATHここからは、少しオマケ的に。
よく「
PATHを通す」とか言われるやつですね。この環境変数に:区切りで設定したディレクトリ内にあるコマンドは、シェルがパスを解決することができます。例えばVagrantで起動した仮想マシン（CentOS 7）ですが、環境変数
PATHの内容を表示してみます。$ echo $PATH /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/vagrant/.local/bin:/home/vagrant/binこれを見ると、
/usr/local/binや/usr/local/sbin配下にもパスが通っていて、デフォルトではこれらのディレクトリ内にはなにもないのですが、ユーザーがコマンドを配置することで全体で使える共通的なコマンドをインストールすることができます。$ ll /usr/local/bin total 0
docker-composeとかが、/usr/local/binディレクトリを使ったインストール例になっていますね。$ sudo curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose一般ユーザーに、どのようなパスが設定されるのかは
$HOME/.bashrc、$HOME/.bash_profile、/etc/bashrc、/etc/profileなどを見ることになります。ところで、
rootユーザーだと環境変数PATHに設定されている内容が、少し変わります。# echo $PATH /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/binこのあたりですね。
/sbinこれは、
/sbinがシステム管理者用のコマンドを置くディレクトリだからですね。あとは、
/usr/local/sbinが/usr/local/binの前にあるなど、細かく違ったりもします。/usr/local/sbin:/usr/local/bin
systemctl/journalctlでサービスの状態やログを見るログファイルを見る以外にも、サービス（デーモンプロセス）の状態を確認したり、システムのログを確認したりすることが
systemctl、journalctlを使って行うことができます。サービスの状態を確認する。
$ sudo systemctl status [ユニット名]サービスやOSの出力したログを確認する。
# サービスユニットを指定してログを見る $ sudo journalctl -u [ユニット名] # カーネルログを見る $ sudo journalctl -k # 全ログを出力 $ sudo journalctlこのあたりの情報を押さえつつ、ログを見たりしつつ、少しずつLinuxに慣れて強くなっていくとよいでしょう。
そして、より強い相手に立ち向かっていきましょう。
- 投稿日：2019-12-05T09:20:20+09:00
Linux SVNのリポジトリ作成
■問題
unable to connect to a repository at url◆修正前のコマンド
svn mkdir file:///home/svn/repos/portal -m "create"◆修正後のコマンド
mkdir -p home/svn
svnadmin create /home/svn/repos/portal
- 投稿日：2019-12-05T06:45:01+09:00
bpftraceでテトリス
みなさんこんにちは．突然ですがbpftraceってご存知でしょうか? 名前から明らかなようにbpfを利用したトレーシングツールです．bpftraceの設計は以前から存在するDTraceやSystemTapに影響を受けています．それらのツールに馴染みのある人にとってはむしろ，bpftraceはDTraceやSystemTapのBPF版と言った方が（非常に雑ですが）分かりやすいかもしれません．
一般にBPFを利用してトレーシンングを実施する場合は，1) BPFプログラム本体 と 2) トレーシング結果を表示するためのユーザランドのプログラム を書く必要がありますが，bpftraceでは独自のスクリプト言語により，それらを特に意識せずにトレーシング処理が記述できます．例えば，プロセス別にシステムコール発行数を集計したい場合は以下のようにしてできます．便利ですね．
% bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }' Attaching 1 probe... ^C @[systemd-journal]: 5 @[sudo]: 7 @[vim]: 12 @[dockerd]: 23 @[bpftrace]: 25 @[sshd]: 26 @[tmux: server]: 29 @[containerd]: 113内部的にはbpftraceはスクリプトの構文解析をしてLLVM IRを出力し，それをBPFプログラムにコンパイルしてカーネルにロードします．また同時にbpftraceプログラム自体がランタイムとなりトレーシング結果を表示します．
ところで
SystemTapではテトリスをはじめとしたゲームが動くらしいです．そうなるとbpftraceで同じことができるか気になりませんか? 気になりますよね?
ということで
tetris.stpをbpftraceに移植してみました．
https://github.com/mmisono/bpftrace-tetris
実は元のtetris.stpを動かしたことがないのでオリジナルの動作は分かりませんが，それっぽく動いてるのできっとOKでしょう1．
FAQ
Q. どうなってるの?
perfのcpu clockのsoftware eventにBPFプログラムアタッチすることで，一定間隔でBPFプログラムを呼び出すことができます．このBPFプログラム内でBPF mapに保存してある盤面の状態を更新し，画面を再描画します．画面の再描画は実際にはBPFプログラム側から
perf_event_output()でメッセージを出力し，そのメッセージを受け取ったユーザランドのbpftraceプログラムがANSI エスケープシーケンスを利用して描画します．Q. キー入力ってどうしてるの?
元の実装では
kbd_envet()関数をフックしてキー入力を取得していますが，この関数は物理キーボードにしか反応しないようでssh環境では使えなかったので，代わりにpty_write()をkprobeでフックしてキー入力を捕捉しています．これがベストな方法かは分かりません．Q. 自分の環境だと動いてくれません
動作にはLinux 5.3以上が必要です．そうでない場合，BPFプログラムの命令数上限に引っかかりBPFプログラムがロードできません．もともとBPFプログラムは一定時間の実行終了を保証するために1プログラムあたり4096命令という制限がありましたが，Linux 5.3から特権ユーザは最大100万命令のプログラムをロードできるようになりました2．またbccはgithubにあるmaster branch，bpftraceは
このブランチgithubのmaster branchを利用して下さい．一部最新機能を利用しています3．Q. Linux 5.2以前の環境でどうしても動かしたい
Linux 5.2以前で動作させるにはBPFプログラムのサイズを小さくする必要があります．
今回作成したプログラムはSystemTap版のものをほぼそのまま移植4したものですが，BPFプログラムの観点から見るといろいろと非効率です．何より，盤面のマスの状態を一つ一つBPF mapに保存していますが，これはアクセスの度に
bpf_map_lookup_elem()が必要な処理であり，大変非効率です．BPFマップには任意のデータ構造が格納できるので，本来であれば盤面を一つのBPFマップのエントリに全体を保存しておいて，一括でロード・ストアすれば良いです．ただし，現状bpftraceはint以外のvalueをmapにストアすることができません．また，BPFプログラムのループ処理を全てunrollしているのも命令増加数の一因です．これはループを含むBPFプログラムはverifierで弾かれるためです．Bounded Loopを使えば一定制約下でループができますが，これもLinux 5.3で導入された機能です（また現時点でbpftraceはbounded loopをサポートしていません）．命令数上限を回避する技としてはbpf tail callを利用してBPFプログラムをチェインする方法もありますが，こちらもbpftraceは現状対応していません．BPFプログラムを分割して一つのイベントに複数のBPFプログラムをアタッチするという必殺技もありますが，イベントがドロップするとBPFプログラムが呼ばれないので，一貫した動作を保証することが困難になります．
ということで，Linux 5.2以前でまともに動くテトリスを作成するのはなかなか難しいと思いますが，我こそはと思う方はぜひチャレンジしてみてはいかがでしょうか．
結論
bpftraceでも頑張ればテトリスは動きます．
冗談はさておき，bpftraceは現在v1.0に向けて活発に開発中です．テトリスは動かないかもしれませんが，4.xのカーネルで利用できます．主要機能は完成していて十分実用的に使用できます5が，まだ細かい部に問題があることがあります．興味のある方はぜひ試してみて，もし問題があればissueの方に報告すると良いと思います．こちらに各ディストリビューションごとにインストール方法がまとまっています．使い方は公式のチュートリアルが参考になります．
また，ちょうど今月にbpftraceの一部開発もしているBrendan Gregg先生のBPF本が出ますね．電子書籍版が既に出ているのでざっと読みましたが，ツールとしてはbpftraceを中心に据えている一方で，（タイトルからは分かりませんが）少量ながらしっかりと既存のトレーシングツールの説明もあり，あくまで実用的なパフォーマンスの問題改善にフォーカスした本なのが良いと思いました．ちなみにトレーシング以外のBPFの話，例えばXDPなどの話はほぼない6のでそれらは違う文献を当たることになります7．
最初実行に少し時間がかかっているのは，BPFプログラムのコンパイルおよびロード時間です． ↩
命令数上限が4096から100万に引き上げられたというとちょっと極端に聞こえますが，実情はそう単純ではありません．実際にBPFプログラムが実行可能かどうかは，BPFの命令数上限の他に，verifierによる検証が一定数以内で終わるかという条件もあります．例えばBPFプログラムはtail callによって他のBPFプログラムに遷移することができますが，この場合はverifeirはその遷移を含めてBPF命令をチェックします．したがって，verifierによって検査される命令数は単一のBPFプログラムの命令数よりも多くなります．このverifierが検査する命令数上限(
BPF_COMPLEXITY_LIMIT_INSNS)はverifierの速度向上とともに引き上げられており，Linux 5.3ではそれが100万になりました．また，それに伴い，プログラムロード時のプログラムサイズ制限も特権ユーザに関してはBPF_COMPLEXITY_LIMIT_INSNSに引き上げられました（当該コミット）． ↩
bpftraceにパッチ当ててるのはずるくない? っていうのは多分すぐ本体にマージされるので許してください...(2019-12-6追記: マージされました) 将来的にはbcc v0.12.0, bpftrace v0.9.4 以上で対応できると思います（共にまだ未リリース）． ↩ライン消去のアルゴリズムだけループが書けないBPFプログラムでは書きにくかったので少し変更しています． ↩
FacebookやNetflixでは既にプロダクション環境で使われているみたいです (cf. https://www.slideshare.net/brendangregg/um2019-bpf-a-new-type-of-software ; この資料だとBPFプログラムが使われている，としか書いてないのでbpftraceではなくてbccのツールかもしれませんが) ↩
ネットワークのパフォーマンス解析の話は丸々一章あります． ↩
付録にあるBPF Cの説明やBPF命令セットの話は役に立つと思います． ↩
- 投稿日：2019-12-05T02:08:19+09:00
Docker Experimental Featuresを有効化してCRIUをやってみる
はじめに
これはCyberAgent 20新卒 エンジニア Advent Calendar 2019の5日目の記事です。
概要
Docker v1.13.0からDocker Experimental Features(Dockerの実験的機能)が追加されました。本記事では、Docker Experimental Featuresを有効にする方法とCRIU機能を試してみます。
Docker Experimental Featuresの有効化
まず、Dockerで実験的機能を使用するには、Docker Experimental Featuresの有効化が必要です。現在のExperimental Featuresの状態は以下のコマンドで確認できます。
$ docker version -f '{{.Server.Experimental}}' false今は、Experimental Featuresは有効化になっていないので、falseとなってます。これをtrueにするには、/etc/docker/daemon.jsonに以下のJSONを定義します。
/etc/docker/daemon.json{ "experimental": true }JSONを定義したら、以下のコマンドでDocker daemonを再起動します。
$ sudo systemctl restart dockerその後にDocker Experimental Featuresの有効化されていることが確認できます。
$ docker version -f '{{.Server.Experimental}}' trueCRIU
まずCRIUって何？
CRIUとは、Checkpoint Restart In Userspaceの略でLinuxのプロセスの状態を保存して停止させ、また同じ状態で再開させる機能のことです。CRIUには、チェックポイント機能とリストア機能があり、チェックポイント機能により、コンテナ状態(メモリ情報など)をdumpして、ディスク上に書き出すことができます。また、リストア機能とは書き出した情報を読み込んでコンテナを実行することができる機能です。
実際にやってみる
コンテナの起動
まずは、サンプルのコンテナを起動します。使うイメージは、rky1011/criu-sampleです。
$ sudo docker run --name cr -d rky1011/criu-sample 7023be792739af4a27a9761a4c48342b68fd7fc04160d48573beef52ff5f365bログを確認して、コンテナが正常に起動しているか確認します。
$ sudo docker logs cr 2019/12/02 04:54:15 2019-12-02 04:54:15.012989234 +0000 UTC m=+10.003540648: count 1 2019/12/02 04:54:16 2019-12-02 04:54:16.013291109 +0000 UTC m=+11.003842518: count 2 2019/12/02 04:54:17 2019-12-02 04:54:17.013561152 +0000 UTC m=+12.004112544: count 3 2019/12/02 04:54:18 2019-12-02 04:54:18.013957634 +0000 UTC m=+13.004509047: count 4 2019/12/02 04:54:19 2019-12-02 04:54:19.014297065 +0000 UTC m=+14.004848477: count 5 2019/12/02 04:54:20 2019-12-02 04:54:20.014497531 +0000 UTC m=+15.005048944: count 6 2019/12/02 04:54:21 2019-12-02 04:54:21.014818609 +0000 UTC m=+16.005370001: count 7 2019/12/02 04:54:22 2019-12-02 04:54:22.015050647 +0000 UTC m=+17.005602048: count 8 2019/12/02 04:54:23 2019-12-02 04:54:23.015328591 +0000 UTC m=+18.005880012: count 9チェックポイントの作成
チェックポイントの作成を行います。コマンドはdocker checkpoint create {container name} {checkpoint name}です。-leave-running=falseを指定すれば、コンテナを停止せずにチェックポイントの作成をできますが、今回はチェックポイント作成と同時にコンテナを停止します。
$ sudo docker checkpoint create cr checkpoint1 checkpoint1コンテナが起動していいないことを確認できます。
$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESコンテナの復旧
checkpointを作成して停止したコンテナを再起動します。コマンドはdocker start --checkpoint {checkpoint name} {container name}です。
$ sudo docker start --checkpoint checkpoint1 crログを確認すると、カウントや時刻が途中から実行されていることを確認できます。
$ sudo docker logs cr 2019/12/02 04:54:15 2019-12-02 04:54:15.012989234 +0000 UTC m=+10.003540648: count 1 2019/12/02 04:54:16 2019-12-02 04:54:16.013291109 +0000 UTC m=+11.003842518: count 2 2019/12/02 04:54:17 2019-12-02 04:54:17.013561152 +0000 UTC m=+12.004112544: count 3 2019/12/02 04:54:18 2019-12-02 04:54:18.013957634 +0000 UTC m=+13.004509047: count 4 2019/12/02 04:54:19 2019-12-02 04:54:19.014297065 +0000 UTC m=+14.004848477: count 5 2019/12/02 04:54:20 2019-12-02 04:54:20.014497531 +0000 UTC m=+15.005048944: count 6 2019/12/02 04:54:21 2019-12-02 04:54:21.014818609 +0000 UTC m=+16.005370001: count 7 2019/12/02 04:54:22 2019-12-02 04:54:22.015050647 +0000 UTC m=+17.005602048: count 8 2019/12/02 04:54:23 2019-12-02 04:54:23.015328591 +0000 UTC m=+18.005880012: count 9 # checkpointを作成した場所 2019/12/02 04:55:35 2019-12-02 04:55:35.465808992 +0000 UTC m=+90.456360361: count 10 # コンテナをcheckpointの一から再実行 2019/12/02 04:55:36 2019-12-02 04:55:36.46625664 +0000 UTC m=+91.456808027: count 11 2019/12/02 04:55:37 2019-12-02 04:55:37.46654395 +0000 UTC m=+92.457095336: count 12 2019/12/02 04:55:38 2019-12-02 04:55:38.466772112 +0000 UTC m=+93.457323548: count 13 2019/12/02 04:55:39 2019-12-02 04:55:39.467092506 +0000 UTC m=+94.457643825: count 14まとめ
CRIUを使うと、コンテナが不意に停止しても、コンテナの実行を継続することができるようになります。現状では、実験的機能としてしか提供されていないのですが、様々な可能性を秘めていると思います。いつか本番環境でも使えると良いですね！
- 投稿日：2019-12-05T01:03:29+09:00
Linux標準教科書メモ1
基本ソフトウェアと応用ソフトウェア
コンピュータ上で動くソフトウェアは大きく二つに分けられる。基本ソフトウェアと応用ソフトウェアの二つです。基本ソフトウェアはWindows, mac OS, LinuxなどのOS(オペレーションシステム)を指し、応用ソフトウェアはOS上で動くWord, Excel, Power Pointなどが応用ソフトウェアとなる。
基本ソフトウェア(OS)の役割
基本ソフトウェアは応用ソフトウェアが動作するのに必要な「部品」を提供したり、ハードウェアの持つ「資源」
を管理する役割を持っています。
「部品」とは応用ソフトウェア（例えばWordとか）をユーザーが操作する際に必要なウィンドウ、メニューやカーソル、ファイルを開いたり保存したりする際のメッセージなどです。OSがないと応用ソフトウェアを作るのに毎回これらの機能を作る必要が出てきて開発に多大なコストがかります。なのでOSは応用ソフトウェアで使う共通機能を提供しています。
ハードウェアの「資源」とはCPUやメモリなどのことで、OS上で動いてる応用ソフトウェアに対して必要な分を分けて与えています。またコンピュータは同時に一つの処理しか出来ないため、動いている応用ソフトウェアを管理して処理のタイミングを高速で切り替えることで複数のアプリを動かしています。
- 投稿日：2019-12-05T00:44:18+09:00
Linux Ubuntu16.04 sudoを使ってコマンドを実行したらちょっと怖いエラーが出た
目的
- ユーザ作成直後、作られたユーザにログインしてsudoをつけてコマンドを実行したときに出たエラーを解決した話をまとめる。
結論
- 新規作成したユーザをsudoのグループに追加していなかった。
起きたこと
sudoをつけてコマンドを実行したところ下記のエラーが出た。実行環境のユーザは
miriwoとする。$ sudo su [sudo] password for miriwo: >miriwo is not in the sudoers file. This incident will be reported. (和訳: sudoersファイルにmiriwoが登録されていません。このインシデントは報告しました。)
行った作業
管理者権限を持っているユーザでLinuxマシンにログインし下記コマンドを実行してユーザ
miriwoを作成した。$ sudo adduser -a miriwoユーザ
miriwoにログインし下記コマンドを実行した。$ sudo suユーザ
miriwoのパスワード入力後に下記のエラーが出た。miriwo is not in the sudoers file. This is incident will be reported解決方法
管理者権限のあるユーザでLinuxマシンにログインし下記コマンドを実行した。
$ sudo gpasswd -a ookawa sudo確認のため再度ユーザ
miriwoでLinuxマシンにログインし下記コマンドを実行した。$ sudo suエラーが出なくなったことを確認した。