それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

macでCPUの温度と使用率と周波数(クロック)をモニタリングする - Intel® Power Gadget

mac でCPUの利用状態をモニタリングする

Intel® Power Gadget というプログラムが提供されている。

s-tui では見れなかったので、別のソフトウェアを探していて行き着いた。

f:id:takuya_1st:20181115011430p:plain

しっかり表示されて嬉しい。

温度変化やCPUの変化、またコア数の利用率の変化を見ることができて楽しい。

ffmpeg で -threadオプションを使ったときや、スレッドプログラミングでGIL (global interpreter lock) を起こしてないかを見るのに使えそう。

モニタリングするタイミングを指定できる

f:id:takuya_1st:20181115011801p:plain

取得感覚を指定できるんでしっかり見れる。

参考資料

software.intel.com

関連資料

Linuxなら s-tui が手軽です。

ターミナルでCPUの使用率の変化を眺める。s-tui - それマグで!

NextCloudでメディアに余計なファイルが出ないよう非表示にする。

NextCloudのメディアに何でも出てくるのが困る。

ファイルのアーカイブとして使っている場合に、バックアップファイルが写真(メディア)の一覧に出てきて困る。

特定のフォルダが、写真(ギャラリー)の一覧に表示されないようにするには。ってずっと考えてた

とくに、ショートカットやリンクや設定を弄り回さなくても、ファイルを作るだけでいいとわかった。

消したいフォルダにcdして

cd /path/to/files
touch .nomedia

これだけ。

ファイルを作るのはどんな方法でも

上のように、 コンソールからやってもいい。他にもNextCloudのフォルダ画面からファイル作成でも良い。

.nomedia とは

Androidスマホなどではメジャー(?)な手法らしい。

参考資料

https://github.com/nextcloud/gallery/wiki/How-to-ignore-folders

Steps to follow

  1. Switch to the "Files" app
  2. Navigate to the folder you want to hide
  3. Click on the "New" button sitting above the list of files
  4. Type ".nomedia" as the filename You're done. The folder will be ignored in Gallery from now on. You can also create that file in your mobile or desktop OS and sync it with your ownCloud.

nextcloud をバックアップするのをスクリプト化

nextcloud のバックアップはちょっと面倒

nextcloud のバックアップにはひと手間が必要。occ コマンドにバックアップ用のサブコマンドが実装されていないので、手作業でバックアップする必要がある。

バックアップする対象

  • MySQL のデータベース
  • ユーザーのデータファイル
  • 設定ファイル

MySQLだとバックアップが面倒なので、SQLiteにすればよかったなと後悔してる。そんなにデータ入ってない。 メモリサイズの10%も超えること無いなら、メモリキャッシュが効くサイズだしSQLiteで十分だったわ。

MySQL のバックアップ

定番のバックアップコマンドですね

mysqldump --single-transaction -h ${db_host} -u ${db_user} --password=${db_pass} ${db_name} 2>/dev/null | gzip > ${dump} 

平文で入力するのがめんどくさそうなところですね。

バックアップスクリプトのIDが面倒。

バックアップスクリプトMySQLのパスワードを書くのは嫌なので、require/include して再利用可能にする。 幸いなことに、nextcloud の config は単体で読み込み可能になっていてこれを使えばいい

ファイルのバックアップ

ユーザーデータや設定ファイルのバックアップは個別にやる必要がありますが、私はめんどくさいので、フォルダごと転送することにした。

バックアップファイルの設置場所

nextcloud は次のようなフォルダ構成になっているため、 nextcloud の最上位のフォルダに置けばいいとわかる。

.
├── backup.php ## 設置
├── data
├── nextcloud
│   ├── apps
│   ├── config
│   ├── console.php
│   ├── core
│   ├── cron.php
│   ├── index.html
│   ├── index.php
│   ├── occ
│   ├── settings
│   ├── themes
│   ├── updater
│   └── version.php
└── tmp

上記の例ではnextcloudのソースコードの入ったディレクトリの一つ上に設置した。

こうすると大丈夫。nextcloud のソースコードの入ったディレクトリの中にファイルを置くと一貫性(integrity)のチェックでエラーになると思う。

php ファイル

<?php

/***
 *
 * 2018-11-05 nextcloudのバックアップする
 *  - MySQL をバックアップするスクリプト
 *  - データ
 *  - 稼働中のソース
 * @author takuya
 * @version 1.0
 *
 */


