What's New Qiita

20191002のLinuxに関する記事は10件です。

  • 投稿日：2019-10-02T22:49:39+09:00

【目からウロコ！】historyのインデックス番号から、簡単にコマンド実行する方法

何かとお世話になってるhistoryコマンド

「あれ？ssh接続するときのコマンドってなんだっけ？」

「mysqlコマンドで指定してたホスト忘れた」

そんなとき、historyコマンドを使って履歴をコピペしてました。

、、、今までは。

historyからのコピペはやめよう

試しにコマンド履歴を見てみます。

たくさんの履歴を見ても仕方ないので、例のように直近の7件だけを表示する場合は、 tail -7 のように件数を指定します。
参考：historyコマンドで最新の数件だけを取得する

$ history | tail -7
  536  cd Desktop/
  537  ls
  538  ruby ruby.rb 
  539  irb
  540  vim ruby.rb
  541  ruby ruby.rb 
  542  history | tail -7

そしていよいよ本題。

例えば538のruby ruby.rbを再度実行したいとき、なんとこんなコマンドが使えるんです。

$ !538

はい、とっても簡単ですね！

Fin

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T19:34:38+09:00

iMacでHerokuにCLIログインしてみる

目標

macOSにHeroku CLIをインストールしてログインする

Linux初心者です。諸般の事情によりMacを使う事になったのでいろいろやってみます。
今回はHerokuというものにMacからターミナルからアクセスします。

いや、Herokuってなにかなー　なんかWebアプリを簡単にデプロイできて、公開もできて、にしては安いって事を聞いて、いろいろ見て回って無料アカウントも作ってみたんです

で、このページ (ログインしないと見れません)で、おっ、Node.jsのアプリも行けるんだぁ　と、Node.jsのアイコンをクリックしたらチュートリアルっぽい画面になって、「うし、やってみるか」って事で"I'm ready to start"ボタンを押した以降が↓です。

参考にさせていただいたページ

Herokuってなんなの？
Heroku初心者がHello, Herokuをしてみる
HomeBrewでgitを入れる（エラーから解消まで
macでheroku deploy
Herokuを使いこなすのに必要な術
herokuで本番環境までを構築する上で知っておきたいこと

準備

  • macOS Mojava v10.14.6
  • Homebrew v2.1.11
  • Heroku(webページで)アカウント作成済み

Heroku Command Line Interface (CLI)のインストール

どうもHerokuをいろいろするのには、Web画面からもできるらしいけれど、ローカルPCにコマンド・ライン・ツール(CLI)をインストールするといいらしい。
なのでインストールします。

  • インストーラーも提供されているようだけど、とうせならという事でHomebrewでインストールする
  • Homebrew用コマンドもちゃんと書いてくれている事ので、それで
$ brew install heroku/brew/heroku
  • heroku/brew というリボジトリにある heroku をインストールしろ　って事ですね
  • いあいあ、私のHomebrewに heroku/brew はTapされてないし
$ brew tap
caskroom/cask
homebrew/cask
homebrew/core
  • という事でせっかくなのでTapから行きます
$ brew tap heroku/brew
・・・
・・・
==> Tapping heroku/brew
Cloning into '/usr/local/Homebrew/Library/Taps/heroku/homebrew-brew'...
remote: Enumerating objects: 10, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 10 (delta 0), reused 7 (delta 0), pack-reused 0
Unpacking objects: 100% (10/10), done.
Tapped 2 formulae (38 files, 28.6KB).
  • そして Heroku のインストール
$ brew install heroku
==> Installing heroku from heroku/brew
Error: Xcode alone is not sufficient on Mojave.
Install the Command Line Tools:
  xcode-select --install
  • このMacにxcode-select 入ってなかった・・・
  • なので指示どおりにインストール
$ xcode-select --install
  • 再度、Heroku のインストール
$ brew install heroku
・・・
・・・
Error: An exception occurred within a child process:
  Errno::EPERM: Operation not permitted @ dir_s_mkdir - /usr/local/Cellar
  • エラーです・・・。　/usr/local/Cellar というディレクトリが権限無くてつくれないみたい
  • sudoで実行してみます
$ sudo brew install heroku
Password:
Error: Running Homebrew as root is extremely dangerous and no longer supported.
As Homebrew does not drop privileges on installation you would be giving all
build scripts full access to your system.
  • なんか怒られました
  • Homebrew 自体を調べます
 $ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: The following directories do not exist:
/usr/local/include
/usr/local/lib
/usr/local/opt
/usr/local/sbin
/usr/local/Cellar

You should create these directories and change their ownership to your account.
  sudo mkdir -p /usr/local/include /usr/local/lib /usr/local/opt /usr/local/sbin /usr/local/Cellar
  sudo chown -R $(whoami) /usr/local/include /usr/local/lib /usr/local/opt /usr/local/sbin /usr/local/Cellar
Dice-no-iMac:~ dice$ 

$ brew install heroku
・・・
・・・
==> Summary
?  /usr/local/Cellar/heroku/7.33.0: 18,675 files, 49.4MB, built in 46 seconds
==> `brew cleanup` has not been run in 30 days, running now...
==> Caveats
==> heroku
To use the Heroku CLI's autocomplete --
  Via homebrew's shell completion:
    1) Follow homebrew's install instructions https://docs.brew.sh/Shell-Completion
        NOTE: For zsh, as the instructions mention, be sure compinit is autoloaded
              and called, either explicitly or via a framework like oh-my-zsh.
    2) Then run
      $ heroku autocomplete --refresh-cache

  OR

  Use our standalone setup:
    1) Run and follow the install steps:
      $ heroku autocomplete

Bash completion has been installed to:
  /usr/local/etc/bash_completion.d

zsh completions have been installed to:
  /usr/local/share/zsh/site-functions
  • インストール成功です
  • なんかbrew cleanupしろとアドバイスしてくれてます。
  • 指示にしたがってコマンドを実行します
$ heroku autocomplete --refresh-cache
Building the autocomplete cache... ?
heroku: Press any key to open up the browser to login or q to exit: Building the
  • とりあえずEnterキー押すと、Webブラウザが立ち上がって"Log in to the Heroku CLI"画面が表示されます
  • ログインするとターミナルの方に伝わって done となります
Opening browser to https://cli-auth.heroku.com/auth/browser/df07f955-xxxxx-xxxx-xxxxx-xxxxxxxxxx
heroku: Waiting for login... done
  • のタイミングでPCいきなり無言でダウン・・・画面真っ暗ですorz
  • 電源入れて、いざログイン
