What's New Qiita

20200318のLinuxに関する記事は15件です。

  • 投稿日：2020-03-18T23:57:08+09:00

シェルスクリプトで今日の天気予報を見る

はじめに

シェルスクリプトの練習として、Livedoorの天気予報APIであるWeather Hacksを使って「今日の天気」を調べるスクリプトを作ってみました。

また、所望の地点における天気予報が見られるように、地名を指定して天気予報が見られるようにしてみました。

スクリプト

概要

  • 天気予報が公開されている地名のリストである全国の地点定義表はXML（RSS）形式ですが、シェルスクリプトでXMLをサクッとパースする方法が見つからなかったので、sedコマンドで不要な部分をゴリゴリと削っています。
  • 引数で指定した地名が「全国の地点定義表」に存在する時は、その地点の今日の天気をJSON形式で取得して、jqコマンドで解析した結果を表示しています。
  • 引数で指定した地名が「全国の地点定義表」に存在しない時は、「全国の地点定義表」に定義されている地点名を一覧表示します。

使い方

  • 以下のweather.shを実行する際に、引数として所望の地名を指定します。
weather.sh
#!/bin/bash
# http://weather.livedoor.com/forecast/webservice/json/v1?
​
# 全国の地点定義表（RSS）から、入力された地名と合致する地点名とIDを抽出する。
# http://weather.livedoor.com/forecast/rss/primary_area.xml
cityname_id=$(curl -s http://weather.livedoor.com/forecast/rss/primary_area.xml \
    | sed "s/>/>\n/g" \
    | grep city \
    | sed "s/<city title=\"//g" \
    | sed "s/\" source.*>//g" \
    | sed "s/\" id=\"/,/g" \
    | grep $1) \
​
# 該当する地名が存在する時は、その都市の天気予報を取得する。
# 該当する都市が存在しない時は処理を終了する。
if [ -z "$cityname_id" ]; then
    echo 「$1」の天気予報は提供されていません。以下の都市から選択してください。
    echo ----------------------------------------
    echo $(curl -s http://weather.livedoor.com/forecast/rss/primary_area.xml \
        | sed "s/>/>\n/g" \
        | grep city \
        | sed "s/<city title=\"//g" \
        | sed "s/\" id.*>//g")
else
    # {地点名,ID}の文字列からIDだけ抜き出す。
    city_id=$(echo $cityname_id | sed "s/.*,//g")
    city_name=$(echo $cityname_id | sed "s/,.*//g")
​
    echo $city_nameの今日の天気： \
        $(curl -s http://weather.livedoor.com/forecast/webservice/json/v1?city=${city_id} \
            | jq '.forecasts[]' \
            | jq -r 'select(.dateLabel=="今日").telop')
fi

実行結果

実行結果（指定した地名の天気予報が存在する時）
[root@akagi ~]# ./weather.sh 東京
東京の今日の天気： 晴れ
実行結果（指定した地名の天気予報が存在しない時）
[root@akagi ~]# ./weather.sh ペンギン村
「ペンギン村」の天気予報は提供されていません。以下の都市から選択してください。
----------------------------------------
稚内 旭川 留萌 網走 北見 紋別 根室 釧路 帯広 室蘭 浦河 札幌 岩見沢 倶知安 函館 江差 青森 むつ 八戸 盛岡 宮古 大
船渡 仙台 白石 秋田 横手 山形 米沢 酒田 新庄 福島 小名浜 若松 水戸 土浦 宇都宮 大田原 前橋 みなかみ さいたま 熊
谷 秩父 千葉 銚子 館山 東京 大島 八丈島 父島 横浜 小田原 新潟 長岡 高田 相川 富山 伏木 金沢 輪島 福井 敦賀 甲府 河口湖 長野 松本 飯田 岐阜 高山 静岡 網代 三島 浜松 名古屋 豊橋 津 尾鷲 大津 彦根 京都 舞鶴 大阪 神戸 豊岡 奈良 風屋 和歌山 潮岬 鳥取 米子 松江 浜田 西郷 岡山 津山 広島 庄原 下関 山口 柳井 萩 徳島 日和佐 高松 松山 新居浜 宇
和島 高知 室戸岬 清水 福岡 八幡 飯塚 久留米 佐賀 伊万里 長崎 佐世保 厳原 福江 熊本 阿蘇乙姫 牛深 人吉 大分 中津 日田 佐伯 宮崎 延岡 都城 高千穂 鹿児島 鹿屋 種子島 名瀬 那覇 名護 久米島 南大東 宮古島 石垣島 与那国島

まとめ

  • 簡単にXMLをパースする方法が見当たらなかったため、力任せなコードになってしまいました。
    • 無理してシェルスクリプトで頑張らずに、RubyやPythonなどを使った方が可読性の高いコードになるだけでなく、生産性も高くなると思いました。
  • 一方で、シェルスクリプトだけでもある程度の事は出来る...ということも分かりました。
    • シェルスクリプトはどうも苦手ですが、苦手意識がなくなるように時々こういったチャレンジを続けていきたいです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T23:36:50+09:00

CentOS7にjava（jdk14）をインストール

