コンテ内でsystemctlが使えない..... 業務でコピペしてコマンド使ってたらsystemctlコマンドで下記のエラーが出ちゃいました。 $ systemctl start mariadb.service Failed to get D-Bus connection: Operation not permitted どうやらcnetosやubuntuのコンテナ内ではsystemctlが使えないらしいです。 systemctlとは そもそもこのコマンドって何なの？ってところですが、systemctlはLinux系で利用されるサービスコントロールをするコマンドらしいです。 コンテナ内で使う方法 まずコンテナを起動する時に--privilegedオプションをつけ、/sbin/initで実行します。 # 例) docker run -d --privileged --name centos_container centos /sbin/iniｔ 次に起動したコンテナにアタッチします。 docker exec -it centos_container /bin/bash これで使えるようになるかと思います。

はじめに 久しぶりにUbuntu20.04LTSを開いたので、sudo apt update と sudo apt upgradeを行ったらエラーが発生。 どうやらnvidiaのドライバの更新をしようとしてエラーが出てるっぽい。 --configure みたいなコマンドを打ってくださいとい表示がされていたので実行。 すると問題なく動いたので良かったのだが、MNISTプログラムを実行するもGPUが動作しない。 仮想環境内でも仮想環境外でもnvidia-smiコマンドは実行可能だし、nvcc -Vでコンパイラのバージョンも確認可能。 バグの原因を調べているとドライバー関連を更新したあとに再起動してないのではないのかという記述を発見。 そういえばsudo apt upgrade でnvidia関連のドライバをインストールしていたことを思い出す。 再起動するといつもなら自然に起動するはずだが、Ubuntuの起動選択画面が表示（最初にインストールしたときに出てくる画面）。 これはなんか怪しいぞと思いつつ起動すると、デュアルモニターの片方が機能していない。 おまけにnvidia-smiコマンドも機能しないということで対処に迫られた。 Ubuntuでの今までの環境構築の経験から原因を予測し対処を試みる。 解決策 Nvidiaドライバーがセキュアブートのせいでうまくインストールできなかった これが一番考えられる。 セキュアブートを詳しく理解は出来てないが、要するに起動時にサードパーティ製のやつみたいな怪しいのは安全のため起動しないことがあるみたいな機能のはず。 この環境構築時にも一度それで失敗しているのと、他の記事でもドライバのインストールの際はセキュアブート切っておけと書いてある。 インストールがうまく出来ていないのか、起動が出来ていないのか問題を切り分けるため、とりあえず再起動しBIOSでセキュアブートを無効にして再起動してみる。 デュアルディスプレイもちゃんともとに戻り、nvidia-smi nvcc -V どちらも動作を確認。 pytorchのtorch.cuda.is_available()での確認もTrueが返ってきて無事成功しており一安心。 ちなみにドライバーのバージョンを確認したが変わってはいなかった。 何が変わったのかよくわからないが、2021年5月19日22時頃に起こった現象であることをここに記しておく。 再発防止策 とりあえず直ったが再発防止策のため原因を再度考える。 おそらくsudo apt upgrade　が原因なのだが、そもそもこのコマンドが詳しくは何をしているのか理解していないのが原因だと考えた。 sudo apt update インストール可能なパッケージリストの更新を行う これ自体でパッケージの更新を行っているわけではない。 sudo apt upgarade インストール済みのパッケージの更新を行う。 [1]によると”アップグレードは主に不具合等を修正して完成度を高めること”であるそうなので、このコマンドでバージョン自体が変わることはなさそうだ。 以上のことを踏まえるとセキュアブートをONにしている限りこのようなことは避けられないと考える。 この論理でいくとセキュアブートは本当に必要なのかという問いに行き着くので調べてみる 定義)セキュアブート:”デジタル署名を検証し、署名されていないソフトウェアを実行しないようにする技術”（2より引用） 他のサイトも見てみたが、セキュリティ面が強くなるのは間違いないよう。 環境構築などの際に邪魔になるのは間違いないだろうが、ドライバー系をインストールする際はセキュアブートを無効にするというのを意識すれば問題ないだろう。 セキュリティの専門家ではないのでおとなしくONにして、必要な時だけOFFにすることに決めた。 ちなみに3によると自宅PCにも使われているUEFIは新しいBIOSの一種みたいなものだそう。 別物なのか気になっていたのでこの際解決しておく。 おわりに 勝手にアップデートされて勝手にバグるのは勘弁してほしい。 ではこれで！! 参考文献 [1]: Ubuntu Linuxのapt updateとapt upgradeの違いは何？アップデートには両方必要なの？ 2021/05/19アクセス [2]:【解説】セキュアブートとは？BIOSの後身、UEFIって何？ [3]: BIOSとUEFIの違いについて詳しく解説！次世代のレガシーBIOSとは？