$ heroku login
heroku: Press any key to open up the browser to login or q to exit: 
Opening browser to https://cli-auth.heroku.com/auth/browser/206ec5fc-xxxx-xxxx-xxxx-xxxxxxxxxxx
Logging in... done
Logged in as <<登録したメールアドレス>>
  • ログイン成功
  • ちゃんとログインログインできてるのかわかりずらい
  • とりあえず確認
$ heroku --version
heroku/7.33.0 darwin-x64 node-v11.14.0
  • ローカルのnodeとはバージョンが違うからHerokuの中にいるのかしらん
$ heroku apps
You have no apps.
  • うん、一応繋がってるみたい
  • では、ログアウト
$ heroku logout
Logging out... done
  • お疲れ様でした

おわりに

いきおいでやり始めたので、ログインできた時点で力尽きました
やはり、コマンドラインだけの世界にはまだ慣れないです

Windowsユーザーのみなさんの参考になればと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T19:12:02+09:00

【目からウロコ！】historyのインデックス番号から、簡単にコマンド実行する方法

何かとお世話になってるhistoryコマンド

「あれ？ssh接続するときのコマンドってなんだっけ？」

「mysqlコマンドで指定してたホスト忘れた」

そんなとき、historyコマンドを使って履歴をコピペしてました。

、、、今までは。

historyからのコピペはやめよう

試しにコマンド履歴を見てみます。

たくさんの履歴を見ても仕方ないので、例のように直近の7件だけを表示する場合は、 tail -7 のように件数を指定します。
参考：historyコマンドで最新の数件だけを取得する

$ history | tail -7
  536  cd Desktop/
  537  ls
  538  ruby ruby.rb 
  539  irb
  540  vim ruby.rb
  541  ruby ruby.rb 
  542  history | tail -7

そしていよいよ本題。

例えば538のruby ruby.rbを再度実行したいとき、なんとこんなコマンドが使えるんです。

$ !538

はい、とっても簡単ですね！

Fin

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T19:06:18+09:00

iptablesのパケットフィルタの基本コマンド例

iptablesの基本的な使用例についてのメモ。
最初に使いたくなるのはfilterテーブルだと思うのでfilterテーブルでパケット破棄するルールの設定例を紹介する。

まずはパケットのフィルタリングテーブルを表示

iptables -nvL　でfilterテーブルの内容を確認できる。

# iptables -nvL
Chain INPUT (policy ACCEPT 798 packets, 69179 bytes)
 pkts bytes target     prot opt in     out     source          destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source          destination         

Chain OUTPUT (policy ACCEPT 793 packets, 70755 bytes)
 pkts bytes target     prot opt in     out     source          destination         
#

パケットのフィルタリングを設定してみる

UDPで送信元IPアドレスが10.10.10.0/24で、送信先アドレスが20.20.20.5で、送信先ポート番号が20000で、eth0インタフェースに入ってくるパケットを、破棄する設定を入れるコマンドはこんな感じ。

# iptables -A INPUT -p udp -i eth0 -s 10.10.10.0/24 -d 20.20.20.5 --dport 20000 -j DROP
  • チェインについて
    入ってくるパケットに対しては INPUT チェインを指定。送信するパケットに対しては OUTPUT チェイン、転送するパケットに対しては FORWARD チェイン。
    -A [チェイン] でルールを追記。
    -I [チェイン] [数字] でルールを数字で指定されたインデックスに挿入。

  • プロトコルについて
    -p でプロトコル指定(tcp / udp / icmp)。

  • NWインタフェースについて
    -i でパケットが入ってくるインターフェース名を指定。

  • IPアドレス、ポート番号について
    -s で送信元IPアドレス、-dで送信先IPアドレス、--dportで送信先ポート番号の指定。

  • パケットの処理方法について
    -j でパケットの処理方法を指定(DROP(破棄) / ACCEPT(許容) / REJECT(拒否))。

再度filterテーブルを確認。

コマンド投入後にルールを再表示するとこんな感じでINPUTチェインにルールが追加されたことがわかる。

# iptables -nvL
Chain INPUT (policy ACCEPT 121 packets, 9944 bytes)
 pkts bytes target     prot opt in     out     source          destination         
    0     0 DROP       udp  --  eth0   *       10.10.10.0/24   20.20.20.5        udp dpt:20000

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source          destination         

Chain OUTPUT (policy ACCEPT 110 packets, 9142 bytes)
 pkts bytes target     prot opt in     out     source          destination

IPパケットのフィルタリングを削除

ルールの解除は、設定投入時のコマンドに対し、-Aを-Dに変更するだけでOK。

# iptables -D INPUT -p udp -i eth0 -s 10.10.10.0/24 -d 20.20.20.5 --dport 20000 -j DROP

あるいは、インデックス指定でも削除可能。

# iptables -D INPUT 1

ルールの全消し

ルールをすべて削除したいときは -F オプション。危険なので気軽に打たないこと。

# iptables -F

もっと深くしりたい？

  • 他のオプションについて
    iptablesの全オプションはこちらのURLが参考になります。
    https://linuxjm.osdn.jp/html/iptables/man8/iptables.8.html

  • チェインやテーブルについて
    チェインには、今回紹介した INPUT / OUTPUT / FORWARD の他にも、PREROUTING / POSTROUTING などがあります。
    また、テーブルについても、今回のフィルタ(filter)テーブルの他にも nat や mangle などがあります。
    これらのチェインやテーブルは、パケットフローの中でどの部分にルールを適用するかによって使い分けることになります。

    パケットフローの仕組みは以下の図が参考になります。iptablesの領域は「Network Layer」の箇所です。
    https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T15:55:22+09:00

Linuxコマンドチートシート(プロセス・メモリ・ディスク編)

はじめに

この記事は Linux 環境でのプロセス、メモリ、ディスクの状況確認のために使う自分のためのコマンドのチートシートです。
適宜更新していきます。

プロセス

プロセスの一覧取得

OS上で動いているすべてのプロセスをCPUやメモリの使用率も表示して確認するのは以下のコマンド。

$ ps aux

ここから特定のキーワードでプロセスを検索したいときは grep を用いるとよい。

$ ps aux | grep node

仮想メモリ使用量でソートするは以下の感じ。

$ ps aux | sort -rnk 5

子プロセスを考慮してプロセスをツリー表示する場合は以下を使う。

$ pstree -p

プロセスの正常終了

$ sleep 600 &
[1] 9087
$ ps
  PID TTY          TIME CMD
 6991 pts/0    00:00:00 bash
 9087 pts/0    00:00:00 sleep
 9088 pts/0    00:00:00 ps
$ kill 9087
$ ps
  PID TTY          TIME CMD
 6991 pts/0    00:00:00 bash
 9142 pts/0    00:00:00 ps

指定のプロセスが開いているファイルを調べる