#########################################
# READ nextcloud database configuration
#########################################


$dir = dirname( __FILE__ );
$config_path = $dir. "/www-data/config/config.php";
if ( !file_exists($config_path ) ) {
  echo "config.php not found.\n";
  exit;
}

include $config_path;

$db_user = $CONFIG['dbuser'];
$db_pass = $CONFIG['dbpassword'];
$db_name = $CONFIG['dbname'];
$db_host = $CONFIG['dbhost'];

$nextcloud_path = "/var/www/virtualhosts/nextcloud.example.com/";
$dst_host = "takuya-oic-google-drive-epgrec";

#### set output filename
$date = date("Y-m-d");
$dump = "nextcloud-${date}-mysqldump.sql.gz";



#### rclone config
$rclone_conf = '/home/takuya/.config/rclone/rclone.conf';
#####################
## build commands
####################
$mysql_backup_cmd = "mysqldump --single-transaction -h ${db_host} -u ${db_user} --password=${db_pass} ${db_name} 2>/dev/null | gzip > ${dump} ";
$mysql_rclone_cmd = "rclone --config  ${rclone_conf}  copy ${dump}  ${dst_host}:backup/nextcloud.example.com/mysql_dump > /dev/null";
$mysql_remove_cmd = "rm ${dump}";


$data_rclone_cmd = "rclone --config  ${rclone_conf}  copy ${nextcloud_path}  ${dst_host}:backup/nextcloud.example.com/nextcloud  > /dev/null";

$cmds = array(
  $mysql_backup_cmd,
  $mysql_rclone_cmd,
  $mysql_remove_cmd,
  $data_rclone_cmd,
);


chdir('/tmp');
// echo getcwd();

foreach ( $cmds as $cmd ) {
  $ret = shell_exec($cmd . "; echo $?" );

  // echo $ret;
  if( $ret > 0  ){
    echo "Error occurred in comamnd ( '$cmd' ) ";
    exit();
  }

}

あとはこれをcronなどに登録する

実行権限は www-data か root で大丈夫。

sudo -u www-data php backup.php

今回はrclone を使ったが rsyncでも

rsync に変えても楽だと思う。sqliteならrsync で転送するだけで終わるんだけどなぁ。

だけどホストの証明書の取扱が面倒なので設定済みのrclone のconfig ファイルを使ったほうが楽でした。

参考資料

https://docs.nextcloud.com/server/14/admin_manual/maintenance/restore.html

ファイルの更新日時(アクセス時刻)を手早く実行する

ファイルの日時 を 手早く変更する

touch を使うと手っ取り早く実行できる。

ファイルの更新日時を更新する。

touch -m -d '2018-11-06 19:51' sample.txt 

ファイルのアクセス日時を指定の時間にする。

access time だから a ですね。

touch -a -d '2018-11-06 19:51' sample.txt 

日付のフォーマット

日付のフォーマットは、割と何でもいい。Linux なので GNU Dateが解釈できたら割と何でも通る。

touch -a -d 'yesterday ' sample.txt 
touch -a -d ' -3 days  ' sample.txt 

とかでも許される。ただし日付はGNU/Linuxの話なので、他でも動くかは環境次第.

日付の確認

確認には stat コマンドが便利です。

takuya@:~$ stat  sample.txt
  File: a
  Size: 0           Blocks: 0          IO Block: 4096   通常の空ファイル
Device: fe01h/65025d    Inode: 2102653     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/  takuya)   Gid: ( 1000/  takuya)
Access: 2018-11-03 19:56:06.360940272 +0900
Modify: 2018-11-06 19:53:46.801494007 +0900
Change: 2018-11-06 19:56:06.357969865 +0900
 Birth: -

関連資料

ファイルの属性情報を表示するコマンド stat - それマグで!

HTTP/2(http2)通信しているかChromeの開発ツールで確認する

http/2 通信をしているか確認したい。

Chromeの開発ツールで手軽に確認ができます。

開発ツールを開いて、ネットワーク・タブを開く

ネットワークタブのヘッダ行を右クリック

ヘッダ行を右クリックすると、いろいろ選べる。ここからプロトコルを選ぶと、HTTP2 通信かどうか確認できる。

HTTP/2のときは h2 と表示される。

f:id:takuya_1st:20181105165146p:plain

ちなみに、HTTPメソッドも確認できる

いちいり詳細をクリックしなくてもリモートアドレスやGET/POSTなどのメソッドも確認できて便利