はじめに 前回の記事[1]でtensorflowの環境を構築した。 pytorchも試してみたくなったのでやってみる。 環境構築といってもpipenvであたらしい仮想環境を作って必要なパッケージをインストールするだけ。 詳しく知りたい人は前回の記事[1]を見てください。 環境 Ubuntu20.04LTS GPU Geforce RTX 2070 super GPUドライバー 450.119.03 CUDA 11.0 cuDNN 8.0 python3.8.10 pipenv pytorchのダウンロード pytorch公式[2]に書いてあるコマンドを利用してダウンロード。 pipenvには探したところなかったのでpipでインストールした。 最新バージョンはCUDA11.0と合うものがないようだったので、pytorch1.8.0をダウンロード。 コマンドがそのまま書いてあるのでそれを打ち込むだけ。 pipでインストールするのでPipfileに反映されない点に注意。 ちなみにpipenvでインストールしたパッケージをpipenvで消すとpip listにも表示されなくなる。 これはpipenvがpipとvirtualenvの組み合わせだからだろう。 MNISTプログラムの作成 前回同様公式のは使わずこちらの記事[3]のプログラムを参考にする。 コピーして実行するもrequestsパッケージが足りないと言われたのでpipenvでインストール。 再度実行するとエラーが出た。 urllib.error.HTTPError: HTTP Error 503: Service Unavailable 要するにmnistのダウンロードサイトがなんか使えないらしい。 調べてみるとこのサイト[3]が見つかった。 サイトから直接ダウンロードしてデータを参照するパスを書き換えればいいらしい。 ダウンロードして解凍。 wget www.di.ens.fr/~lelarge/MNIST.tar.gz tar -zxvf MNIST.tar.gz このあと train_set = MNIST('./', download=True, transform=transforms.Compose([ transforms.ToTensor(), ]), train=True) test_set = MNIST('./', download=True, transform=transforms.Compose([ transforms.ToTensor(), ]), train=False) のように./にパスを変更する。 実行してみるとうまくいった。 おわりに とりあえずpytorchとtensorflowどちらも環境構築と動作確認は出来たので違いを本格的に理解していきたい。 それではまた！ 参考文献 [1]:PyTorchでMNIST [2]:INSTALLING PREVIOUS VERSIONS OF PYTORCH [3]:HTTP Error when trying to download MNIST data

ArchLinux 系のディストリビューションでトラブル？ 一時アップした記事ですが、この内容は ArcoLinux 特有のトラブルのようです。 Manjaro Archman ではごく普通にアップデートできました。 詳しく言うと、入れたはずがない Yay-bin と pacman の衝突でアップデートできなくなり 結果、ディストリビューション自体が壊れるというものです。 ArcoLinux 使えないなぁ・・・？ pacman と yay-bib の信頼関係なのか？ 詳しいことはわかりませんが 当方のArcoLinuxはとっくに壊れてしまいました(笑) 再インストールしようと思いますが 最新のパッケージで再インストールしてください。 https://sourceforge.net/projects/arcolinux-community-editions/files/xfce/ でも、この pacman と Yay のトラブルって結構昔から記事があるんですが・・ どういうことでしょうね？