$ sudo lsof -p ${pid}
COMMAND  PID USER   FD      TYPE             DEVICE SIZE/OFF       NODE NAME
dockerd 1104 root  cwd       DIR              259,5     4096    5376151 /var/snap/docker/384
dockerd 1104 root  rtd       DIR                7,1      321      12827 /
dockerd 1104 root  txt       REG                7,6 79888528         14 /snap/docker/384/bin/dockerd
dockerd 1104 root  mem-W     REG              259,5    32768     656392 /var/snap/docker/common/var-lib-docker/buildkit/cache.db
dockerd 1104 root  mem-W     REG              259,5    16384     656370 /var/snap/docker/common/var-lib-docker/buildkit/metadata.db
dockerd 1104 root  mem-W     REG              259,5    16384     656367 /var/snap/docker/common/var-lib-docker/buildkit/snapshots.db

指定のファイルを開いているプロセスIDを調べる

$ lsof ${filepath}

指定のプロセスが開いているファイルを調べる

$ lsof -p ${pid}

各プロセスの通信に使用しているポートなどを確認する

$ lsof -i

メモリ

メモリ使用量をMB単位で表示する。

$ free -m
              total        used        free      shared  buff/cache   available
Mem:          15935        2259       11752         158        1923       13168
Swap:          2047           0        2047

Memは物理メモリ、Swapはディスク上のスワップ領域となります。

shared は主に tmpfs ファイルシステムで使われている領域のサイズを表す。
Ubuntu だと /dev/shm などにマウントされている。

ファイルの読み込み時にメモリにキャッシュするのだが、buff/cache は現在メモリでキャッシュしている領域のサイズを指す。

Mem の used はプロセスなどが使っている物理メモリ使用量。buff/cache は含まない。
Mem の free も buff/cache を含まない空いている物理メモリ領域を指す。
Mem の available は開放可能である buff/cache も含めた利用可能な物理メモリ領域を指す。

ディスク

指定のファイルのメタデータを確認する

$ stat examples.desktop 
  File: examples.desktop
  Size: 8980        Blocks: 24         IO Block: 4096   通常ファイル
Device: 10305h/66309d   Inode: 3934242     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    teru)   Gid: ( 1000/    teru)
Access: 2019-10-01 22:07:22.533667350 +0900
Modify: 2019-09-28 19:50:24.095516675 +0900
Change: 2019-09-28 19:50:24.095516675 +0900
 Birth: -

ディレクトリ内の各ファイルの inode 番号を調べる

$ ls -i

各ファイルシステムの容量確認

$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             8135284        0   8135284   0% /dev
tmpfs            1631836     2132   1629704   1% /run
/dev/nvme0n1p5  86053984 14722548  66917024  19% /
tmpfs            8159168   109296   8049872   2% /dev/shm
tmpfs               5120        4      5116   1% /run/lock
tmpfs            8159168        0   8159168   0% /sys/fs/cgroup

各ファイルシステムのinodeの利用率

$ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
udev           2033821    646 2033175    1% /dev
tmpfs          2039792   1200 2038592    1% /run
/dev/nvme0n1p5 5505024 376935 5128089    7% /
tmpfs          2039792    226 2039566    1% /dev/shm
tmpfs          2039792      5 2039787    1% /run/lock
tmpfs          2039792     18 2039774    1% /sys/fs/cgroup

その他

指定の秒ごとにコマンドを実行して結果を表示し続ける

10秒ごとに更新してプロセス一覧を表示し続ける。

$ watch -n 10 ps aux

参考資料

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T14:47:47+09:00

【インフラ】問合せフォームで蹴られた意外な理由とは？

※ 実話です (´・ω・｀)

皆さんも考えてみてください

ある企業（Ｄ社）に問い合わせをするため、
Ｄ社のｗｅｂサイトの「問合せフォーム」を利用しました。

●氏名
ほげほげ太郎

●返信用メールアドレス
xxxx@example.com

●問い合わせ内容
かくかくしかじか。かくかくしかじか。かくかくしかじか。

これらを記入し投稿しました（ブラウザ上は正常終了）。
すると記入したメールアドレスに、下記のメールが届きました。

●件名
Mail delivery failed : returning message to sender

●本文
This message was created automatically by XXXXXXX.

A message that you sent could not be delivered to all of its recipients.
This is a permanent error. The following address(es) failed:

xxxx_xxxxxxx_xxxxx@xxxxxxxx.com
host xxxxxxxx.xx.xxxxxxxxxxx.com [XX.XX.XX.XX]
SMTP error from remote mail server after end of data:
553-SPF (Sender Policy Framework) domain authentication
553-fail. Refer to the Troubleshooting page at
553-http://xxx.xxxxxxxxxxxxx.com/troubleshooting for more
553 information. (#5.7.1)

さて、これは何を意味するのでしょうか？
問合せフォームと、何か関係あるのでしょうか？
そもそも問い合わせは、受理されたのでしょうか？

解答

問い合わせは、受理されなかった 可能性が高いです。
上記の英文メールも、問合せフォームに関係があります。

解説

上記の問合せフォームは、おそらく、投稿内容をメールで転送する仕組みです。
私たちがフォームで投稿すると、Ｄ社の問合せ担当にメールが届きます。

それ自体は問題ありません。しかし、転送メールの組み立てに問題がありました。
メールの差出人(From)、および、エンベロープFrom(Return-Path)に、
私の記入した「返信用メールアドレス」をセットしていました。

つまり、あたかも私のメールアドレスから直接、
Ｄ社に送信したように加工していたのです。

これは何を意味するでしょうか？
そうです。「なりすまし」です！ 上記の加工は、From の偽装そのものです。

From 偽装のメールを、Ｄ社のメールサーバに送ると どうなるか？
（実際はＤ社からＤ社へ送っているのですが）
スパム判定ツールが「なりすまし」と見なし、メールを拒否します。

そりゃそうです。Ｄ社のＩＰアドレスからは来るはずのない
差出人 xxxx@example.com のメールが飛んでくるのですから。

しかも面白いことに、拒否されたという通知（冒頭の英文メール）が、
Return-Path の xxxx@example.com （つまり私）に送られたのです。
私は なりすましメールなど送っていないのに、です。

（フォーム投稿しただけなんだけど。）

疑問

ただ それだと、すべてのフォーム投稿が拒否されるはずです。
投稿のたびに なりすましメールが送信され、スパム判定され、
捨てられるのですから。

でも実際は逆で、ほとんどの問い合わせがスパム判定にパスし、
受理されているに違いありません。

じつは、記入したメールアドレス（xxxx@example.com）だから
拒否された理由があったのです。

ＳＰＦ

冒頭の英文メールのＵＲＬにアクセスすると、このような説明がありました。

If the Env Sender publishes a hard-fail SPF policy and the inbound email fails SPF verification,
the action of block and delete will be enforced and a 5xx error is returned to the sender.
SPF records set to soft-fail will not trigger the action.

要するに なりすましの場合、ＳＰＦに -all(hard-fail) の設定があれば
エラーとして扱います。ただし ~all(soft-fail) なら受理します、と。

たしかに xxxx@example.com のＳＰＦは、
-all(hard-fail) という厳密な設定をしていました。
それゆえ、問い合わせがエラーとして扱われたのでしょう。

いやいや（笑）

Ｄ社の担当者さん、そうじゃないでしょう。
じゃ、ＳＰＦに -all(hard-fail) は使えないのですか？
ウチが ~all(soft-fail) に変えなきゃいけないのですか？

Ｄ社内で勝手になりすましメールを送って、
これまた勝手に拒否しているんでしょう？
変えるとしたらＤ社の問合せシステムですよね？

まずメールの差出人(From)を、Ｄ社の固定のメールアドレスにする！
（これで、なりすましでは無くなります。）

そして必要なら、返信用メールアドレス（xxxx@example.com）は
Reply-To に設定する！（決して From, Return-Path ではない。）

（あるいは問い合わせの転送メールのみ、スパム判定をスルーするとか。）

強制 問い合わせ！

さて、愚痴ったところで、このままでは永遠に問い合わせができません。
私は以下をおこないました。

じつは冒頭の英文メールには、本来 届くはずだった問合せメールが添付されていました。
その内容を そっくりそのままコピーし、私のＰＣのメーラーから送りました。
正規のＩＰアドレスから送るのだから、今度は なりすましではありません。

（もし届いたとき、Ｄ社の担当者がメールを見たら、
「なんかフォントが違うなぁ」くらいは思ったかもしれません。）

結局、問い合わせは受理されたようで、後日 回答メールが届きました。

コマンド

ＳＰＦ（ＴＸＴレコード）の確認は、Linux(CentOS7)の場合、dig を使います。

dig txt xxxx.com

参考

SPF（Sender Policy Framework） : 迷惑メール対策委員会

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T12:11:53+09:00

Linux基礎(SUID/SGID/Sticky Bit)

SUID

Linuxでは、ユーザはUIDと呼ばれるID番号で管理されている。一時的に別のUIDのユーザに変更できる機能のことをSUID(Set User ID)という。SUIDで一般ユーザがroot権限でファイルを実行できる。
※通常の実行ファイルは実行者の権限で動作するが、SUIDが設定されていると実行ファイルの所有者権限で動作させられる。

SUIDの使用例をみる。例えばパスワード変更は、/etc/shadowファイルを編集する必要があるが、このファイルの変更権限は一般ユーザにはない。しかし、パスワード変更コマンド(passwd)にはSUIDが設定されているため、一般ユーザがpasswdコマンドを実行した場合においても、passwdコマンドの所有者であるroot権限で実行できる。なおSUIDが設定されているファイル（プログラム）においては所有者の実行権限が「s」と表記される。

$ ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 25980 Feb 22 2012 /usr/bin/passwd

上のコマンド結果では所有者（root）のアクセス権は「rws」となっており、実行権が「s」であることがわかる。つまり、このコマンドを実行可能なアクセス権を有する一般ユーザーによりプログラムが実行された場合はこのファイルの所有者(root)の権限で実行できることを意味する。

アクセス権を決定するchmodコマンドでSUIDを設定する場合は、アクセス権表記に「4000」を加算する。つまり元が755(rwx r-x r-x)のファイルの場合は「4755」と設定する。すると 「rws r-x r-x」となる。
chmodによるアクセス権の設定は数値で定義する方法と、3つの記号（u+s)を用いた方法の2種類ある。

# 実行例 ： test.txt ファイルのアクセス権を「 rws r-x r-x 」にする設定
$ chmod 4755 test.txt |

# 実行例 ： test.txt ファイルのアクセス権が変更前「 755 」である値を、変更後に「 4755 」とする設定 (SUID)
$ chmod u+s test.txt |

SGID

SGIDはグループ権限で動作する。SUIDの場合は、所有者権限の実行権限が「s」となるが、SGIDではグループの実行権限が「s」となる。chmodコマンドでSGIDを設定する場合、アクセス権表記に「2000」を加算する。文字列の場合には(g+s)を定義

# 実行例 ： test.txt ファイルのアクセス権を「 rwx r-s r-x 」にする設定
$ chmod 2755 test.txt |

# 実行例 ： test.txt ファイルのアクセス権が変更前「 755 」である値を、変更後に「 2755 」とする設定 (SUID)
$ chmod g+s test.txt |

スティッキービット(Sticky Bit)

Sticky Bitが設定されたディレクトリ以下のファイルとディレクトリは、実際に設定したアクセス権に関係なくて、所有者とrootユーザのみが名前の変更と削除を行える。このスティッキービットが使用されるケースは「全ユーザがファイルを作成できるが作成したファイルを他人がファイル名の変更や削除できないようにしたい」場合に利用する。例えば/tmpディレクトリにはスティッキービットが設定済み。
スティッキービットでは他のユーザの実行権限が「t」となる。chomodコマンドでスティッキービットを設定する場合、アクセス権表記に1000を加算する。文字列の場合は3つの記号（o+t）を定義

# 実行例 ： testディレクトリのアクセス権を「 rwx rwx rwt 」にする設定
$ chmod 1777 test|

# 実行例 ： testディレクトリのアクセス権が変更前「 777 」である値を、変更後に「 1777 」とする設定 (SUID)
$ chmod o+t test|

SUID/SGID/StickyBitの違い

比較項目 実行権限の設定対象 加算するアクセス権の表記 加算するアクセス権の表記(3つの記号)
SUID 所有者 4000 u+s
SGID グループ 2000 g+s
StickyBit その他のユーザ 1000 o+t

umaskコマンド

umaskコマンドは、umask値の確認とumask値の設定を行うコマンド。新規作成したファイルやディレクトリのアクセス権はファイルの場合「666」からumask値を引いた値、ディレクトリの場合「777」からumask値を引いた値となる。rootユーザのumask値のデフォルト値は「0022」。従い、新規に作成されるファイルのアクセス権は644(666-022=644)となり、新規作成のディレクトリのアクセス権は755(777-022=755)

# umack値の確認
$ umask

#umask値を0022から、0027に変更する設定
$ umask 0027
#このumask値が適用されるユーザが作成した新規ファイルのアクセス権は（-rw r-- ---）となる。

chown/chgrpコマンド

chownコマンドはファイルやディレクトリの所有者を変更するコマンド。root権限のユーザのみ実行できる。
chgrpコマンドはファイルやディレクトリの所属するグループを変更するコマンド。