f:id:takuya_1st:20181105165412p:plain

参考資料

https://edit.co.uk/blog/test-website-supports-http2-0/

廃棄HDDのデータを「シュレッダ」してデータ破壊し安全に廃棄する - 方法2 shred コマンドを使うときのポイント

HDDの消去してますか?

私はやってませんでした。物理的に破壊すればいいと思ってたので。

中古HDDなんてヤフオクに出してもクレームの嵐だし。

それでも一定需要があるので「安全に・手軽に」読めなくすることで安心してHDDを出品できるようにすればいい。

HDDの物理破壊で安全に破棄ですか?

HDDの物理破壊では危険です。物理破壊する業者が中間でデータを抜き去る可能性があります。

業務用PCの廃棄業者に丸投げするのも危険です。いくら契約で縛り付けようと、情報が一度流出してしまえば元も子もありません。

破棄するまえに、他社に移管する前で破壊しなくてはいけません。 しかし物理破壊するのはコストが高いです。

データを破棄する方法は3つあります。

  1. HDDなどストレージを暗号化しておく。
  2. shred コマンドでデータを全部上書きする
  3. ドリルドライバで物理破壊する

推奨されるのは、「データの暗号化」です。暗号化を複合する鍵がなければデータは読めません。iPhoneなどApple製品はこの方式です。

コマンドでデータを破棄する方法は物理破壊より時間はかかりますが、確実にデータを消去することができます。

物理破壊はコストも管理もずさんになるので全くおすすめしません。ところが世間では物理破壊がメインに採用されています。信じられない。

HDDってもったいないよね。

ふと思い出したんですよ。HDDって物理的に破壊する必要があるのかなって。

HDDって最近値下がりしてないし、まだまだ需要があるのかもって思い直しました。

HDDの物理的に破壊は必要ない。

HDDはシュレッダ(shred)コマンドにかけてデータを破壊するか、暗号化ディスクとして読めなければ十分ですよね。

暗号化はOS付属機能でかんたんに実現できるので、ここでは紹介しません。

今回は 「安全にデータを破壊する」方法です。

shred コマンドでHDDをきれいに消す

 shred -v /dev/sdX
## または
shred -vfz /dev/sdX

ポイント -v を忘れない

-v は進捗状況を表示するオプションなので、これをわすれるといつ終わるのかが全くわからなくなる。必ずつけること

shred は時間がかかる。

shred コマンドはランダムでファイルを書き換えていくのですごく時間がかかる。しかも3回やる。時間がかかる。本当にかかる。2TB消去するのに、数日とかかかる。

HDD の Write が 50MB/s 程度とすると、100MBに2秒 1000Mに20秒 1000*1000MBに 20,000秒 で、2.5日かかる

もし限界の150MB/s 程度が出たとしても、数回のランダムで埋め尽くすには 24時間程度じゃ足りない。

1回だけでいいよ

shred --verbose --random-source=/dev/urandom -n1 /dev/sbX

とにかく最低限で必要十分エントロピーを確保してなデータ消去ならコレで良い。

shred は時間がかかる。

hdd を shred に掛ける時間を測定する。

4TB のHDDを消去するのに、さて何分掛かるでしょうか。

使ったのは、WD4TB WD4ERFXです、だいたいこれくらいの速度が出ます。

takuya@m75q-1:~$ sudo time shred -vfz /dev/sda
[sudo] password for takuya:
shred: /dev/sda: pass 1/4 (random)...
shred: /dev/sda: pass 1/4 (random)...567MiB/3.7TiB 0%

4TBのShredに何時間かかったのか

user 12743.30
system 33:55:52

34時間です。結構かかりましたね。。。

shredするくらいなら

通常使うなら暗号化ディスクで十分ですね。

まさか、ディスク完全消去のソフトウェアを購入したり、ドリルで穴を開けたりしないでしょ。

SDDは注意が必要

shred コマンドでデータを消せない場合があります。SSDです。こいつはいまのところ上書きで消せません。そのため暗号化が必須になります。

いまのところ、SSDをセキュアに完全消去する用事がないので。。。リンクだけ置いときます。

https://wiki.archlinux.org/index.php/Solid_state_drive/Memory_cell_clearing

ATA Secure Erase - ata Wiki

2019-12-10 追記

安全に廃棄するにはドリルとかいうナンノコッチャな対策が世間を賑わせているので。このエントリが検索結果に上位に来るように書き直した。