はじめに Ubuntuでtenosrflowとpipenvによる環境構築をしたのでまとめておきます。 自分は初心者なので、LINUXのコマンドを叩ける人ならわかる解説になっていると思います。 わかっている人からしたら少しくどいと思いますが、自分用なので。 また仮想環境の構築とpython関係のパッケージのインストールはpipenvで行います。 virtualenvとpipなどでもいいですが、便利なのでおすすめです。 OSはUbuntuを想定していますが、それ以外のディストリビューションでも可能だと思います。 環境 環境(構築前) Ubuntu20.04LTS GPU Geforce RTX 2070 super GPUドライバー　 450.119.03 環境(構築後) Ubuntu20.04LTS GPU Geforce RTX 2070 super GPUドライバー　 450.119.03 CUDA 11.0 cuDNN　8.0 python3.8.10 tensorflow 2.4.0 pipenv 目標環境はtensorflow公式ホームページを参照に決めました。[1] 使用するGPUによってドライバが異なります。 ドライバによって対応しているCUDAが違うので、まずは対応を確認して自分の目指す環境を確認してください。 こちらの記事[2]も対応を確認するには役に立つので目を通しておくといいです。 CUDAのインストール 公式サイト[3]でダウンロードしたいものをクリックしていくとダウンロードするためのコマンドが出てくるのでそれを実行。 CUDA Toolkit 11.0 →　LINUX →　x86_64　→　centOS →　version7 →rpm(local) と選択していくとコマンドが表示されます。アーキテクチャはほとんどの人がx86_64だと思いますが、確認したいという人はarchコマンドで確認できます。 最後のはネットワークでも問題ないと思いますが、以前ダウンロードした時に失敗したことがあるのでlocalにしています。 runfileでもダウンロードしてshコマンドでrunfileを実行後、欲しいものを選択すればダウンロードできます。 今回はわかりやすくdebファイルで行っていきます。 一応下に載せておきますが、公式サイトの方を参考にしてください。 wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin sudo mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600 wget http://developer.download.nvidia.com/compute/cuda/11.0.2/local_installers/cuda-repo-ubuntu2004-11-0-local_11.0.2-450.51.05-1_amd64.deb sudo dpkg -i cuda-repo-ubuntu2004-11-0-local_11.0.2-450.51.05-1_amd64.deb sudo apt-key add /var/cuda-repo-ubuntu2004-11-0-local/7fa2af80.pub sudo apt-get update sudo apt-get -y install cuda インストールしたらパスを通します。 パスを通すに関してはこの記事[4]を 僕は.bashrcにパスを書いてsorceで更新しました。 先頭に.がつくファイルは隠しファイルなのでls -aで表示しましょう。 またsourceコマンドは厳密ではコマンドではなかったような気がします。 なのでインストールしようとしても出てきません。 Ubuntuだと sudo apt install build-essential chekinstall で使用できるようになります。 ちなみにcentOSでは yum groupinstall "Development Tools" とディストリビューションによって異なるので、Ubuntu以外でやってる人は注意してください。 .bashrcの末尾に export PATH="/usr/local/cuda/bin:$PATH" export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH" を追加したあとにsourceコマンドで更新 source .bashrc which nvcc　でパスが出てきたらパスが通っています。 ちなみにたまに.bash_profileに書いてる記事などもありますが、特にこだわりがなければ.bashrcでいいと思います。 一応違いが書いてある記事[5]を載せておきます。 cuDNNのインストール cuDNNの公式サイト[6]からダウンロード。 メンバー登録が必要ですが、Googleアカウントと連携できます。 2021年6月3日現在の最新バージョンはcuDNN v8.2.0ですが、インストールしたいのは古いものなのでそちらをインストールします。 ここは各自のGPUやドライバー、ディストリビューションに応じて各自変えてください。 アーカイブのところをクリックすると過去のものが出てくるのでインストール。 例えばCUDA11.0でcuDNN v8.0がインストールしたければcuDNN v8.0.5 for CUDA 11.0 が確認できる中で最新なのでこれをインストールします。 対応するディストリビューションのX86_64アーキテクチャのパッケージを下記の3つインストールしましょう。 ・Runtime Library ・Developer Library ・Code Samples and User Guide 対応するアーキテクチャ、ディストリビューションのやつをダウンロードしましょう。 クリックしたらダウンロードされます。 ダウンロードしたら解凍しましょう sudo dpkg -i debファイル で解凍できます。 解凍したあとになんかしたような気がするんですが忘れちゃいました。 なんかエラー出たら頑張って解決してください。 cuDNNが使えているかの確認のためにcuDNNのサンプルを実行します。 僕の場合はcuDNNのサンプルは /usr/src/cudnn_samples_v8 にあります。 最後の数字はバージョンに合わせて変えてください。 mnistCUDNNディレクトリに移動して sudo make を行ってください。 パーミッション的に管理者権限じゃないとアクセスできないようでsudoつけました。 結構かかると思いますが終わったら生成されるmnistCUDNNを./mnistCUDNNで実行してください。 ログが流れてTest Pssed!と表示されたらcuDNNを使用できています。 出来てなかったらcuDNNが使えていない可能性が高いです。 なんとか対応してみてください。 Pythonのインストール これは公式サイト[7]にわかりやすく載っています。 ただインストールする際はホームディレクトリにインストールすることをおすすめします。（環境によるとは思いますが） 個人的にシステム標準でついてくるPythonと混ぜたくないのでそうしています。 システムのPythonと混ぜるのは公式でも推奨されていないですし、面倒なことになるのでおすすめしません。 具体的に言うと　sudo apt install python-numpy などはしないほうがいいです。 僕が今回ダウンロードするのはPython3-8-10です。 対応している中で最新のものを選びました。 あとは[7]通りにやればOKですが、ローカルにダウンロードする場合はオプションが必要なので注意です。 余談 コマンドでインストールしたい人はPPA(個人が公開するパッケージ的なの)を使ってインストールできますがおすすめしません。 このブログ[8]の方法だとシステムにPythonがインストールされますし、公式ではないので。 おとなしく公式のやり方にしておいたほうがあとあと楽です。 pipenvのインストール pipenvと他のコマンドとの比較についてはこの３つ[9][10][11]を見てください。 そんなのどうでもいいという人でも、pipenvはvitualenvとpip(pip3)の組み合わせみたいなものなので、もとの原理を知っておかないと応用が効きません。 Pythonを上記の手順でインストールしている人は標準でpip3がついているはずです。 間違ってもsudo apt install python3-pipはしないほうがいいです。 わかっている人はいいですが、初心者が手をだすとどこになんのパッケージが入っているのかわからなくなるのでやめたほうがいいです。 詳しいことはこちら[12]。 pipenvのインストールはpip3から行います。 pip3 install pipenv pipenvのインストール先は/home/tumutubo/.local//bin/pipenv になっています which pipenv で確認できます。 もし表示されなかったらパスを通しましょう。 多分いらないですが一応pipenvの更新。 pip3 install -U pipenv 作りたい仮想環境名のディレクトリを作成し、そこで pipenv install で作成（事前にPythonのバージョン指定も出来ます） pipenv shell で仮想環境を有効化。 exit で抜けられます。 which python3などとするとパスが変わっているのがわかります。 その他詳しいことはこちらの記事で[13][14] 余談 pipは環境によって動作が少し変わります。 python2系が入っている場合はそちらにダウンロード、python3系のみの場合はpython3にダウンロードされます。 python2系が入っていない場合はpip=pip3として扱えます。 ただ最新のLinuxシステム標準についてくるPythonもいまは3系ですし、Pythonパッケージをダウンロードしてついてくるのもpip3なのでどちらでもいいと思います。 ぼくは3うつのめんどくさいのでpipとpythonコマンドでやってます。 コマンドの場所を確認したい場合は which pip which pip3 と打てば確認できます。 パッケージのインストール Pipfileが存在するディレクトリでpipenv shellで仮想環境に入ります。 あとはパッケージをインストールするだけです。 使いそうなものを適当にダウンロードしておきます。 pipenv install numpy pandas matplotlib keras requests tensorflow==2.4.0 バージョン指定のやり方は上の通りです。 自分の環境にあったものをダウンロードしてください。 動作確認 tensorflow/kerasを使用したMNISTプログラムを動かします。 ほんとは公式をみてやったほうがいいんでしょうが、公式ドキュメントはあまりまとまって無くて苦手です。 たぶん自分の読解力が足りないんだと思うんですけどね。 ここらへんの記事[15][16]を参考にしてMNISTのサンプルを作成します。 [15]の方はコピペだけで動いたのですが、[16]の方は関数などが古くaccをaccuracyに書き換えないと動きません。 また古い関数を使っているせいか最後の部分が表示されなかったりします。 まあとりあえずtensorflow/kerasが動いているのが確認できたのでとりあえずOKです。 おわりに 研究で機械学習をする必要があったので、自宅環境にtensorflowの動く環境を作ってみました。 かなり大変だったのでLGTMしてくれると喜びます。 ちなみに研究室はアーキテクチャ系なので最終的にはCUDAなどの下層のコーディングをすることになると思います。 大変ですがやはりやっていて楽しいですね。 この記事がみなさんの役に立てたらうれしいです。 それではまた！ 参考文献 [1]:ソースからのビルド(TensorFlow) [2]:TensorFlowでGPU学習させるためにCUDA周りではまったときの対処法 [3]:CUDA Toolkit Archive [4]:PATHを通すの意味と通し方　.bash_profile [5]:本当に正しい .bashrc と .bash_profile の使ひ分け [6]:cuDNN Download [7]:Ubuntu環境のPython [8]:Ubuntu16.04にpython3.7を apt install する方法（というか，apt レポジトリに登録されていないpythonのバージョンを導入する方法） [9]:pyenv、pyenv-virtualenv、venv、Anaconda、Pipenv。私はPipenvを使う [10]:Pythonの環境管理ツール良し悪し [11]:Pythonの仮想環境構築についてまとめ【社内向け】 [12]:pip [13]:Pipenvことはじめ [14]:Pipenvを使ったPython開発まとめ [15]:Keras で MNIST データの学習を試してみよう [16]:Keras/TensorflowでMNISTデータセットの画像分類