CentOS7にjava（jdk14）をインストールした手順を紹介します。
今回はrpmファイルを取得しインストールしました。

jdk1.4のダウンロード

以下のコマンドでjdk-14_linux-x64_bin.rpmをダウンロードします。
curl -OL -b "oraclelicense=accept-securebackup-cookie" "https://download.oracle.com/otn-pub/java/jdk/14+36/076bab302c7b4508975440c56f6cc26a/jdk-14_linux-x64_bin.rpm"

実行結果
[root@CENTOS7 ~]# curl -OL -b "oraclelicense=accept-securebackup-cookie" "https://download.oracle.com/otn-pub/java/jdk/14+36/076bab302c7b4508975440c56f6cc26a/jdk-14_linux-x64_bin.rpm"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   527  100   527    0     0    774      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  165M  100  165M    0     0   232k      0  0:12:06  0:12:06 --:--:--  227k
[root@CENTOS7 ~]#

ダウンロードしたファイルのハッシュ値を確認

Java SE 14 Binaries Checksumでjdk-14_linux-x64_bin.rpmのハッシュ値を確認します。
ハッシュ値はsha256: c470c99df36a33274832828475766da3e054e0a12db454c1d7c97ae909a55ecbとなっているので、以下のコマンドでダウンロードしたファイルのハッシュ値を取得し、一致していることを確認します。

sha256sum jdk-14_linux-x64_bin.rpm

実行結果
[root@CENTOS7 ~]# sha256sum jdk-14_linux-x64_bin.rpm
c470c99df36a33274832828475766da3e054e0a12db454c1d7c97ae909a55ecb  jdk-14_linux-x64_bin.rpm
[root@CENTOS7 ~]#

jdk14のインストール

以下のコマンドでダウンロードしたjdk-14_linux-x64_bin.rpmをインストールします。

rpm -ivh jdk-14_linux-x64_bin.rpm

実行結果
[root@CENTOS7 ~]# rpm -ivh jdk-14_linux-x64_bin.rpm
警告: jdk-14_linux-x64_bin.rpm: ヘッダー V3 RSA/SHA256 Signature、鍵 ID ec551f03: NOKEY
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:jdk-14-2000:14-ga                ################################# [100%]
[root@CENTOS7 ~]#

jdk14インストールの確認

以下のコマンドでjdk14がインストールされたことを確認します。

java -version
which java

実行結果
[root@CENTOS7 ~]# java -version
java version "14" 2020-03-17
Java(TM) SE Runtime Environment (build 14+36-1461)
Java HotSpot(TM) 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)
[root@CENTOS7 ~]# which java
/usr/bin/java
[root@CENTOS7 ~]#

参考

Installation of the JDK on Linux Platforms
Java SE 14 Binaries Checksum

以上

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T23:36:50+09:00

CentOS7にjava（Oracle JDK14）をインストール

CentOS7にjava（jdk14）をインストールした手順を紹介します。
今回はrpmファイルを取得しインストールしました。

Oracle JDK14 のダウンロード

以下のコマンドでjdk-14_linux-x64_bin.rpmをダウンロードします。
curl -OL -b "oraclelicense=accept-securebackup-cookie" "https://download.oracle.com/otn-pub/java/jdk/14+36/076bab302c7b4508975440c56f6cc26a/jdk-14_linux-x64_bin.rpm"

実行結果
[root@CENTOS7 ~]# curl -OL -b "oraclelicense=accept-securebackup-cookie" "https://download.oracle.com/otn-pub/java/jdk/14+36/076bab302c7b4508975440c56f6cc26a/jdk-14_linux-x64_bin.rpm"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   527  100   527    0     0    774      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  165M  100  165M    0     0   232k      0  0:12:06  0:12:06 --:--:--  227k
[root@CENTOS7 ~]#

ダウンロードしたファイルのハッシュ値を確認

Java SE 14 Binaries Checksumでjdk-14_linux-x64_bin.rpmのハッシュ値を確認します。
ハッシュ値はsha256: c470c99df36a33274832828475766da3e054e0a12db454c1d7c97ae909a55ecbとなっているので、以下のコマンドでダウンロードしたファイルのハッシュ値を取得し、一致していることを確認します。

sha256sum jdk-14_linux-x64_bin.rpm

実行結果
[root@CENTOS7 ~]# sha256sum jdk-14_linux-x64_bin.rpm
c470c99df36a33274832828475766da3e054e0a12db454c1d7c97ae909a55ecb  jdk-14_linux-x64_bin.rpm
[root@CENTOS7 ~]#

Oracle JDK14 のインストール

以下のコマンドでダウンロードしたjdk-14_linux-x64_bin.rpmをインストールします。

rpm -ivh jdk-14_linux-x64_bin.rpm

実行結果
[root@CENTOS7 ~]# rpm -ivh jdk-14_linux-x64_bin.rpm
警告: jdk-14_linux-x64_bin.rpm: ヘッダー V3 RSA/SHA256 Signature、鍵 ID ec551f03: NOKEY
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:jdk-14-2000:14-ga                ################################# [100%]
[root@CENTOS7 ~]#

Oracle JDK14 インストールの確認