こんなことを書いていると、ほんとうに思った通りの事件が起きて驚きました。

f:id:takuya_1st:20191210161635p:plain

参考資料

2021/11/10

shred 時間測定したので追記。

xargs でシェルのalias を使えるようにする方法。

xargs で alias が使えない

takuya@:教科書$ find -type d -maxdepth 1  | xargs ll
xargs: ll: そのようなファイルやディレクトリはありません

悲しい。Aliasはあくまで bashエイリアスであり、シェル経由せずにfork するような場合には全く役に立たない。linux のコマンド実行の仕組みを知っていると別に不思議でもなんでもないんだけど初心者にはコレが不思議らしい。

xargs で alias を使う方法

sudo のときと同じように再帰的なalias展開を使えば、なんとかなる時がある。

alias xargs='xargs '

これをすれば 、動く

takuya@:教科書$ find -type d -maxdepth 1  | xargs  ll
./2018-04-23-スキャンファイル:
合計 336K

でもオプションを渡せない。

alias の再帰的な展開に限界があるので、xargsにオプションつけたら、を渡せない

takuya@:教科書$ find -type d -maxdepth 1  | xargs -p ll
xargs: ll: そのようなファイルやディレクトリはありません

あああ、、振り出しに戻る。。

bashを指定したり

 find -type d -maxdepth 1  | xargs -I@ bash -c 'source ~/.bashrc;ll @'

設定を同時ロードするようにシェルを指定したり

 find -type d -maxdepth 1  | xargs -I@ bash -ic 'll @'

シェル経由だとどうしても不都合が

コマンド文字のエスケープがあるので、ファイル名に「空白」 「&」などが挟まると面倒なことになる。

alias を変数として持ってきたり

エイリアスが、bash_aliases変数にあることを利用して

 echo "${BASH_ALIASES[ll]}"
ls -l -h

これをつかって

 find -type d -maxdepth 1  | xargs -I@ ${BASH_ALIASES[ll]} @

などと出来なくもないが、良い解決策はないようです。

めんどくさいけど xargsのラッパを書くしか無い。

どうしても使いたいのであれば、 /usr/local/bin/xargs.sh を作って

引数のaliasを手作業で展開するしか無いと思う。めんどくさいわりに得られるものがないので作るのはしないけど。

#!/bin/bash 
# 引数を受け取ってalias を展開する
#xargs  に渡し直す

結論

諦めましょう。

参考資料

https://unix.stackexchange.com/questions/141367/have-xargs-use-alias-instead-of-binary

rcloneでバックアップ転送するときに設定を指定する

rclone でバックアップ便利です。

以前、rcloneについてのエントリを書きました。いまも便利に使っています。 rclone コマンドで google ドライブにデータを転送する(rcloneインストール方法と使い方) - それマグで!

バックアップ時にパーミッションエラー

root で実行すれば良いんですけど、指定したユーザーでないとアクセスが出来ないファイルのバックアップが出来なかったりするので不便です。( ~/.ssh/id_rsa など )

でも、設定ファイルをいっぱい書くのは管理が不便なのでめんどくさい。

config を指定して実行

config オプションを付ければ、設定を再利用できる。

rclone --config  /home/takuya/.config/rclone/rclone.conf sync $SRC  gdrive:$DST > /dev/null

config は、 ~/.config/rclone に保存されているので、そこを使えば設定を再利用できる。

rclone 便利ね

rclone だと手軽にクラウドをバックアップサービスに使えるから便利ね。

参考資料

https://rclone.org/commands/rclone_config/

gitlab-runner を削除する

gitlab-runner を削除したい

不要になった runner や、名前をつけ間違えたrunnerを削除したい。

でもGitLabのWeb側で削除したけど、残ってたので、よくわからなったのでまとめた。

gitlab側で削除されたランナーを見つけて消す方法

sudo gitlab-runner  verify --delete

実際に消したところ。

takuya@sakura:~$ sudo gitlab-runner  verify --delete
Running in system-mode.

Verifying runner... is alive                        runner=b1c83735
Verifying runner... is alive                        runner=00b62a52
Verifying runner... is alive                        runner=90cd2aef
Verifying runner... is alive                        runner=a4facb27
ERROR: Verifying runner... is removed               runner=5be0fea6
Updated /etc/gitlab-runner/config.toml

消した結果、一つ減りました。