0日目 私は自宅用に外部公開していないUbuntu Serverを運用しています。 時折SSHでログインしてsudo apt update && sudo apt upgradeとかWinSCPでファイル操作しているのですが、ある日こう思いました。 root所有のファイルに触れないのがめんどくさい そこでなんとなく自分がrootグループに所属してれば解決する気がしたので、少し検索してこのコマンドを入力しました。 $ sudo usermod -G root kurema ここで私は3つ間違いを犯しています。 rootグループに所属したところでroot権限は得られない。得られるのも望ましくない。 rootグループに所属したところでパーミッションがrwxrwx---みたいなファイルしか触れない。大抵はrwx------とか。 usermodの-Gオプションは副グループが指定したものに書き換わる。追加したいなら-aG。 やらかしました。 この時は気付いていません。 (ただしsambashareグループは残っていたので何か別の操作をしたかもしれません。) 1日目 しばらくしてログインした時、sudoで以下のエラーが出ることに気づきました。 $ sudo apt update kurema is not in the sudoers file. This incident will be reported. ここでusermodコマンドを間違えたくさいと思い当たりました。 Ubuntu Serverではsudoグループに所属しているユーザーがsudoできます。 /etc/sudoersに書いてあります。adminでも良いようです。 しまった。現時点でsudo権限を持ったユーザーが居ない。どうしよう？ なんとかして誤魔化せないか。いや一般ユーザーがroot権限を普通に奪取出来たら脆弱性だ。 権限昇格系の脆弱性が公開されるのを待つか？いや待ってられないし実証コードとか絶対めんどくさいに決まってる。 考えろ。考えるんだ…。 まぁこの時点で解決策は分かっていました。 サーバーには物理アクセスできるわけですから、キーボードとモニターを刺してレスキューモードに入る、最悪ハードディスクを抜いて直接書き換えればどうにでもなる(ファイルシステムは暗号化していません)。 しかしそれは嫌でした。 なぜならめんどくさいからです。 そこで思い浮かびました。 確かcrontabでrootが毎日シェルスクリプトを回してる。 もうsudoできないので記憶頼みだけど確かそうです。 しかもkuremaが書き換え可能な権限持ってる！ やった。勝った！ というわけでシェルスクリプト末尾に以下の行を追加しました。 cd `dirname $0` #... usermod -aG sudo kurema そして安心して寝ました。 cronは夜働くからです。 2日目 再びログインして、sudoを試しました。 $ sudo apt update kurema is not in the sudoers file. This incident will be reported. 何も変わりません。groupsの結果も同じです。 スクリプト自体は動いた形跡があります。 とりあえずエラーか何かで途中で終了したのかもと考え、usermod行を末尾から先頭に移動しました。 ちなみにシェルスクリプトでは途中エラーが出ても普通に下まで実行するはずなのでこれは間違いです。 途中で終了させたい場合はset -eなどとしますが、今回してないので推測がおかしいです。 その辺はなんとなく分かってましたがダメもとです。 usermod -aG sudo kurema cd `dirname $0` #... シェルスクリプト内のエラーが発生した場所で異常終了したい bashスクリプトのエラー処理のベストプラクティス 3日目 再び試しました。案の定ダメです。 以前、cronでshutdownを実行するときrootでもsudo shutdown -r nowのように書かなければならなかったことを思い出し、sudo usermod -aG sudo kuremaのようにしました。 ないだろうなぁ。 sudo usermod -aG sudo kurema cd `dirname $0` #... 4日目 ダメです！ 意味が分かりません。エラー文が見たいのでファイル出力を設定しました。 明日解決する可能性はないですが、原因は分かるはずです。 これは3日目にまとめてやったかも。 sudo usermod -aG sudo kurema > /home/.../usermod.log 2>&1 cd `dirname $0` #... 5日目 ファイルを確認してみよう。 あれ、ファイルが存在しません。 シェルスクリプト自体が実行された形跡はあります。 これはおかしい…。 ここでいくつか推測。 ほぼ同一のシェルスクリプトが他の場所にあるのでそっちを実行してた…？←一行目がcd `dirname $0`(シェルスクリプトの場所にcd)なのでそれはないはず セキュリティ上の理由で、シェルスクリプトはcrontab -e実行時のものがキャッシュされる仕組みがある？←そんな非直感的な仕様はないはず。調べてもなさそうだった。 違う。 そして思い出しました。 「そういやこれ、フォルダをdockerコンテナにvolumeでマウントして、docker内からシェルスクリプトを実行してる。」 忘れてた。 詰んだ。 これはもう素直にモニターを運んでつなげるしかないのでしょうか。 嫌だなぁ。 ただdockerはroot権限でファイルは作れるんだよな。 何かできないか？ ファイル作れても仕方ないしなぁ。 そうだ！ /etc/sudoers.d/をボリュームに追加でファイル作れるじゃん！ これで解決だよ。良かった。 というわけでdocker-compose.yml(これもkuremaが変更可能)を書き換え、シェルスクリプトも書き換え、寝ました。 version: '3' services: nicochcgi: #... volumes: - ./config:/etc/nicochcgi - /home/share/niconico:/media/niconico - /etc/sudoers.d:/media/sudoers.d #ここを追加 echo `kurema ALL=(ALL:ALL) ALL` > /media/sudoers.d/kurema #... sudoを/etc/sudoers.d/fileで許可する 6日目 確認。変化なし。 考えてみるとdocker-compose.ymlを実行中書き換えても反映されないだろうし、コンテナ再起動が必要か。忘れてた。 サーバーごと再起動っと。 $ shutdown -r now Failed to set wall message, ignoring: Interactive authentication required. Failed to reboot system via logind: Interactive authentication required. Failed to open initctl fifo: Permission denied Failed to talk to init daemon. そりゃそうだ。 再起動は確か日曜日にスケジュールしてたはずだ。 電源ボタンを押せば手動でできるけど、dockerが起動しなくなったりすると厄介なので待とう。 7日目 (再起動までの数日除く) ダメ。慣れてきた。 そういえば、ボリューム追加にはあらかじめマウント先のフォルダを作ってないといけないかったような。 とりあえずフォルダを作るか。 mkdir /media/sudoers.d echo `kurema ALL=(ALL:ALL) ALL` > /media/sudoers.d/kurema #... さすがにもう一週間は待てないので電源ボタンを押す。まぁ大丈夫だろう。 8日目 またもダメ。変化なし。 しかしなぜ動かないんだろう。 dockerはroot権限で動いて、作るファイルもroot所有…。 あ！ Ubuntu ServerのdockerはSnappyで動いてる！ Snappyだと/etcとかには直接触れないんだ！ 思い出した…。そんなことあったわ。 うーん。何か手はないか。 …まぁないだろ。 サンドボックス下からsudo権限取れたら話にならんし。 dockerをclassicオプション付きで再インストールできれば良いが、当然sudoが必須だし。 Snap(Snappy) コマンドの使い方 …諦めよう。 9日目 仕方ないのでキーボードとモニターを持って行ってサーバーに繋げました。 shutdown -r nowはなぜかsudoなしで動きました。直接繋ぐとOKなのかな？ まぁ目の前に電源ボタンがあるからsudo必須にする意味もないか。 (ちなみに下の作業前にインストールメディアから色々やろうとしたが、LVMのマウントが面倒だったので検索しなおした。) 電源投入時Esc連打。 GRUBメニューが出たらnormalEnterすぐEsc。 Advanced options for Ubuntu選択。 Ubuntu, with Linux *.*.*(recovery mode)選択。2つあったがどっちでも良い。 ⁠root:Drop to root shell prompt選択。 ls /homeとかでサーバーと同じ環境で普通にマウントされてることを確認。念の為。 usermod -aG sudo kurema。groups kuremaで確認。 第639回　Ubuntuに「トラブル時に」ログインするいろいろな方法 終わり。 長かった。 毎日やったのは数行程度の作業だから「最初からこうすれば」ということはなかった。 数日sudo使えなくても実害はないし。 むしろモニターとキーボードをつないで作業するってのはホントめんどくさい。 というわけで奮闘むなしくシングルユーザーモードでログインして解決しました。 一番避けたかった(再インストールやHDD抜き差しという最悪の事態は回避できたとはいえ)結果に終わったのは残念ではあるけれど。 改めて攻撃者の立場で見てみると、結構やらかしてる点があるというのに気づきました。 最終的にroot奪取はできなかったけど、sudo権限を奪われてもrootでファイル操作は多少できていたし、docker-composeも書き換えられるし。 自分はsudo可能だから大して気にしてなかったけど本来はよろしくないね。 あと念のためレスキュー用ユーザーでも作っておくのも良いかなとも思いました。散らかるのでやらないけど。