以下のコマンドでjdk14がインストールされたことを確認します。

java -version
which java

実行結果
[root@CENTOS7 ~]# java -version
java version "14" 2020-03-17
Java(TM) SE Runtime Environment (build 14+36-1461)
Java HotSpot(TM) 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)
[root@CENTOS7 ~]# which java
/usr/bin/java
[root@CENTOS7 ~]#

参考

Installation of the JDK on Linux Platforms
Java SE 14 Binaries Checksum
Java SE Development Kit 14 - Downloads

以上

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T18:26:19+09:00

grepコマンドの--color=alwaysオプションを使うべきではない

TL;DR

grepに色を付ける際は、--color=alwaysではなく--color=autoを使いましょう、という話です。

環境

$ zsh --version
> zsh --version
> zsh 5.7.1 (x86_64-apple-darwin17.7.0)

背景と問題

タスクを進める過程で、以下のような構造のCSVファイルから、col1またはcol2が特定の文字列である行を抽出してcol3の値が大きい順にソートする、というような処理がありました。

test.csv
col1,col2,col3
a,a,10
a,a_1,20
a,a_2,5
a,a_3,10
a_1,a,25
a_1,a_1,30
a_1,a_2,20
a_1,a_3,10

例としてここでは、col1またはcol2の値がaである行を抽出する必要があったとします。
シンプルに、a,でgrepしたものをsortすれば目的の出力が得られるはずだと考えて、以下のコマンドを実行しました。

ターミナル
$ grep 'a,' test.csv | sort -t ',' -k 3 -rn
出力
a,a_1,20
a,a_3,10
a,a_2,5
a_1,a,25  # numerical sortされていない
a,a,10    # 同上

あれ？ なんで4、5行目が降順ソートされていないんだ？
パイプを使わずにsort単体で挙動を試したところ、col3での降順ソートは問題なく実行できる様子。
となるとgrepに原因があるのか？とアタリをつけて試行錯誤すること数十分（ツラい）。
問題のコマンドの出力をファイルにリダイレクトしてみた時、ようやく原因が分かりました。

原因

以下が、先程のコマンドの出力をテキストファイルにリダイレクトした中身です。