takuya@sakura:~$ sudo gitlab-runner  verify --delete
Running in system-mode.

Verifying runner... is alive                        runner=b1c83735
Verifying runner... is alive                        runner=00b62a52
Verifying runner... is alive                        runner=90cd2aef
Verifying runner... is alive                        runner=a4facb27

--delete オプションで簡単です。unregister はgitlab-server 側から削除される前なら使えるんだけど、削除後はコレが一番簡単だと思う。

remove とか探したけどないし、 stop / start も違うしちょっと迷ったのでメモ。

yarn install/npm i でnode-gypがエラーになったときの原因が調べたらpyenvだった

いつものように npm i 決めてたら

エラーになりました。

node-pre-gyp WARN Tried to download(404): https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.4/fse-v1.2.4-node-v67-darwin-x64.tar.gz
node-pre-gyp WARN Pre-built binaries not found for fsevents@1.2.4 and node@11.0.0 (node-v67 ABI, unknown) (falling back to source compile with node-gyp)
gyp ERR! configure error
gyp ERR! stack Error: Command failed: /Users/takuya/.pyenv/shims/python2 -c import sys; print "%s.%s.%s" % sys.version_info[:3];
gyp ERR! stack pyenv: python2: command not found
gyp ERR! stack
gyp ERR! stack The `python2' command exists in these Python versions:
gyp ERR! stack   2.7.15

python2じゃないってエラーじゃん。

macOS の標準システムをターゲットに作られているのでpyenv が入っていたら消す。

対策

該当プロジェクトに入って

pyenv local  system

npm するまえに、pythonをシステム標準のものにする必要がある。怖い。

node-gyp がエラーになりだすと、gyp 関連で落ちてるのか、node のバージョンで落ちてるか、本当にわからない。

たいていは fsevent でエラーになるんだけど。npm マジ困る。

gitlab のログインをGoogleにする。(ユーザー初期登録も

gitlab の初期登録後に、Google ログインを有効にした

Google Oauth を使うと、Gitlab側でいちいちユーザーを作らずに済むので便利。

認証の設定について

Google OAuthの設定で2つの連携設定がある。

  1. 登録済ユーザーが各自で認証Googleアカウントを設定する
  2. 未登録ユーザーがGoogleでログインしたらユーザー作成

必要なもの

独自ドメインgoogle oauth で必要です。

httpsはあったほうが良い。っていうか今どきは当たり前。

google oauth の取得方法

Google アカウントでAPI Consoleにログインして、Google のOAuth用のWeb credential を作る。

  • API コンソールにログイン
  • プロジェクトを作成(なければ)
  • credential を作成
  • web アプリケーションで作成
  • ドメインに gitlab-ce のドメインをいれる。

oauth が準備できたら

gitlab の設定をする。

omnibus の場合 /etc/gitlab/gitlab.rb

Google Oauthでログインしたユーザをすぐに有効にする。

この設定が大事。

gitlab_rails['omniauth_block_auto_created_users'] = false

この設定を true にするとユーザ登録はできてもブロックされる。

ちなみにデフォルトはブロックです。 GoogleのOAuth連携できるユーザーはすべて無条件で許可されてしまいます。

この設定をfalse にすると google で認証されたユーザーは無条件に許可されるので、Gitlab側の設定で「ドメインに制限」を掛ける必要がある。

Gitlab側の設定では

  • /admin/application_settings から、
  • Sign-up restrictions
  • Whitelisted domains for sign-ups

とたどって許可したいドメインだけに限定しないと大変なことになる。

gitlab 側の設定

### OmniAuth Settings
###! Docs: https://docs.gitlab.com/ce/integration/omniauth.html
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['google_oauth2']
# gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
# gitlab_rails['omniauth_sync_email_from_provider'] = 'saml'
# gitlab_rails['omniauth_sync_profile_from_provider'] = ['saml']
# gitlab_rails['omniauth_sync_profile_attributes'] = ['email']
# gitlab_rails['omniauth_auto_sign_in_with_provider'] = 'saml'
gitlab_rails['omniauth_block_auto_created_users'] = false
# gitlab_rails['omniauth_auto_link_ldap_user'] = false
# gitlab_rails['omniauth_auto_link_saml_user'] = false
gitlab_rails['omniauth_external_providers'] = ['google_oauth2']
gitlab_rails['omniauth_providers'] = [
  {
    "name" => "google_oauth2",
    "app_id" => "xxxxxxxxxxxxxxx0dse47iulk.apps.googleusercontent.com",
    "app_secret" => "xxxxxxxxxxxxxxxxxx",
    "args" => { "access_type" => "offline", "approval_prompt" => "" }
  }
]

ログインチェック

設定したら gitlab を reconfigure してログインをチェックする。コレが大事。

ぱぱっとやれば大丈夫。

参考資料

https://docs.gitlab.com/ee/integration/google.html

LVMのVG構成をバックアップする

VGの構成をバックアップするコマンドがある。

VG構成はディスクを再利用するときにどうなってたかわからないと再現が難しい。とくに複数のPVをVGにまとめてから切り出しているときなど。

takuya@:~$ sudo vgcfgbackup
  Volume group "data" successfully backed up.
  Volume group "home" successfully backed up.

vgcfgbackup を使って構成をバックアップとっておくとちょっとだけ安心できる。

リストア(復旧・リカバリ)するには vgcfgrestore を使う。

vgcfgrestore -f /etc/lvm/backup/home home

試したいけど、LVM環境を作って試すのがめんどくさいのでメモ程度。

GitlabのSSHアクセスで、標準22以外のポートを使えるように設定する

gitlabのssh ポートを変えたい

Gitlabでpushするssh のポートを自分の独自のポートにしたい。

自宅サーバーで運用してたり、セキュリティ的な問題でポート22番以外を使ってるとき、gitlabでsshを使おうとするとデフォルトの22ポートになるので不便。

かといって、.ssh/config で設定するのもめんどくさい。

調べたらできることがわかった。gitlab ホント柔軟に使えるな。

22 → 2222

設定ファイルを書き換えて再起動でオッケ

/etc/gitlab/gitlab.rb

gitlab_rails['gitlab_shell_ssh_port'] = 2222

再起動

gitlab-ctl reconfigure

これでコピペするURLにポートが含まれるようになる。わーい。

参考資料

MacでIPv6をオフにして無効化する

IPv6をオフにする。

フレッツ光ネクストを使っていると、例の壊れたv6がWiFi経由で割り振られて辛い。

個人的には、v6のほうが空いているし、フレッツIPv6網の通信は高速なので使いたいんだけど、まだまだv4です。v6→v4 のフォールバックが発生するのが悲しい

内線外線がないGWで守れない通信は正直つらいところ。フレッツ機器でv6を使いたいし網内折返しをフィルタリングをしたいんだけど、、、不便だよね。

もうv6オフにしちゃおう

sudo networksetup -setv6off Wi-Fi

WiFiの名前は

 networksetup -listallnetworkservices

これで取得することができる

参考資料

  • networksetup -h

sudo su実行後も環境変数を維持する

suの実行後にカレントディレクトリを維持したい

su を実行するとカレントディレクトリが変わってしまうので、いまいるディレクトリやeditor 変数をそのままに 別ユーザーになりたい。

sudo -E を使う

sudo にオプションを付ければ、カレントディレクトリなど現在の環境をそのまま維持してsu することができる。

sudo -E su

man sudo から抜粋

      -E, --preserve-env
                   現在の環境変数をそのまま保持するのがユーザの意向だと、セキュリティポリシーに指示する。 ユーザが環境を保持する許可を持っていない場合は、 セキュ                                                                            
                   リティポリシーがエラーを返すことになるだろう。                                     

/etc/sudoers の設定と密接な関係

環境変数の設定と維持は sudoers の設定と密接な関係にある。

私の場合、sudo 実行時に余計な環境変数を持ち込みたくないのでリセットしている。というかディストリビューションのデフォルトはほとんど場合が環境変数を初期化するはずだ。

sudoers

Defaults  env_reset

この設定があれば、 /etc/environment の設定で環境変数がリセットされるはずだ。

sudoersで環境変数を維持することにする?

sudo -E を毎回付けるのが面倒な場合は env_reset を消してしまえばいい。 

個人用のLinux Desktop だと便利だと思う。 ただ、共有のサーバーなどでこれをやると知らないあいだに alias 書き換えられてたりして、気づかずマルコマンドを実行する恐れがあって怖い。

なので、他の設定 etc_keep や set_env を sudoersで組み合わせて必要な環境変数だけ持ち込むのがベターだとおもう。これらのついては、はどこか別の機会に

参考資料

  • man sudo
  • man 5 sudoers

関連資料

http://takuya-1st.hatenablog.jp/entry/2018/10/17/023000