BH3のシャットダウンシーケンスは下記の手順で停止・起動の設定をすることができます。 再起動後も設定は保持されます。 （デフォルトはイネーブルです） ■停止手順： % sudo systemctl daemon-reload % sudo systemctl disable shutdown-sensor.service ■起動手順： % sudo systemctl daemon-reload % sudo systemctl enble shutdown-sensor.service

RiderとTypeScript 前提条件 node.jsをインストール npmをインストール typeScriptをインストール $ node --version $ npm --version $ tsc --version TypeScriptのプラグインをインストール 設定 - Marketplaceからインストールする インストールすると実行構成にtypescriptの設定画面が現れる TypeScriptファイルとtsconfigファイルを作成する exploerから右クリックでTypeScriptファイルとtsconfigファイルを作成する TypeScriptファイルとtsconfig.jsonパスを設定 TypeScriptファイルとtsconfig.jsonのファイルのパスを設定する TypeScript形式でプログラムを書く TypeScriptファイルに記述する function greeter(person: string) { return "Hello, " + person; } let user = "Jane User"; console.log(greeter(user)); TypeScriptファイルをコンパイル エディタ上で右クリックするとコンパイルを実行するが表示される この画面で右クリック - コンパイルを実行 JavaScriptが生成される 同じフォルダにJavaScriptが生成される JavaScriptの実行環境を作ってから実行 node.jsベース　プラウザベースで実行環境を作ってから実行 JavaScriptをそのまま実行 実行環境作らなくてもこの画面で右クリックからでも実行できます 続く