オプション 説明
-R 指定したディレクトリ以下の全てのファイルの所有者の変更 
# test.txtファイルの所有者を「tom」に変更
$ chown tom test.txt

# test.txtファイルの所有者を「tom」に変更、グループを「group1」に変更
$ chown tom:group1 test.txt

# test.txtファイルのグループを「tom」に変更
$ chgrp group1 test.txt
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T11:02:06+09:00

Bashが人気だが、大規模システムにおけるBashと同等に求められるプログラム言語の話をしよう

Bashとは

「シェル」の一つのことであり、「シェル」とはLinuxやUNIXやMac等のOSに対して命令を実行する為のプログラムのこと。
特にBashスクリプトとは主にバックエンドにおける様々な処理の「自動化」を目的として使用される。
近年ではDevOps、AWS、GCP、オンプレでの実サーバー管理などにおいて一連の作業を自動化することに使われています。
Pythonなど他のスクリプト言語もあるのですがLinuxはBashが標準でインストールされているためLinuxやMacであれば初期設定なしで使えるという大きなメリットがあります。

Bashと同等に求められるプログラム言語とは

現場の経験的にBashと同等に求められるプログラム言語を紹介します。

①バッチファイル（Batch File）

MS-DOS、OS/2、Windowsでのコマンドプロンプト（シェル）に行わせたい命令列をテキストファイルに記述したもの。
これらはマイクロソフトが開発したシェルであり、大手SIerの中には認証用のサーバーとしてマイクロソフト製品を利用していることが多く（自分の経験的には認証としてはほぼこれ）
インフラや運用管理系の案件では開発用の作業端末もWindowsのPCであることが多いです。
WindowsOS環境があると各作業を自動化＆効率化できてめちゃめちゃ人材として重宝されます。

②teratermマクロ

フロントエンド系のエンジニアの方は無縁だと思われるのが意外とこのteratermマクロ。
OS側の環境変更やCLIにて運用管理業務を自動化します。こちらはLinux、WindowsやMacOSにも対応しており（その為の環境変更は必要だが）管理系業務を自動化したい場合は最高に使えます。
ちなみにことらのプログラムは管理業務を自動化したい効率性の高い企業は積極的に採用しています。
オンプレ側では優秀なサーバーエンジニアとネットワークエンジニアが積極採用しているイメージです。

③VBA

定型業務の自動化、省力化。
例えば、毎日更新されるデータを出社してからいちいち手入力し、手順を入力して計算させていた業務を、夜の間に自動でソフトウェアを起動し、データを読み込ませ、朝までに処理させておける。
またOfficeアプリケーションではマクロ記録/再生という操作手順の記録/再生機能を使って、プログラムに関する知識が少ないユーザーでも、ある程度の定型業務の自動化を行なえる。マクロはVBAコードの自動生成により実現されている。
ちなみにWebブラウザとも連携できるしOS系の運用管理業務も自動化できます。ExelVBAができるとエンジニア以外の業務の定例作業も自動化できるので現場で重宝されます。

最後に

フロントエンド系エンジニアの方にとっては触る機会が少ないと思われるのでキャリア形成において費用対効果が低いと思われますが、
DevOps系、バックエンド系やインフラエンジニア(サーバー、ネットワーク)においては近年自動化は注目されているので、上記キャリアを形成する可能性がある方はこの手の言語を習得する為に時間を費やす費用対効果はめちゃめちゃ高いです。
是非気になる方は習得してみましょう。
※近日中に実際の使われ方やコードを公開しますね！！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T01:35:37+09:00

年収1000万円を要求するインフラエンジニアが知っておくべき最低限のLinuxディストリビューション

はじめに

なんか某所に面接に来た年収1000万円以上希望のインフラエンジニア候補に、Linuxのどのディストロ使ってるか聞いたら「ディストロってなんですか？」と聞き返して来たという話をきいたのでオラびっくらこいてQiitaに記事書き始めちまったぞ

使ったことはなくてもいいから名前と特徴くらいは知っていて欲しいディストリビューションを列挙する。ディストロの系列ごとに書いたので、列挙順は重要度順ではない。が、2019年現在絶対に知ってないとマズイalpineだけは先頭に置いた

busybox系

Alpine Linux

公式: https://www.alpinelinux.org/
Wikipedia: https://ja.wikipedia.org/wiki/Alpine_Linux
パッケージマネージャー: apk
最小構成だと約5.6MBという圧倒的小ささで、dockerコンテナのベースとして存在感を日々増大させている。busyboxというのは昔FDD1枚(1.2MB)で起動する1 floppy linux系でよく使われていた技術で、lsやcd等多数のコマンドを一つのbusyboxというバイナリのシンボリックリンクにしておき、実行時に$0で「どのコマンドで起動されたか」を調べて挙動を変えることでサイズを小さくしている。単一バイナリなのに沢山仕事があるから「busybox(忙しい箱)」なのである。

伝統的巨大企業で働いてる人は「ウチはまだベンダーの動作保証のあるRHELだから」という事はあるだろうが、使ったことはなくても2019年現在でAlpineの名前と用途を知らないインフラエンジニアはヤバイ。

RedHat系

パッケージマネージャー: yum (.rpm)

Red Hat Enterprise Linux (RHEL)

公式: https://www.redhat.com/ja/technologies/linux-platforms/enterprise-linux
Wikipedia: https://ja.wikipedia.org/wiki/Red_Hat_Enterprise_Linux
サーバーで定番だったディストリビューション。実績もあったし、高いロイヤリティとるだけあってちゃんとhpやIBMなどのサーバーベンダーにかけあって検証させ、サーバーの動作保証OSにRHELの名前が挙がっていた。商用では「フリーソフト(≒OSS)なんて信用できない、バグがあったときにどうするんだ1！」という時代で、ベンダーにCentOS使ってるなんて言ったら「それはうちの動作保証外なんで返答できかねます2」と言われるのがオチだった。今でも変わってないかも。でも今はベンダーからサーバー買うよりクラウドの方が多いと思うので、そんな事を気にすることもなくなった。

Amazon Linux

公式: https://aws.amazon.com/jp/mp/linux/
言わずとしれたAmazonが自社のクラウドサービスAWSのサーバーインスタンスであるEC2用に提供しているディストリビューション。Amazon Linux2でやっとRHEL7ベースになった。初代Amazon LinuxはRHEL6がベース。AmazonオリジナルはDBのAuroraなども含め、AWS最適化パッチがあたっているものの本家からは数年遅れるため本家のバグ対応や機能追加が取り入れられるのが遅いというパターンが多い気がする。最近は本番環境もdockerな事が多いのでホストなんてセキュアであればそれで必要十分とは思う。