[01;31m[Ka,[m[Ka_1,20
[01;31m[Ka,[m[Ka_3,10
[01;31m[Ka,[m[Ka_2,5
a_1,[01;31m[Ka,[m[K25
[01;31m[Ka,[m[K[01;31m[Ka,[m[K10

一見して「ナニコレ？」と面食らってしまいましたが、調べた結果、この特殊文字は色付け用のANSI escape codeだと分かりました。
.zshrcでexport GREP_OPTIONS="--color=always"としていたので、grepの検索パターンにマッチした部分に色付け用の特殊文字が挿入されたわけです。
今回の問題は、それによって4､5行目のcol3が数値として解釈不可能な文字列になってしまい、降順数値ソートがうまく働かなかった、ということですね。
色付け設定が原因だと分かったところで、上記の行をコメントアウトして再度実行すると案の定上手くいきました。

grepの--colorオプション

「とはいえ色付けできたほうが見やすいし、何かないかな」とgrepの--colorについて調べてみると、never,auto,alwaysのいずれかが指定可能であり、それぞれ以下のような仕様だと分かりました。

  • never：色を付けない
  • auto：標準出力がターミナルに繋がっている場合のみ色を付ける（パイプやリダイレクトの際は色付けしない）
  • always：常に色付け（文字列を変更するので後続処理に影響を与える）

こうして見ると、基本的に--color=alwaysに設定するメリットは薄いと言ってしまってよさそうです。
視認性を高めるためにaliasや環境変数で指定する分には、autoでおそらく充分でしょう。
例外があるとすれば、grepの結果が長大化したときにlessに渡して閲覧する、というような状況でしょうか。
grepの--colorオプションは、実行時に渡した値が環境変数のそれに優先して使われるので、その際にだけgrep --color=alwaysとしてlessにパイプすれば、目的は果たせるかと思います。

参考にさせていただいた記事

grepコマンドに色をつける
Different results in grep results when using --color=always option

教訓

問題の根本の原因は、プログラムを書き始めた頃の自分が「とりあえずbashよりzshのが高機能らしい」「この設定にしとけば便利らしい」と、聞きかじりの知識でターミナル環境を構築してしまったところにありました。
至極当たり前のことですが、先駆者のコードや設定を使わせてもらう際は、その目的と影響範囲を正しく認識しておくのが大切ですね...
ただ、そのマインドを維持できるのもある程度の体系的な知識が有ってこそだと思いますので、今後も精進していきたいと思います。

過去の自分が何気なくコピペした.zshrcに時を超えて困らされるという、ある意味貴重な自戒の機会でした。
このささやかなハマり事例が、もし誰かのお役に立ったなら幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T17:56:08+09:00

メモリ使用率の確認

TL;DR

githubから"memory.sh"をDLしてご利用ください。

コマンド実行後、"memory_size.txt" というファイルが生成されますので、
そちらからどのプロセスがどのくらいの使用しているか確認可能です。
使用量が多い順にソートされます。

コマンド

./memory.sh

動作確認環境

OS : RHEL/CentOS 7.*

シェルスクリプト解説

重要でないところは、省きます。

全プロセスのステータスファイルからメモリ情報を取得

# get memory data
for pid in $(grep VmSize /proc/*/status | cut -d/ -f3) ;do
name=$(grep Name /proc/$pid/status)
memorysize=$(grep VmSize /proc/$pid/status)
echo "-$name/PID:$pid/$memorysize"; echo
done

取得したデータを整形し、ソート

# shaping information
sed -i -e '/^$/d' -e 's/\t//g' -e 's/ //g' $temp
sed -i '/^grep/d' $temp 

# sort informaiton
sed "s/kB//g" $temp |sort -r -n -k 4 -t : > $output

取得したデータ確認

TL;DRでも記述しましたが、
memory_size.txtというファイルが同ディレクトリに内に生成されますので、そちらを確認してください。

取得したデータ確認方法

/ がデミリタで左から

プロセス名、プロセスID、メモリ使用量(KB)

となっています。

-Name:sshd/PID:20073/VmSize:112920
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T16:54:54+09:00

umaskコマンドについてまとめてみた

はじめに

ネット上にはumaskコマンドやマスク値の紹介が色々ありますが、
論理和、論理積、ビットの反転など難しく感じたため記事を投稿します。

umaskコマンドとは

ファイルやディレクトリを新規作成する際に、
どのようなアクセス権(パーミッション)をマスクするかを決めます。

各ユーザごとにマスクすることができます。
ちなみに、umaskはuser maskの略称です。

マスクとは

そもそも、マスクとは何かというと「覆い隠す」という意味です。
私達が身につけているマスクも口元を「覆い隠して」いますよね。

umaskとマスク値の仕組み

umaskコマンドとマスク値の関係をみていきます。
元々は、ファイルやディレクトリを新規作成する際は、全権限(777)が付与されます。
そこに、マスク値を引き算することで、実際に付与されるアクセス権が決まります。

. 　777 　←新規ファイルや新規ディレクトリを作成するときのアクセス権
-)　022　 ←umaskコマンド実行結果(マスク値)
ーーーーーーーー
. 　755　 ←umask -Sの実行結果・・・※

ファイルを作成するときは、※のアクセス権からx権が剥奪されて
644（rw-r--r--）になります。

実機操作

qiita.PNG

参考

umaksコマンドを実行したときに出力される、千の位の「0」は特殊なアクセス権を表します。

  • 4：SUID
  • 2：SGID
  • 1：スティッキービット
  • 0：特殊なアクセス権なし

まとめ

ファイルやディレクトリを新規作成する時のアクセス権を変更したい場合は、umaskコマンドを使いましょう。
ファイル作成時はX権が剥奪されるため、プログラムファイルとして実行したいときは
chmodコマンドでX権を付与しましょう。
早くマスクの流通がもとに戻りますように・・・

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T15:37:51+09:00

GitHubの草の生やし方

GitHubのContributionに草が生えない場合の解決方法

GitHubを登録し、最初にGitHub Desktopでコミット・プッシュをしていた時は、contributionに草（芝）が生えていました。
しかし、SourceTreeをインストールしGitHubに連携してから、GitHub Desktopでプッシュをしても草が生えなくなってしまいました、、進捗が目に見えなくて悲しい、、、
GitHub草問題.png
「GitHub 草生えない」でググって試してみても草が生えない:cry:

草が生えない原因

結論：
GitHubに登録しているメールアドレスと、ローカルのメールアドレスが違ったため、草が生えていなかったみたいです。
他にも要因はあるみたいですが、ほとんどの場合はメールアドレスを連携させることで解決できるっぽい！

今まで出来てたのに急に出来なくなったのはSourceTreeと連携した時に、何らかの不具合が生じてしまった、、？

解決方法

GitHubに登録しているメールアドレスと、ローカルのGitのメールアドレスを一致させます。

・GitHubのメールアドレスの確認方法
右上のアイコン->Settings->Emails->Primaryと表示されているメールアドレス
GitHub草問題　２.png

・ローカルのメールアドレスの確認方法
コマンドで

command
$ git config user.email

この時表示されるアドレスがローカルのGitのアドレスです。
何も表示されない場合は設定されていません。

・ローカルのメールアドレスの設定、変更方法

command
$ git config user.email [GitHubのメールアドレス]

これで登録完了！
上記コードのメールアドレスを代入する部分の[ ]は不要です。
（ググって出てきたままメールアドレスを[ ]で囲んでいたため、私はなかなか草が生えてくれませんでした:no_good_tone1:）

e.g.)メールアドレスが"example@gmail.com"の場合

command
$ git config user.email example@gmail.com

これでメールアドレスが一致し、Contributionが反映され、草が生えるようになりました！草いっぱい生やしたい！みんなも緑でいっぱいにしよう！！:clap_tone1:

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T15:08:11+09:00

apt-get update のThe following signatures couldn't be verified because the public key is not availableと 404 Not Found エラー達をなんとかした話

環境

WSL Ubuntu 18.04です。

nana@LAPTOP:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"

エラーの内容

久々にapt-get updateしたら二種類のエラーに遭遇した

nana@LAPTOP:~$ sudo apt-get update
Get:1 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease [3626 B]
Hit:2 http://ppa.launchpad.net/ansible/ansible/ubuntu bionic InRelease
Ign:3 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic InRelease
Err:1 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 51716619E084DAB9
Get:4 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:5 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:6 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Err:7 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release
  404  Not Found [IP: 91.189.95.83 80]
Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Reading package lists... Done
W: GPG error: https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease: The following signatures couldn't be verified bec
ause the public key is not available: NO_PUBKEY 51716619E084DAB9
E: The repository 'https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

対処法

その１

まずは最初のエラー↓の対処

Err:1 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 51716619E084DAB9

パブリックキーの期限切れ等によるエラーです。
apt-key advコマンドで更新します。

nana@LAPTOP:~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 51716619E084DAB9
Executing: /tmp/apt-key-gpghome.UfENnbgHmi/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 51716619E084DAB9
gpg: key 51716619E084DAB9: public key "Michael Rutter <marutter@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

再度apt-get updateすると

nana@LAPTOP:~$ sudo apt-get update
Hit:1 http://ppa.launchpad.net/ansible/ansible/ubuntu bionic InRelease
Get:2 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease [3626 B]
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:4 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Ign:5 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic InRelease
Get:6 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Err:7 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release
  404  Not Found [IP: 91.189.95.83 80]
Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:9 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ Packages [76.8 kB]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

パブリックキーのエラーは無くなりました。

その２

次はこちらのエラー↓をなんとかします。

Err:7 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release
  404  Not Found [IP: 91.189.95.83 80]

Silver Searcher を使って/etc/apt/以下のppaの記載があるファイルを探します。

nana@LAPTOP:~$ ag ppa /etc/apt/
/etc/apt/sources.list.d/aseering-ubuntu-wsl-bionic.list
1:deb http://ppa.launchpad.net/aseering/wsl/ubuntu bionic main
2:# deb-src http://ppa.launchpad.net/aseering/wsl/ubuntu bionic main

/etc/apt/sources.list.d/ansible-ubuntu-ansible-bionic.list
1:deb http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main
2:# deb-src http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main

/etc/apt/sources.list.d/aseering-ubuntu-wsl-bionic.list.save
1:deb http://ppa.launchpad.net/aseering/wsl/ubuntu bionic main
2:# deb-src http://ppa.launchpad.net/aseering/wsl/ubuntu bionic main

記載のある行を全てコメントアウトします。

nana@LAPTOP:~$ sudo vi /etc/apt/sources.list.d/ansible-ubuntu-ansible-bionic.list
  1 # deb http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main
  2 # deb-src http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main

そして再度apt-get updateをしてみると

nana@LAPTOP:~$ sudo apt-get update
Hit:1 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease
Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:5 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Fetched 252 kB in 7s (34.3 kB/s)
Reading package lists... Done

これでひとまず全てのエラーは無くなりました。

参考

https://chrisjean.com/fix-apt-get-update-the-following-signatures-couldnt-be-verified-because-the-public-key-is-not-available/
https://hibiki-press.tech/learn_prog/dev-env/apt-update-gpg/1976
https://yuis-programming.com/?p=2048

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T15:08:11+09:00

apt-get update 時の"The following signatures couldn't be verified because the public key is not available" と "404 Not Found" エラー達をなんとかした話

環境

WSL Ubuntu 18.04です。

nana@LAPTOP:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS"

エラーの内容

久々にapt-get updateしたら二種類のエラーに遭遇した

nana@LAPTOP:~$ sudo apt-get update
Get:1 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease [3626 B]
Hit:2 http://ppa.launchpad.net/ansible/ansible/ubuntu bionic InRelease
Ign:3 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic InRelease
Err:1 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 51716619E084DAB9
Get:4 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:5 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:6 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Err:7 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release
  404  Not Found [IP: 91.189.95.83 80]
Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Reading package lists... Done
W: GPG error: https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease: The following signatures couldn't be verified bec
ause the public key is not available: NO_PUBKEY 51716619E084DAB9
E: The repository 'https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

対処法

その１

まずは最初のエラー↓の対処

Err:1 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 51716619E084DAB9

パブリックキーの期限切れ等によるエラーです。
apt-key advコマンドで更新します。

nana@LAPTOP:~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 51716619E084DAB9
Executing: /tmp/apt-key-gpghome.UfENnbgHmi/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys 51716619E084DAB9
gpg: key 51716619E084DAB9: public key "Michael Rutter <marutter@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

再度apt-get updateすると

nana@LAPTOP:~$ sudo apt-get update
Hit:1 http://ppa.launchpad.net/ansible/ansible/ubuntu bionic InRelease
Get:2 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease [3626 B]
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:4 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Ign:5 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic InRelease
Get:6 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Err:7 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release
  404  Not Found [IP: 91.189.95.83 80]
Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:9 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ Packages [76.8 kB]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

パブリックキーのエラーは無くなりました。

その２

次はこちらのエラー↓をなんとかします。

Err:7 http://ppa.launchpad.net/aseering/wsl/ubuntu bionic Release
  404  Not Found [IP: 91.189.95.83 80]

Silver Searcher を使って/etc/apt/以下のppaの記載があるファイルを探します。

nana@LAPTOP:~$ ag ppa /etc/apt/
/etc/apt/sources.list.d/aseering-ubuntu-wsl-bionic.list
1:deb http://ppa.launchpad.net/aseering/wsl/ubuntu bionic main
2:# deb-src http://ppa.launchpad.net/aseering/wsl/ubuntu bionic main

/etc/apt/sources.list.d/ansible-ubuntu-ansible-bionic.list
1:deb http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main
2:# deb-src http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main

/etc/apt/sources.list.d/aseering-ubuntu-wsl-bionic.list.save
1:deb http://ppa.launchpad.net/aseering/wsl/ubuntu bionic main
2:# deb-src http://ppa.launchpad.net/aseering/wsl/ubuntu bionic main

記載のある行を全てコメントアウトします。

nana@LAPTOP:~$ sudo vi /etc/apt/sources.list.d/ansible-ubuntu-ansible-bionic.list
  1 # deb http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main
  2 # deb-src http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main

そして再度apt-get updateをしてみると

nana@LAPTOP:~$ sudo apt-get update
Hit:1 https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/ InRelease
Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:5 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Fetched 252 kB in 7s (34.3 kB/s)
Reading package lists... Done

これでひとまず全てのエラーは無くなりました。

参考

https://chrisjean.com/fix-apt-get-update-the-following-signatures-couldnt-be-verified-because-the-public-key-is-not-available/
https://hibiki-press.tech/learn_prog/dev-env/apt-update-gpg/1976
https://yuis-programming.com/?p=2048

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T11:24:46+09:00

C++ 簡易sleep関数 

#include <chrono>
#include <thread>

void util_sleep(int64_t msec)
{
    std::this_thread::sleep_for(std::chrono::milliseconds(msec));
}
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T10:41:50+09:00

Macの仮想環境上でaws-cliが実行できない時の解決方法(python3.8インストール後)

経緯

pythonの仮想環境上で、aws-cliを使用しようと公式のコマンドを実行しようとしても上手くできなかったので、その解決方法の備忘録。
設定を色々いじってもダメだったので全部消してから再インストールしてみました。(2020/03)

仕様

Macbook: MacOS Mojave
Python: Python 3.8.0

aws-cliをインストール

公式に従い、以下を実行

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

しかし、$ aws --version でバージョン確認したところエラー発生

cannot execute binary file

デバッグ

色々試したものの、どれもうまくいかなかったので一度仕様してないファイルはきっちり消すため
$ rm '/usr/local/bin/aws'
$ rm '/usr/local/bin/aws_completer'
で削除を実行。

そこから

$ pip install --user virtualenv
$ virtualenv ~/[仮想環境名]

で新たに仮想環境を作成して

#仮想環境を activate
$ source ~/[仮想環境名]/bin/activate

新しい仮想環境に awscli を pip install

([仮想環境名])~$ pip install --upgrade awscli

awscli が正しくインストールされたかを確認

$ aws --version

aws-cli/1.18.23 Python/3.8.0 Darwin/18.7.0 botocore/1.15.23

インストール成功しました！
この後awsコマンドも正常に利用できていることを確認できました！

まとめ

色々ググったけれど、公式サイトがなんやかんや最強でした。

参考・引用元
仮想環境に AWS CLI バージョン 1 をインストールする(公式サイト)

(ちなみに私はAWS CLI バージョン 2 をインストールしようとして失敗したので、バージョン 1 をインストールすることで解決しました。)
バージョン 2 インストール公式はこちら↓
Linux での AWS CLI バージョン 2 のインストール(公式サイト)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T10:41:50+09:00

Macの仮想環境上でaws-cliが実行できない時の解決方法(Python3.8インストール後)

経緯

pythonの仮想環境上で、aws-cliを使用しようと公式のコマンドを実行しようとしても上手くできなかったので、その解決方法の備忘録。
設定を色々いじってもダメだったので全部消してから再インストールしてみました。(2020/03)

仕様

Macbook: MacOS Mojave
Python: Python 3.8.0

aws-cliをインストール

公式に従い、以下を実行

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

しかし、$ aws --version でバージョン確認したところエラー発生

cannot execute binary file

デバッグ

色々試したものの、どれもうまくいかなかったので一度仕様してないファイルはきっちり消すため
$ rm '/usr/local/bin/aws'
$ rm '/usr/local/bin/aws_completer'
で削除を実行。

そこから

$ pip install --user virtualenv
$ virtualenv ~/[仮想環境名]

で新たに仮想環境を作成して

#仮想環境を activate
$ source ~/[仮想環境名]/bin/activate

新しい仮想環境に awscli を pip install

([仮想環境名])~$ pip install --upgrade awscli

awscli が正しくインストールされたかを確認

$ aws --version

aws-cli/1.18.23 Python/3.8.0 Darwin/18.7.0 botocore/1.15.23

インストール成功しました！
この後awsコマンドも正常に利用できていることを確認できました！

まとめ

色々ググったけれど、公式サイトがなんやかんや最強でした。

参考・引用元
仮想環境に AWS CLI バージョン 1 をインストールする(公式サイト)

(ちなみに私はAWS CLI バージョン 2 をインストールしようとして失敗したので、バージョン 1 をインストールすることで解決しました。)
バージョン 2 インストール公式はこちら↓
Linux での AWS CLI バージョン 2 のインストール(公式サイト)

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T09:18:23+09:00

DockerのMySQLコンテナが、永遠に再起動を繰り返すエラーの対処法

概要

事象

MySQLが動くDockerコンテナを、docker-composeで立ち上げようとしたところ、コンテナが永遠に再起動を繰り返す事象が起こりました。この問題の解決方法を、ここにメモしておきます。

ちなみに、私はWindows上でDocker Toolboxを用いていた時にこの問題が起こりましたが、それ以外の環境だとこの問題は起こらなさそうです（おそらく）。

docker-compose.ymlの設定

docker-compose.ymlのうち、この問題が起こる部分の設定は以下のようになっています。

  db:
    image: mysql:5.7
    volumes: 
      - "/tmp/db/data:/var/lib/mysql"
      - "./db:/usr/src/db"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: $MYSQL_ROOT_PASSWORD
      MYSQL_DATABASE: $MYSQL_DATABASE
      MYSQL_USER: $MYSQL_USER
      MYSQL_PASSWORD: $MYSQL_PASSWORD
    ports:
      - 3306:3306

特別な設定は何もしておらず、単純にmysql:5.7のイメージをベースに必要最低限の設定をしているのみです。

対処法

立ち上がったコンテナ内で、--innodb-use-native-aio=0を実行させます。なので、docker-compose.ymlは以下のようになります。

  db:
    image: mysql:5.7
    volumes: 
      - "/tmp/db/data:/var/lib/mysql"
      - "./db:/usr/src/db"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: $MYSQL_ROOT_PASSWORD
      MYSQL_DATABASE: $MYSQL_DATABASE
      MYSQL_USER: $MYSQL_USER
      MYSQL_PASSWORD: $MYSQL_PASSWORD
    ports:
      - 3306:3306
     command: --innodb-use-native-aio=0 # <- これ！

なぜこれで解決するのか

MySQLの公式ドキュメントには、以下のような記述があります。

InnoDB uses the asynchronous I/O subsystem (native AIO) on Linux to perform read-ahead and write requests for data file pages. This behavior is controlled by the innodb_use_native_aio configuration option, which applies to Linux systems only and is enabled by default.

InnoDB(MySQLのためのデータベースエンジン)はデフォルトでLinuxの非同期I/O(native AIO)を用いるように設定されていますが、この挙動はinnodb_use_native_aioオプションで変更できます。

今回私はWindows上でDocker Toolboxを用いてコンテナを動かしていたのですが、その場合だとこの非同期I/Oが利用できないため、エラーが起こり再起動が繰り返されていたようです。そのため、公式ドキュメントの上に引用した部分に書いてある通り、innodb_use_native_aioオプションで非同期I/Oを用いないように設定して、この問題を回避する必要があります。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T09:18:23+09:00

DockerのMySQLコンテナが、Docker Toolbox上で起動に失敗するエラーの対処法

概要

事象

MySQLが動くDockerコンテナを、docker-composeで立ち上げようとしたところ、コンテナが永遠に再起動(restart)を繰り返す事象が起こりました。この問題の解決方法を、ここにメモしておきます。

ちなみに、私はWindows上でDocker Toolboxを用いていた時にこの問題が起こりましたが、それ以外の環境だとこの問題は起こらなさそうです（おそらく）。

docker-compose.ymlの設定

docker-compose.ymlのうち、この問題が起こる部分の設定は以下のようになっています。

  db:
    image: mysql:5.7
    volumes: 
      - "/tmp/db/data:/var/lib/mysql"
      - "./db:/usr/src/db"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: $MYSQL_ROOT_PASSWORD
      MYSQL_DATABASE: $MYSQL_DATABASE
      MYSQL_USER: $MYSQL_USER
      MYSQL_PASSWORD: $MYSQL_PASSWORD
    ports:
      - 3306:3306

特別な設定は何もしておらず、単純にmysql:5.7のイメージをベースに必要最低限の設定をしているのみです。

対処法

立ち上がったコンテナ内で、--innodb-use-native-aio=0を実行させます。なので、docker-compose.ymlは以下のようになります。

  db:
    image: mysql:5.7
    volumes: 
      - "/tmp/db/data:/var/lib/mysql"
      - "./db:/usr/src/db"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: $MYSQL_ROOT_PASSWORD
      MYSQL_DATABASE: $MYSQL_DATABASE
      MYSQL_USER: $MYSQL_USER
      MYSQL_PASSWORD: $MYSQL_PASSWORD
    ports:
      - 3306:3306
     command: --innodb-use-native-aio=0 # <- これ！

なぜこれで解決するのか

MySQLの公式ドキュメントには、以下のような記述があります。

InnoDB uses the asynchronous I/O subsystem (native AIO) on Linux to perform read-ahead and write requests for data file pages. This behavior is controlled by the innodb_use_native_aio configuration option, which applies to Linux systems only and is enabled by default.

InnoDB(MySQLのためのデータベースエンジン)はデフォルトでLinuxの非同期I/O(native AIO)を用いるように設定されていますが、この挙動はinnodb_use_native_aioオプションで変更できます。

今回私はWindows上でDocker Toolboxを用いてコンテナを動かしていたのですが、その場合だとこの非同期I/Oが利用できないため、エラーが起こり再起動が繰り返されていたようです。そのため、公式ドキュメントの上に引用した部分に書いてある通り、innodb_use_native_aioオプションで非同期I/Oを用いないように設定して、この問題を回避する必要があります。

コンテナの再起動について

コンテナが再起動するのは、私がdocker-compose.ymlにrestart:alwaysを書いているからです。それ以外の場合は、普通にコンテナが落ちると思われます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-03-18T00:22:08+09:00

ユーザー名を変えようとしたらUbuntuが吹っ飛んだ

初めに

僕のノートPCにはWindowsとUbuntuがデュアルブートしてあって、普段の開発等はすべてUbuntuの方で行ってました。そんな中、ふと「Ubuntuのユーザー名変えたいな」という衝動に駆られたわけです。これが後に悪夢となろうとは。好奇心のままに動いただけの少年は絶望を味わうのです。100秒後に死ぬOS。

ユーザー名を変えようとしただけなのに

というわけで、最初にrootユーザーにログインしようとしました

[myname@ubuntu]$sudo su -
Password
[root@ubuntu]#

ここでパスワードを聞かれるのでパスワードを入力します。すると、真ん中の$がrootユーザーを示す#になり、左側の表示がちゃんとrootになりました。rootユーザーにログインできました。ここで

[root@ubuntu]#usermod -l 新ユーザー名 旧ユーザー名

を叩いて、ユーザーネームを変更し、続いて

[root@ubuntu]# cd /home
[root@ubuntu]# mv 旧ユーザ名/ 新ユーザ名/
[root@ubuntu]# vim /etc/passwd

でVim上でユーザー名を変更する所までしました。ここでですよ。ふと気付いたんですね。

日 本 語 入 力 が で き な い

Scrapboxとかに逐一情報をメモしてて気づいたのですがローマ字入力が効かなくなっていたんですね。僕のUbuntuはちょいちょい音割れを起こしたり、注意しないと文字入力のカーソルがあさっての方向に飛んだり、いろいろ不具合が観測されてたので、さして気にしませんでした。が、直後にまた異変が見られたんですね。

C h r o m e が 落 ち た

「どうやら内部でエラーが起こったようなので、Scrapboxに問い合わせてみてね」のと内容で、さすがに僕も「あ、なんかマズい」って思ったわけです。それで、さっきのVimの変更を戻したんですよね。すると、Scrapboxは復旧しました。よかった、日本語入力も治ったかな？

治 っ て な い

急いで元のユーザー名に戻しました。今覚えば、直した気になっていただけだったのかもしれませんひととおり治した後、一旦

[root@ubuntu]#exit

で一般ユーザーに戻った後、再び

[myname@ubuntu]$sudo su -

でrootユーザーにログインしてみました。するとどうでしょう。

#

左側のユーザー情報が一切表示されなかったんですよね。「やばばばばば。」何度も先ほどの手順をさかのぼり、ユーザー設定も見直しました。しかし一向にrootユーザー情報は表示されません。
「こうなったら再起動だ」と、Ubuntuを一回落として再起動させようとしました。
image.png
この画面から進むことはありませんでした。終わった。まさか再起動することなく、永遠の眠りにつかれるとは。しかし何分かした後、画面に変化がありました。「お！もどったか？」微かな期待を胸に抱きます。
image.png
非 情 な W e l c o m e

UIをMac風にカスタマイズし、春休み中に一緒にプログラミングの勉強をしようと毎日向き合っていたLinuxディストリビューションはもういないのです。あるのはもう、偽りのUbuntuだけ。幸か不幸か、コードのファイル群はほぼすべてGitHubに上げていたので大丈夫でしたが、サーバーの勉強会に行ったときに設定したSSH秘密鍵がお亡くなりになられました。これイチから設定できるのかな…しんどい…

image.png
※ちなみにUbuntuの復旧用のオプション開いたらこの有様だったので、新しくUbuntu入れるか、新しいLinuxディストリを入れることになりそうです

最後に言いたいです

どういった理由でデータが吹っ飛ぶかはわかりませんが、その時は突然やってきます。これがWindowsに起こらなくて本当に良かったです。皆さん、悪いことは言いません。今すぐPC上にあるすべてのファイルのバックアップを取りましょう。ソースコードはGitHubへ。ダウンロードしてきた画像？GooglePhotoに入れておけばひとまずは安心です。OS自体は吹っ飛んでも割と復旧が効きますが、おそらくファイル群は戻ってきません。僕と同じ目に合わないように、日ごろからバックアップを取っておくと、いざというときに被害を最小限に抑えられるでしょう

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