はじめに 大学院の研究でCUDAなどを使う必要性が出てきたので、GPUの認識を考えるとデュアルブートが一番良いと判断。もともと持っていたWindowsPCでUbuntu20.04とのデュアルブートを試みます。 PCスペック (変更前) OS : windows10 home m.2 nvme SSD : 1TB HDD : 2TB メモリ : 8G×2 GPU : Nvidia RTX2070super (変更後) OS : windows10 home or Ubuntu20.04LTS m.2 nvme SSD : 1TB (windows 10 home) m.2 nvme SSD : 500TB (Ubuntu20.04LTS) HDD : 2TB メモリ : 8G×2 + 16G×2 = 48G GPU : Nvidia RTX2070super デュアルブートの必要性 まず本当にデュアルブートが必要か判断してください。 Linux系のOSをWindowsで使いたい場合は方法は大まかに分けて３つあります。 仮想環境の構築 一番オーソドックスなのはDocker、VirtualBoxなどの仮想環境作成ツールを使っての作成だと思います。Windows内のリソースは取られ、少し動作も遅いですがGPUなどの認識がいらないのであればこれでもいいです。DockerなどでもGPUが使えるようになったと噂を聞きましたが、めんどくさかったのでやめました。 WSL お手軽にCUIを体験してみたい、atcoderなどの競技プログラミングでのファイル作成しかしないということであればwslがいいです。WindowsStoreにあるのをダウンロードすればターミナルは使えるようになるので一番簡単でしょう。新しいwsl２ではGPUが使用可能らしいですが、バグがあったり動作が不安定だったりするので記事投稿時点では採用しません。2023年頃にはまともに使えるようになってそうな気はします。 デュアルブート 結局これが一番楽。起動時にOSを選択するのが面倒ですが。同じSSD内でパーティションを区切って他OSをインストールすることも出来ますが、よっぽどわかっている人以外は辞めたほうがいいです。 結論: GPUを使いたいならSSD増設してデュアルブート化する 参考記事 検索したところこちら[1]がわかりやすくまとまっていたので、この記事を参考にデュアルブートに挑戦していきます LiveUSBの作成 いまあるPCでLiveUSBを作成します。ブートメディアならばなんでもいいのでDVDでも問題ないです。 最初はbalena Etcherを使用して作成しようとしたのですが、フリーズしてできなかったので仕方なくUNetBootinでLiveUSBを作成しました。 SSDの増設 僕はM.2SSDを買いましたがSATA接続のものを買っても問題ないと思います。 SATA接続の場合は電源ケーブル、SATAケーブル、 SSDを購入する前に自分のPCを開けてみて中身がどうなっているのかをきちんと確認しましょう。 僕はもともとPCゲームをするためにBTOで買っていたので、購入履歴からマザボの名称を発見。 その名称を検索してマザボ上にSSDをどうつけるかを考えました。 m.2スロットが２つあっても同時に使えなかったり、そもそも2つなかったりするかもしれないのでしっかり調べましょう。 SSDをマザボに接続できたらwindowsで起動して認識しているか確認しましょう。 認識していることが確認できたらOSを入れたい記録媒体以外は全部マザボから外しましょう。 間違えてwindowsの方にインストールしたら当然データふっとぶのでやばいです。 よっぽど自信のある方以外は全部外すことをおすすめします。 あとケーブル類を外す際はマザボ側の端子、電源側の端子を外しましょう。 逆側を外しただけのときに何故かうまく行きませんでした。 メモリ不足を感じていたので、ついでにメモリも増設しました。 OSのインストール Live USBを挿した状態で起動してBIOSを開きます。 僕はF2で開いて、F11でOSの選択でしたがそれはPCによるので自分で調べてください。 あとは[1]の通りに進めていきます。 パーティションのところだけわからなかったので調べました。 どのサイトか忘れたのでわからない人は調べてください。 再起動すると画面がバグっていたので[1]に書いてある参考文献をみて解決。 要するにNVIDIAドライバーがうまく動かないので無効にしてあとでダウンロードする感じらしい。 書いてある通りやって再起動するとうまく行きました。 とりあえず流れでいろいろダウンロード。 ひとまずダウンロードが必要とのことで再起動すると無限にログインを求められる。 調べて見ると[2]に対応作が書いてあってのでそれを実行。 再起動するとやっとログイン出来た。 linux系はやっぱりある程度調べたり解決する力がないときついですね。 確認とダウンロード ターミナルを開いて nvidia-smi と入力してGPU情報が出てくればGPU認識されています。 sudo apt update sudo apt upgrade でパッケージの更新ができるので好きなコマンドやアプリケーションを入れましょう。 storeからダウンロードしてもOKです。 おわりに 今回はデュアルブート化をしてみました。ノートPCもUbuntuにしたことがあるのでまだ楽でしたが、デスクトップPC内部をいじったりするのは初めてだったので壊さないか緊張しましたね。リスクを減らして作業を行うことの大切さが改めてわかりました。次はディープラーニング用の環境を構築していきたいと思います。 それではまた！ 参考文献 [1] WindowsでSSDを増設してデュアルブートしたUbuntuでPyTorch(GPU)を使うまで [2]:Ubuntu20.04がログインループで立ち上がらなくなった場合の対処法