CentOS

公式: https://www.centos.org
Wikipedia: https://ja.wikipedia.org/wiki/CentOS

「RHELとのバイナリ互換を目標」として、RHELのSRPMから構築するコミュニティベースのプロジェクトだった。他にWhitebox LinuxとScientific Linux、CERN Linuxなどがあったが消えたので言及しない。当初はSRPMから消し忘れたRHELのロゴなどに対してチクチクとRH本体から「うちの商標を侵害するな」といじめられていたが、今ではRHがCentOSのサポーターになっている。中身はRHELと同等と考えておいて差し支えない。たまに失敗してRHELで動くバイナリが同じバージョンのCentOSで動かないことがあるらしいが、遭遇したことない。

Fedora

公式: https://getfedora.org/
Wikipedia: https://ja.wikipedia.org/wiki/Fedora

黎明期に一斉を風靡したRed Hat Linuxの正当な後継はこれ。RedHat社はRHELだけを商品として取り扱い、Fedoraコミュニティをサポートして成果物をRHELに取り込むという関係にある。新しいものを積極的に取り入れるため、新しく入ったもののRHEL本体に取り込まれないまま消えてしまう機能などもある。

Ubuntu系

パッケージマネージャー: apt, dpkg (.deb) snappy(.snap)

Ubuntu Linux

公式: https://www.ubuntulinux.jp/
Wikipedia: https://ja.wikipedia.org/wiki/Ubuntu
Linuxのデスクトップ利用として泣く子も黙るトップシェアを誇るのがUbuntu。ウェブ上に最も情報が多いのがこれなので、「Linuxは初めて」という初心者から「Linuxは〇〇に使いたいだけなんだ、ディストロ選びやインストール作業は趣味じゃないんだ！」という上級者まで安心して使えるディストリビューション。Thawte(1999年にVerisignに買収された)で一旗あげたマーク・シャトルワースによって創設された。彼はカノニカルという企業も設立し業務としてUbuntuを支援している。

snappyはカノニカルがメンテナンスしているパッケージマネージャーで、ディストロ依存しないのが特徴。.soのライブラリをパッケージに含むのでサイズが大きくなってしまう。カノニカル的には「aptに代わってsnappyを使ってみんなで幸せになろう」という事なんだろうが、批判も多く他のディストリビューションに受け入れられているかというと微妙な状況である。