概要 古パソに、DietPiベースにして、OpenMediaVault 5を入れて、NASを作る OMV5は、Debianベースのものにインストール OMV配布のISOイメージで、古いUEFIのPCにインストールしたら、NO BOOTABLE DEVICEとなってしまったので、(ラズパイで!!)実績のあるDietPiを入れて、インストールすることにした。 Dockerベースでいろいろ拡張できる(っぽいぞ) 1Gbpsのネットワーク分は出てる? プロ環(プログラミング環境)関連、ってことでQiitaで書いてもええよね。 環境 x86_64系のPC (インストール先が全部消去される) Acer ES1-512 (2014年製くらい??) CPU: Intel Celeron N2840 (2.16GHz) Memory: 4GB HDD: 500GB LAN: Realtek RTL8211 (?) -- QEMUでのBridge接続がうまくいかないかったのは、こいつのせいか？？ Windows PC ISOイメージのダウンロードと、rufusでUSBへISOイメージ書き込み ブラウザ開いて、OpenMediaVaultのWebUIに接続 手順 USBメディア作成 ISOファイルを rufusにて USBフラッシュメディアに焼く。 DietPi DietPi::インストール DietPiのサイトで、[Download] => [PC/VM]にてフィルタ。Native PC(UEFI) をクリック、Installer Imageから、ファイルをダウンロード。解凍して、ISOファイルを焼く https://dietpi.com/downloads/images/DietPi_NativePC-UEFI-x86_64-Buster_Installer.7z USBメディアから起動。　電源入れたら、[F12]をぽちぽちおすと、起動デバイスが選べる機種がおおいかと。 Clonezillaが起動する. 基本Enterキー。インストール先を間違えないように インストールが終わると、電源オフになる。 うまくインストーラーが起動しない場合 BIOS設定で、Secure bootを、Disabled に。 だめなら、Native PC(BIOS/CSM)を使ってみる DietPi::初期設定 有線接続(Ethernet)して、電源オン。 初回起動時 初回ログイン: ユーザ:root / パスワード:dietpi ネットにつながって、自動更新される。 DietPi-Surveyに参加する(OptIn)か、参加しない(OptOut)か選ぶ。 DietPi-Softwareでインストールするソフトのデフォルトパスワードdietpiを変更するか?=> <OK>変更する / <Cancel>変更しない rootとdietpiというユーザのパスワードを変更するか? => <OK>変更する / <Cancel>変更しない シリアルコンソールを禁止するか => <OK>禁止する / <Cancel>禁止しない DietPi-Softwareというのが立ち上がる。 DietPi-Software DietePi Config Advanced Options > RTC mode > [Emulate] => [Hardware]に変更 Language/Regional Options > TimeZone(default: Europe/London)とKeyboard(default gb)の設定変更 DietPi-Software SSH Server: [Dropbear] => [Open SSH Server]に変更 設定したら、"Install"を選択 reboot # 再起動 sshでrootログインできるようになってます。 OpenMediaVault 5 OMV5::インストール 以下実行 time wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash # # https://forum.openmediavault.org/index.php?thread/32182-rpiv4-network-and-plugin-problem /&postID=237002#post237002 rm /etc/systemd/network/99-default.link omv-salt deploy run systemd-networkd # # 再起動 reboot なんか、１つFailedになっているっぽいけど... set_timezone? ならええか. どんまい。 ... Summary for DietPi ------------- Succeeded: 77 (changed=26) Failed: 1 ------------- Total states run: 78 Total run time: 16.678 s proftpd.service is not a native service, redirecting to systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable proftpd Done. real 15m54.973s user 8m52.709s sys 1m4.006s root@DietPi:~# OMV5::初期設定 なんらかのPCで、ブラウザを開いて、http://<OMVをインストールしたPCのIPアドレス>/にアクセス ログイン: ユーザ:admin / パスワード:openmediavault 設定 - 個々のメニューで設定を [Save/保存]したら、[Apply/適応]する。 Web管理者パスワード変更System > General Settings: [Web Administrator Password] 日付関連 System > Date & Time ホスト名System > Network: [General] (※お好みで)ネットワークのインターフェースをブリッジにする(KVM/QEMU使用するが、うまくうごかないNIC?もあるっぽい) System > Network: [Interfaces] eth0 を選択して、[Delete] => [Yes] [Add] => Bridge Applyを押す Docker/Portainer のインストールSystem > OMV-Extras : [Docker] CockpitのインストールSystem > OMV-Extras : [Cockpit] で +Install OMV5: 共有ディスク・ネットワーク共有の設定 概要 ディスクを認識させる(Disk) USBの外付けディスクを挿して、ここで、Scanを押して、認識させる ファイルシステム(FileSystem) ファイルシステムを作成 ファイルシステムをマウントする マウントできるとこんな感じ 共有フォルダ(Shared Folders)の設定 共有フォルダの作成 こんな感じ SMB/CIFSで共有設定 SMB/CIFSを有効にする。 共有の設定 TimeMachineとかのスイッチもあるので、Macのバックアップとかにも使える? ユーザ関連 homeフォルダを有効にする? ユーザ作成 適当に埋めて、Groupsタブへ Groupsの設定 users: キホソ sambashare : たぶん、smb共有で必要なんじゃないかな？ ssh : sshログインするのに必要かも? sudo : sudo する? docker : 必要な人は kvm, libvirt : 必要な人は 読み書き権限の設定 クライアントから使う Windows エクスプローラ開いて、アドレスバーに \\<OMVのIPアドレス または ホスト名>\を入れて Enterキー。ユーザとパスワードは設定したやつ ドライブに割り当て lubuntuとかファイルマネージャっぽいのを開いて、ネットワーククリックすると、勝手に探してくれたような.. mac smb://<OMVのIPアドレス または ホスト名>/ でいけるんじゃなかったっけかな... iOSで、VLCから。ネットワークで、ファイルサーバーのとこに出てくる Dockerベースでいろいろ拡張 Nextcloud: AdguardHome: Jellyfin: メディアサーバ apt-cacher-ng calibreweb dashmachine jdownloader netdata syncthing torsocksproxy transmission Cockpit ブラウザで、https://<OMVのIPアドレス>:9090/にアクセス. httpsなので、セキュリティがごにょごにょ言われるが、先に進む。 既存ユーザ(root)で、ログイン。 端末...CTRL-なんちゃら、はブラウザのほうのショートカットキーになることがある.. 仮想マシン(KVM/QEMU) Cockpitを入れると、仮想マシンが、使えるようになってるっぽいぞ vagrant-libvirt: Vagrantでさくっと。 Vagrantインストール VAGRANT_VERSION=2.2.16 wget https://releases.hashicorp.com/vagrant/${VAGRANT_VERSION}/vagrant_${VAGRANT_VERSION}_x86_64.deb && \ sudo apt install -y ./vagrant_${VAGRANT_VERSION}_x86_64.deb && \ sudo apt install -y build-essential libvirt-dev pkg-config && \ vagrant plugin install vagrant-libvirt && \ vagrant plugin install vagrant-mutate Vagrantで実行例 mkdir ~/vmwork cd ~/vmwork vagrant init generic/alpine312 # alpine 3.12のイメージ使用 vagrant up # 仮想マシン起動。初回起動時、イメージのダウンロードをするので時間かかる。 vagrant ssh # sshログイン # #...仮想マシン内での作業 ip a exit # 抜けて、ホストに戻る #... # vagrant halt # 仮想マシンシャットダウン。作業内容はのこる。vagrant upで起動すればよい。 # vagrant destroy -f # 仮想マシン削除。　作業内容も消される。 ことば NAS: Network Attached Storage ネットワークアタッチトストレージ > ネットワークアタッチドストレージ (Network Attached Storage) とは、コンピュータネットワークに直接接続して使用するファイルサーバ。 UEFI: Unified Extensible Firmware Interface OMV: OpenMediaVault > OpenMediaVault（OMV）は、Debianをカーネルに用いたLinuxのフリーのNASシステム。 KVM: Kernel-based Virtual Machine > Kernel-based Virtual Machine (KVM) は、Linuxカーネルをハイパーバイザとして機能させるための仮想化モジュールである。 SMB: Server Message Block > Server Message Block (SMB) は、主にWindowsを中心とした環境でLANを通じてファイル共有やプリンタ共有などに使用される通信プロトコルの総称。OSI参照モデルでは第7層アプリケーション層に該当する。 CIFS: Common Internet File System > マイクロソフトは1996年にSMBをCommon Internet File System (CIFS) と改称し、Windows NT 3.51、Windows NT 4.0、Windows 98に搭載した --- DietPi: QEMU: Docker: Samba: NextCloud: Jellyfin: その他 ディスクは、/srv/dev-XXX にマウントされる. カーネルが更新できない。sudo apt install linux-image-5.10.0-0.bpo.5-amd64(問題なければ、気にしないほうが... "触らぬ神に祟りなし" ...) DietPi-Run_NTPD | Waiting for completion ..が出続ける sudo dietpi-configで、 Advanced Options > Time sync mode > [Custom]に変更(よくわからんけど) バックライト変更 / On / Off # Backlightの値の最大値取得 cat /sys/class/backlight/intel_backlight/max_brightness # 明るさ設定 echo 123 | sudo tee /sys/class/backlight/intel_backlight/brightness # BL Off echo 1 | sudo tee /sys/class/backlight/intel_backlight/bl_power # BL On echo 0 | sudo tee /sys/class/backlight/intel_backlight/bl_power OMV5::OMVのシステムの入ったディスクにDATAパーティションをつくる OMV5は、通常、システム用とデータ用で、ディスクを別のを使用する。 OMV5の公式ではおすすめしていない gpartedで、既存のをshrinkして空きを作り、新規パーティションをext4でつくる。 TODO KVM/QEMUで、Windows環境の構築の説明 とりあえず、動く.. ↓は、メモリ増やさないと厳しいな Docker関連??