後述するDebianの派生ディストロなのでDebian系とするのが正しいが、Ubuntuからさらに派生したディストロがかなりあるのでこでは系統をわけて「Ubuntu系」とした。「UbuntuはDebianの成果にただ乗りして利益をだしている(Debianは儲かってないのに！）」「Debianのコミッターを(自発的ではあれ)引き抜いて行く」として批判する向きもある。そういう話がどうでもいい人はなにも聞かなかったことにして使っていればよい。

Ubuntu派生

Ubuntuは人気なので派生がいっぱいある。好みのものを使ってもいいし、使わなくてもいい3。MintやLubuntu等の人気が高い。Ubuntuと設定ツールが微妙に違ったりして、ネットで情報をググっても自分の環境に適用できない事があったりするので注意されたし。

Wikipedia: Ubuntu派生ディストリビューション
https://ja.wikipedia.org/wiki/Category:Ubuntu%E6%B4%BE%E7%94%9F%E3%83%87%E3%82%A3%E3%82%B9%E3%83%88%E3%83%AA%E3%83%93%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3

Debian系

パッケージマネージャー: apt, dpkg (.deb)

Debian GNU/Linux

公式: https://www.debian.org/
Wikipedia: https://ja.wikipedia.org/wiki/Debian
DebianはGNU精神を尊重していて、うっかり「Debian Linux」などと言うと「Debian GNU/Linuxです！」といちいち訂正されるので気をつけてほしい。「debian」と書く分には怒られない（たぶん）。Slack、Red Hatと並ぶLinux黎明期BIG3的な存在。現在のBIG3はRed Hat, Debian, Archだろうか。

Kali Linux

公式: https://www.kali.org/
Wikipedia: https://ja.wikipedia.org/wiki/Kali_Linux
ペネトレーションテスト用のソフトウェアがあらかじめセットアップされた状態のディストロで、ベースはdebian。用途から察するに名前の由来は血と殺戮の女神カーリーだろう。これを使って外部のサービスに侵入を試みてはいけない。するなよ！するなよ！絶対にするなよ！4。

Raspbian5

公式: https://www.raspberrypi.org/downloads/raspbian/
wikipedia https://ja.wikipedia.org/wiki/Raspbian

大人気Raspberry Pi向けディストリビューション。用途が用途なので大規模サーバーを触ってる人には縁がないかもしれないが、ラズパイを知らなかったらアンテナが低すぎるし、ラズパイ上ですぐ動くLinuxがあるよ、ということは知っていて損はない。一応Xもあるけどラズパイ2までは重すぎて使い物にならないと思う。ラズパイ4はメモリ4GB積めるみたいだしいけるのかなあ。買ってみようかな。通常はPC上で組んだプログラムをラズパイに転送して動かすものだと思う。

Tails

公式: https://tails.boum.org/
Wikipedia: https://ja.wikipedia.org/wiki/Tails_(%E3%82%AA%E3%83%9A%E3%83%AC%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)

初回起動時からTorで接続する、匿名性を高めたディストリビューション。Torでも当局6に本気出されたら追跡可能という噂もあるが、普通にネットに繋いでる人よりはTor使いの方が追跡に時間と手間がかかるのは間違いない。捕まらないとは言っていない。

MX Linux

公式: https://mxlinux.org/
2019-10現在distrowatchで一位を誇っている人気ディストリビューション。これを書いてる俺も今知ったので詳細は知らん7。

Arch Linux系

Arch

公式: https://www.archlinux.org/
Wikipedia: https://ja.wikipedia.org/wiki/Arch_Linux
シンプル・ミニマムをモットーにしている。リリースバージョンというものはな、ローリングリリースといって随時パッケージが更新されている。CD/ISOインストールように定期的にスナップショットはあるが、特にそれに対してバージョン番号を振ったりはしない。

Manjaro

最近MXに抜かれたが、distrowatchで長い間検索結果一位の座に君臨していた。Arch系の時点で人を選ぶのだが、その人達によっぽど好まれているものと思われる。

その他

Gentoo8

全部ソースで提供されて自分でビルドするというポリシーのディストリビューション。コンパイルオプションを細かく設定することで自分のPCや用途に最適化する事ができる。例えば、サーバーとして使うコンピュータであればグラフィカル系のものをコンパイルしないようにすることでかなりバイナリサイズが小さくなる。

FreeBSD

公式: https://www.freebsd.org/ja/
Wikipedia: https://ja.wikipedia.org/wiki/FreeBSD
そもそもLinuxでない。なんかここの紹介を間違うとものすごく怒られそうな気がするのと、歴史の話をするとながーーーい事になるので、興味ある人だけ調べて見てほしい。なぜか日本では人気の高かった、Linuxの「雑多でも動く事が重要」に対して「設計の綺麗さ、コードの正しさ」を求めてると聞くけど自分でカーネル追ったわけでもないので詳しくは知らない。俺が触った時はJVMが動かなくて自社の業務のサーバーとして使えなかったし、情報量もLinuxほど多くないから触るのをやめてしまった。「FreeBSD」という名称と、「Linuxではない」事くらいは知っておいて欲しい

おまけ

ここから下はまあ知らなくても支障はないけど、話の種くらいにはなるかもしれない

Oracle Linux

RHELクローン、Oracle DB向け最適化、だったけど今更好き好んでOracleに金払うやつもいないと思う。使っているのは過去のしがらみでOracle Databaseを使わざるを得えないところか、Oracle CloudにおけるAmazon Linux的な位置づけとして使われている程度ではなかろうか。使ってる人の話は聞いたことない。

Miracle Linux

元はRH系がベースだっけ？途中でTurboベースに代わったが、Turboが死に体だったのでRH系に戻った。Oracleでの豊富なLinux対応案件を武器に日本オラクルからスピンアウトしてOracle、PostgreSQL,Samba等特定用途に特化して、その用途にチューンナップ済み9のディストリビューションの商売を始めた。世界進出成功する前に米Oracle本体にOracle Linuxを出され、日本オラクルからは出資は引き上げられるし散々だった。その後turbo他と組んでAsianux Serverなどと迷走した上になんとかまだ生きてる。生きてるだけでエライ！

Turbo Linux

米Pacific HiTech(以下PHT)によるディストリビューション。PHTはインターネット黎明期からフリーウェアをまとめてCDに焼いて売ったりしていた。当時は常時接続は一般的ではなかったし速度も遅かったので、CDに入る600MB以上のソフトが1000円で買えるとなれば利用者にはとてもお得だったのである。turboは米では即死したが、日本ではGUIインストーラーで日本語が使える状態で発売され、導入の優しいLinuxということで人気があった。Redhatの人気はその後。

Slackware

歴史の長いディストリビューションの一つ。当時はCD bootとかも一般的でなく、まずWindows95のDOS窓でloadlinして、Linux側に切り替えたあと、自分のPC用にkernelの機能をmake configしてmake install、LILO(≒GRUBのレガシー版)にkernelを登録して再起動するのが普通だった。カーネルをコンパイルする理由だが、当時はブート時に読み込み可能な領域が640KBであり(zimageの場合)、kernelを512KB以下にする必要があった。インストール時に使うカーネルには起動に最低限必要なものだけしか入っていないので、自分の持っているビデオカードやSCSIカードに合わせて機能を盛り込んで、そのkernelで再起動してやっと使えたのである。全部てんこ盛りにするととても512KBには収まらない。'97年くらいにはkernelがmoduleの動的読み込みに対応しだして、しばらくはexperimentalな機能として推奨されていなかったが、安定してくるとデバイスドライバみたいなものはmoduleで動的に読み込むようになり、いちいちkernelを再コンパイルする必要がなくなった、気がする。古すぎて記憶が曖昧。

これにJE(Japanese Environment)というキット、というか一連のソフトウェアを入れて日本語が使えるようになった。なんかソースが飛んでPJEとかいう名前に変わった気がしないでもない。

Plamo Linux

日本発のディストロで、SlackにJEが載った状態でインストールできるようなもの、という位置づけだった。が、源流はそのままにどんどん使いやすく進化しているようで2019年現在活動中である。すごい！

Kondara MNU/Linux

日本発、オサレなペンギンがマスコットのRH系ディストロ。KondaraはLinuxコミュニティへのコミットも活発だったし、デジタルファクトリーという会社が発売して商流にのったのもあって「ディストロ渡り歩きたくないしこれからはKondaraメインでやっていこう」と思った瞬間に運営ともめて解散した。コミュニティベースの商売の難しさを教えてくれた。後継はmomonga。PS/2 Linuxに採用され、kondara linuxって表示されてたけどkondaraのメンバーは知らなかったらしく、ライセンス的にはどうなってるの？って思ったけどどっちでも俺には関係ない。

Vine Linux

日本発、葡萄がトレードマーク。RHベースに日本語環境特化して一部に人気を誇った。Linux、というかソフトウェア業界全体が「各国版をそれぞれローカライズするより、初めから国際化(Internationalization, I18N)だよね」という流れになって、どのディストロでも多言語が当たり前のように使えるようになってからの動きは知らない

SUSE

なんかあったね。Suse Linux Enterprise Server略してSLESだっけ？なんかヨーローッパの方で元気だった気もする。日常的に使ってる人は見たことない。

SCO UNIX

Linux界隈はみんな大嫌いなSCO

あとがき

これらを知っている程度で年収1000万円になれるわけではないし、なんなら俺はインフラエンジニアではない。
昔ならデキるインフラエンジニアはこういうイメージだった。

  • ネットワーク設計
  • サーバーを調達するベンダーの選定、CPUの種類や世代による特性を理解したサーバーの選定
  • iSCSI/NFSなどのプロトコルに対する知識や設定
  • HA構成でのSAN共有ディスクやFibreChannelなどの知識・設定
  • NICのチーミング(Bonding)などの知識・設定
  • L2/L3におけるCisco/IOSやその代替機の設定（スパニングツリー、vtag等)
  • L7におけるF5 BIGIPやその代替機の設定

ラックへのキッティングは職人さんにやってもらった方が綺麗にできるぞ！（その後ネットワーク設計の変化が起きた時に綺麗でいられるかどうかはインフラ担当者が頑張る）

今どきだとこんな感じか？

  • AWS/GCPでAutoScalingGroup(ASG)やKubernetes(K8s)の設定
  • リージョンまたぎでの冗長構成の設計
  • CDNのベンダーごとの特性の把握
  • infrastructureの設定をK8sやdockerに落として、git管理しどこでもすぐ再現できるようにする

クラウドならサーバーラック周りでの知識は不要、オンプレならまだ上のBIGIPのようなスキルがいると思う。まあなんにしても各方面の技術がそれぞれ進化して、昔なら一人で全部みるような人がいたけど、今は大変だよね。今「フルスタックエンジニア」とか言っちゃってる人は大体ぺらい。

んで、ここに挙げたような事は個人的なスキルで、上に立つ人はこの知識を部下に教えながら大きなネットワークを管理し、インフラの冗長構成だけでなく人材のトラックリスク/退職リスクを考慮して育成していかなければならない。

商用UNIXは、、やるなら昔話タグかな

  1. 「誰に責任転嫁すればいいんだ！」の意 ↩

  2. 仕事でこれをやり始めちゃうとキリがない、キリの境界線が「動作保証対象かどうか」なので仕方ない ↩

  3. 世界樹の迷宮、懐かしいね ↩

  4. https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%81%E3%83%A7%E3%82%A6%E5%80%B6%E6%A5%BD%E9%83%A8#%E4%B8%BB%E3%81%AA%E3%82%AE%E3%83%A3%E3%82%B0 ↩

  5. @FSMSさんありがとうございます ↩

  6. どこの？ ↩

  7. じゃあ「知っておくべき」に挙げるなよ、と言いたいところだが一位なら仕方ないじゃないか ↩

  8. @tuvistavieさんありがとうございます。 ↩

  9. 当時はkernelパラメータで共有メモリのサイズを変更したり、HDDのsyncタイミングなどを設定するのが当たり前だった。メモリ数GBが普通になってからは各ディストロもデフォルトでそれなりの共有メモリサイズを設定するようになった。 ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-10-02T00:07:30+09:00

Ubuntu 18.04 sudo apt-get updateコマンド が Failed to fetchエラーになった時の解決法

目的

  • コマンドsudo apt-get updateを実行した際にFailed to fetchエラーが出たときの解決法を知る。

実行環境

  • OS
    Ubuntu18.04(WSL)

エラー内容

shun@DESKTOP-AO64T0U:~$ sudo apt-get update
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:5 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [523 kB]
Get:6 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [746 kB]
Get:7 http://security.ubuntu.com/ubuntu bionic-security/main Translation-en [175 kB]
Get:8 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [8192 B]
Get:9 http://security.ubuntu.com/ubuntu bionic-security/restricted Translation-en [3180 B]
Get:10 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [608 kB]
Get:11 http://archive.ubuntu.com/ubuntu bionic-updates/main Translation-en [268 kB]
Ign:12 http://security.ubuntu.com/ubuntu bionic-security/universe Translation-en
Get:13 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [4904 B]
Get:14 http://security.ubuntu.com/ubuntu bionic-security/multiverse Translation-en [2396 B]
Get:12 http://security.ubuntu.com/ubuntu bionic-security/universe Translation-en [203 kB]
Err:12 http://security.ubuntu.com/ubuntu bionic-security/universe Translation-en
File has unexpected size (202408 != 202600). Mirror sync in progress? [IP: 91.189.88.173 80]
Hashes of expected file:
- Filesize:202600 [weak]
- SHA256:d5644557978bdf7fdd90693bebb82c40ab026134bce6a0878f892fe222d37f75
- SHA1:c40f41430f0e0571a11f5a1f2308a0ee0c339899 [weak]
- MD5Sum:8c8b9c42ecf2348f66b13f1608f38234 [weak]
Release file created at: Tue, 01 Oct 2019 13:01:35 +0000
Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [15.1 kB] 
Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/restricted Translation-en [4844 B]
Get:17 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [1007 kB]
Get:18 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [309 kB]
Get:19 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 Packages [7556 B]
Get:20 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse Translation-en [3868 B]
Get:21 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [4020 B]
Fetched 3942 kB in 43s (92.2 kB/s)
Reading package lists... Done
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/bionic-security/universe/i18n/Translation-en.xz  File has unexpected size (202408 != 202600). Mirror sync in progress? [IP: 91.189.88.173 80]
Hashes of expected file:
- Filesize:202600 [weak]
- SHA256:d5644557978bdf7fdd90693bebb82c40ab026134bce6a0878f892fe222d37f75
- SHA1:c40f41430f0e0571a11f5a1f2308a0ee0c339899 [weak]
- MD5Sum:8c8b9c42ecf2348f66b13f1608f38234 [weak]
Release file created at: Tue, 01 Oct 2019 13:01:35 +0000
E: Some index files failed to download. They have been ignored, or old ones used instead.

解決法

  • 先人の知恵によりコマンドsudo apt-get updateを実行した際のパッケージリストが悪さをしていることが分かった。
  • パッケージリストを先に削除してあげることで正常にコマンドsudo apt-get updateが実行できた。
  1. 下記コマンドを実行してパッケージリストを削除する。
  $ sudo rm -rf /var/lib/apt/lists/*
  1. 今一度、コマンドsudo apt-get updateを実行する。
  $ sudo apt-get update
  1. 下記の様に出力されればコマンドsudo apt-get updateが正常に実行できている。
  shun@DESKTOP-AO64T0U:~$ sudo apt-get update
  Get:1 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
  Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
  Get:3 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [523 kB]
  Get:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
  Get:5 http://security.ubuntu.com/ubuntu bionic-security/main Translation-en [175 kB]
  Get:6 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [8192 B] 
  Get:7 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
  Get:8 http://security.ubuntu.com/ubuntu bionic-security/restricted Translation-en [3180 B]
  Get:9 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [608 kB]
  Get:10 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1019 kB]
  Get:11 http://security.ubuntu.com/ubuntu bionic-security/universe Translation-en [203 kB]
  Get:12 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [4904 B]
  Get:13 http://security.ubuntu.com/ubuntu bionic-security/multiverse Translation-en [2396 B]
  Get:14 http://archive.ubuntu.com/ubuntu bionic/main Translation-en [516 kB]
  Get:15 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages [9184 B]
  Get:16 http://archive.ubuntu.com/ubuntu bionic/restricted Translation-en [3584 B]
  Get:17 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [8570 kB]
  Get:18 http://archive.ubuntu.com/ubuntu bionic/universe Translation-en [4941 kB]
  Get:19 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [151 kB]
  Get:20 http://archive.ubuntu.com/ubuntu bionic/multiverse Translation-en [108 kB]
  Get:21 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [746 kB]
  Get:22 http://archive.ubuntu.com/ubuntu bionic-updates/main Translation-en [268 kB]
  Get:23 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [15.1 kB]
  Get:24 http://archive.ubuntu.com/ubuntu bionic-updates/restricted Translation-en [4844 B]
  Get:25 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [1006 kB]
  Get:26 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [309 kB]
  Get:27 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 Packages [7552 B]
  Get:28 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse Translation-en [3868 B]
  Get:29 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages [2512 B]
  Get:30 http://archive.ubuntu.com/ubuntu bionic-backports/main Translation-en [1644 B]
  Get:31 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [4020 B]
  Get:32 http://archive.ubuntu.com/ubuntu bionic-backports/universe Translation-en [1856 B]
  Fetched 19.7 MB in 2min 5s (158 kB/s)
  Reading package lists... Done
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