読者です 読者をやめる 読者になる 読者になる

デスクトップパソコン内部のお掃除をするときの注意点

はじめに

デスクトップパソコンの電源ユニット(↓のようなやつ)
f:id:Y-Andoh:20170324124436p:plain:w300
を、お掃除した時の話です。

結論

パソコン内部のお掃除をするときは、感電に留意しよう。
お掃除大いに結構。だけど、何も考えずに適当にやるのはやめよう。
お掃除方法をちゃんと調べて、道具をちゃんと用意して、適切なプロセスでやりましょう。
(未来の自分に対する戒め記事です。未来の自分よ、同じ過ちを繰り返すないでくださいね。。。)

経緯というか、ただの駄文。

半年くらい前から、パソコンから異音がするようになったんですね。
それも、普通じゃないくらいの大きな音がするんですね。
で、ケースを開けて、音の出処を調べてみると、どうも電源ユニットから音がしている。
そういうことが分かったわけです。

で、この時点で、私としてはかなり高をくくっているわけです。
「なんだ、所詮電源ユニットか。壊れても交換すればいいや。そんな高い部品じゃないわけだし。」
「グラボ、CPU、HDD、このあたりが正常であれば、どうでもいいですよ。」
こんな感じです。

で、この状況を半年くらい放置していたんですけど、あるとき、
「電源ユニットが壊れるのは構わないけど、死ぬときに他の部品を道連れにすることはあるのか?」
ふと、こう思ったわけです。

さすがに、道連れ死はないとは思うんですが、ちょっと不安です。
電源ユニットは、グラボ、マザボ、HDDにケーブルで直結して、給電してるわけです。
最悪部品全滅か?そんなことあるのか?
こんなふうに、ちょっと不安に思うわけです。

というわけで、電源ユニットを壊す覚悟で、電源ユニット内部のホコリ取りを行いました。

※注
電源ユニットをバラして、内部のお掃除をする場合、保証が効かなくなるかもなので、注意です。
わたしの場合は、電源ユニットのネジ穴に封印シールが貼ってあって、
それを剥がしちゃうと、もう保証が効かなくなったんじゃないかと思います。
ただ、わたしの場合は、もう保証が切れてたので、「バラして掃除する。」という選択を取ったわけです。

で、そのときは何も考えずに、
パソコンから電源ユニットを外して(当然、電源は切っておきますよ。)、
電源ユニットのケースを開けて、内部のホコリを細口の掃除機で吸いだして、
残った頑固なホコリは、ティッシュを使って手で取り除いて、
終わったら、すべて元に戻す。

こんな操作をしたわけです。
で、それが功を奏して、異音は見事になくなったんですよ。

それ自体は良かったんですが、
あとから、web上で、パソコン掃除にまつわる記事を見ているとですね、

「電源内部のコンデンサに触ると感電するからヤバイですよ。」

みたいなことが、書かれているわけです。
これはさすがにヒヤッとしました。

「あれ?これ、私、最悪死んでた?」
「何も知らずに、無自覚に特攻してたってこと?」
「静電気防止のために、一応ゴム手袋着けてたのが、良かったの?」
「たまたま、電源ユニット外してからある程度の時間が経ってたから、自然に放電されてて助かったの?」
「そもそも、掃除と称して、電源ユニット内部を手で触ってたのもマズイんじゃないの?」

なんて思うわけですよ。
しかも、すべて、あとから気付いたことだってのが、またツライ。

その、なんと言いますか、、、
みなさんは、私のような間抜けなことはやらないように、気をつけてください。。。
それから、未来の自分は同じ失敗を繰り返さないでくださいね。ほんとに。。。

AwesomeEventsをherokuで動かしてみた。

はじめに

  • 「herokuって何ですか?」
    無料で試用できる、Webアプリの実行環境。とでもいえばいいんでしょうか。
    よくわからん。ってひとは、自分で調べたほうが早いです。

  • 「AwesomeEventsって何ですか?」
    以下の書籍内で、作成することになる、Railsのサンプルアプリです。
    gihyo.jp
    完成品のソースコードは↓からダウンロードできます。
    github.com

私が、heroku上で動かしたAwesomeEventsへのリンク先

AwesomeEvents

 

動かしてみた所感。

  • お試しで作成するには、ちょうどいい規模のアプリ。
    お勉強するには、ちょうどいいボリュームだった。
    bootstrapを使っているから、CSSを自分で書かなくていいから楽ちん。
    コードのサンプルもあるし、かなり満足できました。

  • Vagrant上で動かした時はCarrierWaveの機能がうまく動かない。
    Vagrant上で動かした時はCarrierWaveの機能がうまく動かなかったが、heroku上では動くようになった。
    単純にVMの設定がまずいような気がする。
    VMに対して、FTP経由のデータ転送ができないだけ?
    どうせVMの環境設定の問題だから別にいいや。と無視して、あまりちゃんと検証してない。

  • あえて自分で拡張するなら
    OAuth を使って、"google+FacebookAmazon"
    このへんのアカウントで、ログインできるようにするのが楽しそう。
    gemがあればすぐできそう。

  • その他
    特に大きなトラブルもなく、割とさくさく終わってしまったので、全然書くことがない。
    まあ、自分用備忘録だから別にいいけど。。。

heroku上にbaukisをデプロイして動かしてみました。

はじめに

  • 「herokuって何ですか?」
    無料で試用できる、Webアプリの実行環境。とでもいえばいいんでしょうか。
    よくわからん。ってひとは、自分で調べたほうが早いです。

  • 「baukisって何ですか?」
    以下の書籍内で、作成することになる、Railsのサンプルアプリです。
    book.impress.co.jp
    完成品のソースコードや、Vagrantfileは↓からダウンロードできます。
    www.oiax.jp

heroku上で、Railsアプリを動かすときは。

ひとまず、以下のリンク先のページを読めば、なんとかなるでしょう。
Getting Started with Rails 4.x on Heroku | Heroku Dev Center

なんとかならない人は、今回のこの記事を読めば少しは役に立つかもしれません。

 

私が、heroku上で動かしたbaukisへのリンク先

Admin top page - Baukis
Staff top page - Baukis

もちろん、ログインパスワードは変えてありますし、教えませんよ。

 

私が、heroku上でbaukisを動かしたときの、メモ

ここからが本題。(内容は、自分用の備忘録です。特に難しいことはありません。)

自分のbaukisがMySQLで動いている場合は、 PostgreSQLで動くように変更します。

heroku上でwebアプリを動かす時は、PostgreSQLがデフォルト。
MySQLを使いたいときは、クレジットカード情報を登録しなければならないとかなんとか。

herokuについて、いろいろ調べるのは面倒なので、
アプリ(baukis)をPostgreSQLで、動くようにしちゃったほうが手っ取り早いでしょう。

どうせ、データベースに投入してあるデータは、テスト用のダミーデータでしょう。
全部消して、一からデータベースを作るだけなら、簡単でしょう。
(データベースのデータを移植しない場合ってこと。)

やりかたを箇条書きしておきます。
・Gemfile内の mysql と書いてあるところを pg に変更する。
・PostgreSQL用に config/database.yml を書き換える。
・bin/bundle を実行して、gem(pg)をインストールする
・"bin/rake db:migrate:reset", "bin/rake db:reset" とかで、DBのデータを一から構築する。(シードデータ生成スクリプトは既に持ってるはず。)
もし、PostgreSQLが入ってない場合は、yumとかapt-getでインストールしましょう。

とりあえず、私が使った、config/database.yml を貼り付けておきます。

$ cd /vagrant
$ egrep "pg|mysql" Gemfile 
gem 'pg'
$ 
$ cat config/database.yml 
default: &default
  adapter: postgresql
  encoding: unicode
  pool: 5
development:
  <<: *default
  database: baukis_development
test:
  <<: *default
  database: baukis_test
production:
  <<: *default
  database: baukis_production

一番手っ取り早いのは、
「baukis/db/seeds/developmentをコピーして、新たにproductionを作る。」これだけでしょう。
もちろん、スクリプトを変更して、ログインパスワードは変えておきます。

手元で動かないものは、heroku上でも動かないですね。当たり前ですが。

念の為、
・ ~/.baukis_secret_key_base ファイルがあること(本に従って自分が作成しているはず)
・ 環境変数 $SECRET_KEY_BASE に、そのファイルの内容がセットされてること
は、チェックしておきましょう。

$ ls -l ~/.baukis_secret_key_base 
-rw-rw-r-- 1 vagrant vagrant 128 Dec 10 14:33 /home/vagrant/.baukis_secret_key_base
$ echo $SECRET_KEY_BASE
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (ランダムの文字列がこんな感じで表示されます。)

— ここまでが、大前提 —

これも、やり方は、適当にwebサイトを漁れば、いくらでも情報は出てきます。

heroku CLIは↓を見れば、やり方が書いてあります。
MacOS XでVagrantにCentOS入れ、Railsアプリ制作、Heroku公開 vol.07 - Qiita
(wget使って、インストールシェルを実行している。)

gitは、最初からLinuxレポジトリに登録されてあるはずなので、
"apt-get install" とか、yum とかで、インストールするだけですね。

baukisの書籍で紹介されている、Vagrantfile。
これを使って、VMのLinuxを構築していれば、確実にapt-getとかyumが使えるはずです。
あくまで、VMのLinuxにgitをインストールする。って話なので、
俺はMACだから、とか、俺はWindowsだから、とかって話にはなりません。

前出ですが、Vagrantfileは、
『実践Ruby on Rails 4』読者サポートページ - Ruby on Rails with OIAX
ここにダウンロード先のリンクが書いてあります。

config/database.yml の記述は、1に書いてあります。
1のプロセスをスキップした人は、ここで、忘れずに書き換えて置きましょう。

さて、この項は、少し悩んだのですが、
・手元のvagrant上のVMで動いているbaukis
・heroku上で動かす予定のbaukis

全く同じアプリですが、当然、実行環境が違います。
そして、この2つは並走させたいです。
ならば、2つのbaukisに対して、それぞれ別々のURLを用意する必要がある。(はずです。)

じゃあ、どうしようか?と考えたのですが、
「config/environments/production.rb を、ベタ書きで変更する。」
これでいくことにしました。(手抜き。)

以下、config/environments/production.rb の変更内容。

$ git diff
diff --git a/config/environments/production.rb b/config/environments/production.rb
index 3873377..7e71834 100644
--- a/config/environments/production.rb
+++ b/config/environments/production.rb
@@ -82,11 +82,11 @@ Rails.application.configure do
   config.active_record.dump_schema_after_migration = false
 
   config.baukis = {
-    staff: { host: 'baukis.example.com', path: '' },
-    admin: { host: 'baukis.example.com', path: 'admin' },
-    customer: { host: 'example.com', path: 'mypage' }
+    staff: { host: 'baukis-dup.herokuapp.com', path: '' },
+    admin: { host: 'baukis-dup.herokuapp.com', path: 'admin' },
+    customer: { host: 'baukis-dup.herokuapp.com', path: 'mypage' }
   }
 end
"baukis-dup.herokuapp.com" ってのは、私がheroku上で動かす予定のbaukis。
これのドメイン名です。

本当は、"baukis.herokuapp.com"という名前を使いたかったんですが、
既に、誰かが使っている名前だったので、使えませんでした。
(heroku上でのアプリケーション名は、ユニークである必要があるようです。)

例えば、
baukis.herokuapp.com を作る場合は、以下のコマンドを実行するわけですが、
$ heroku create baukis
Creating ⬢ baukis... !
 ▸    Name is already taken
"Name is already taken" と怒られてしまいます。

当然、私が使っている "baukis-dup.herokuapp.com" も使えません。
各自、適当にユニークネームを考えてください。

大した操作では無いので、操作logだけ貼り付けておきます。
以下参照です。

$ cd /vagrant
$ git init
Initialized empty Git repository in /vagrant/.git/
$ git add .
$ git commit -m "Init"
[master (root-commit) 8004838] Init
 685 files changed, 85998 insertions(+)
 create mode 100644 .rspec
 create mode 100644 .ruby-version
    :
    : (長いので省略)
    :
$ 
$ git log
commit 8004838cafad7de20acf2337323d392b824d5956
Author: Admin for baukisdup <you@example.com>
Date:   Thu Feb 9 16:21:21 2017 +0900

    Init

また、操作logだけ貼っておきます。

$ cd /vagrant
$ heroku create baukis-dup
Creating ⬢ baukis-dup... done
https://baukis-dup.herokuapp.com/ | https://git.heroku.com/baukis-dup.git
$ git config --list | grep heroku
remote.heroku.url=https://git.heroku.com/baukis-dup.git
remote.heroku.fetch=+refs/heads/*:refs/remotes/heroku/*
また、一応の注意として、名前を指定してcreateしたほうが良さそうです。

既に作成済みの "~/.baukis_secret_key_base"
この値を、heroku上のbaukisでも使うことにします。

以下、操作log

$ cd /vagrant
$ heroku config:set SECRET_KEY_BASE=`cat ~/.baukis_secret_key_base`
    : (実行結果は省略)
ファイルを作成してなければ、以下の操作で作れます。
$ ruby -e 'require "securerandom";  print SecureRandom.hex(64)' > ~/.baukis_secret_key_base

例によって、また操作logだけ貼っておきます。以下参照です。

$ cd /vagrant
$ git push heroku master
Counting objects: 618, done.
Compressing objects: 100% (581/581), done.
Writing objects: 100% (618/618), 1.70 MiB | 228.00 KiB/s, done.
Total 618 (delta 200), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote: 
    :
    : (実行結果は、かなり長いので省略)
    :
To https://git.heroku.com/baukis-dup.git
 * [new branch]      master -> master

vagrant上のVMでrakeコマンドを使うのと、全く同じ感覚で、データベースを作ることができます。

例によって、また操作logだけ貼っておきます。以下参照です。

$ cd /vagrant
$ heroku run rake db:migrate
Running rake db:migrate on ⬢ baukis-dup... up, run.8340 (Free)
Migrating to CreateStaffMembers (20161213034748)
    :
    : (実行結果は、かなり長いので省略)
    :  
$ 
$ heroku run rake db:seed
Running rake db:seed on ⬢ baukis-dup... up, run.4824 (Free)
Creating staff_members....
Creating administrators....
Creating administrators....
Creating staff_events....
Creating customers....
$ 
$ heroku ps:scale web=1
Scaling dynos... done, now running web at 1:Free
$ 
$ heroku ps
=== web (Free): bin/rails server -p $PORT -e $RAILS_ENV (1)
web.1: up 2017/02/09 16:27:34 +0900 (~ 1m ago)

ちなみに、"rake db:setup" を使うと、何故か怒られてしまいました。(以下参照。)
$ heroku run rake db:setup RAILS_ENV=production
Running rake db:setup RAILS_ENV=production on    gentle-atoll-64698... up, run.5341 (Free)
FATAL:  permission denied for database "postgres"
DETAIL:  User does not have CONNECT privilege.
  :
  : (結果は長いので省略)
  :
あまりちゃんと調べてないのですが、
heroku では、複合系のコマンド(db:setupは、db:create,db:schema:load,db:seed の複合)は、
何故か失敗するとかなんとか。って話を、散見しました。

私も「手元のvagrantではrakeコマンドで、問題なくDB操作できるのに、heroku ではうまくいかない。」
ってケースを、結構体験させられました。

"rake db:migrate:reset", "rake db:reset" このあたりも、うまくいかなかった記憶があります。。。
しかし、"rails_12factor"のgemを入れて、ログを強化しておけば、どうにか対処できると思います。


ちなみに、私が、heroku上のbaukisに全くログインできない状況に遭遇したときに、以下のようなlogがコンソールに出ていました。
 app[web.1]: PG::UndefinedTable: ERROR:  relation "staff_members" does not exist
 app[web.1]:   Rendered errors/internal_server_error.html.erb within layouts/staff (0.3ms)
 app[web.1]:   Rendered staff/shared/_header.html.erb (0.5ms)
 app[web.1]:   Rendered shared/_footer.html.erb (0.1ms)
 app[web.1]: Completed 500 Internal Server Error in 8ms (Views: 2.3ms | ActiveRecord: 3.0ms)
この問題は、DBが全く作成されていないことが原因で、
つまり、結局、"heroku rake db:xxxx" がうまくいってなかったって話だったのですが、
結構、トラブルシューティングに時間を割くことになりました。

つまんないトラブルですが、対処するのが意外と面倒だったりします。
"rails_12factor"のgemは役に立ちますです。

自分用備忘録 : bashのビルトインコマンドの確認方法、及び、bashオプションの確認方法

確認方法のまとめ

bashの全てのビルトインコマンドを表示する場合は、 "enable -a"
各ビルトインの詳細を知りたいときは、 "man builtins"
bashオプションの有効/無効を確認したいときは、 "set -o"

実行例

$ enable -a
enable .
enable :
enable [
enable alias
enable bg
enable bind
enable break
enable builtin
enable caller
enable cd      ### cd はビルトイン! ###
enable command
enable compgen
enable complete
enable compopt
enable continue
enable declare
enable dirs
enable disown
enable echo
enable enable
enable eval
enable exec
enable exit
enable export
enable false
enable fc
enable fg
enable getopts
enable hash
enable help
enable history
enable jobs
enable kill
enable let
enable local
enable logout
enable mapfile
enable popd
enable printf
enable pushd
enable pwd
enable read
enable readarray
enable readonly
enable return
enable set
enable shift
enable shopt
enable source
enable suspend
enable test
enable times
enable trap
enable true
enable type
enable typeset
enable ulimit
enable umask
enable unalias
enable unset
enable wait
$ man builtins 
BASH_BUILTINS(1)                                          General Commands Manual                                         BASH_BUILTINS(1)

名前
       bash,  :,  ., [, alias, bg, bind, break, builtin, caller, cd, command, compgen, complete, compopt, continue, declare, dirs, disown,
       echo, enable, eval, exec, exit, export, false, fc, fg, getopts, hash, help, history, jobs, kill, let, local, logout, mapfile, popd,
       printf,  pushd,  pwd,  read,  readonly, return, set, shift, shopt, source, suspend, test, times, trap, true, type, typeset, ulimit,
       umask, unalias, unset, wait - bash の組み込みコマンド (bash(1) を参照)

bash の組み込みコマンド
       特に断らない限り、このセクションで説明されている組み込みコマンドのうち - で始まるオプションを受け付けるものは、オプションの終わりを
       表す -- も受け付けます。 組み込みコマンド :, true, false, test はオプションを持たず、-- を特別扱いしません。 組み込みコマンド exit,
       logout, break, continue, let, shift は、- で始まる引き数として受け取るのに、 --  を必要としません。  そのほかの組み込みコマンドは、
       受け取ると明記されているオプション以外を引き数として受け取り、  - で始まる引き数を不正なオプションをとて解釈します。 この解釈を防ぐ
       には -- が必要です。
  :
  : 長いので省略
  :
$ set -o
allexport       off
braceexpand     on
emacs           on
errexit         off
errtrace        off
functrace       off
hashall         on
histexpand      on
history         on
ignoreeof       off
interactive-comments    on
keyword         off
monitor         on
noclobber       off
noexec          off
noglob          off
nolog           off
notify          off
nounset         off
onecmd          off
physical        off
pipefail        off
posix           off
privileged      off
verbose         off
vi              off
xtrace          off

LPIC 公式例題集のまとめ

はじめに

以前の記事でLPIC 303 の公式例題集を少し加工して、自分用に使いやすくしました。(以下の記事を参照のこと)
LPIC 303 試験対策 - I took an arrow in the knee.
LPIC 303 試験対策 その2 - I took an arrow in the knee.

「じゃあ、303以外の例題はまとめないの?」
という、声が(私の中で)強かったので、すべての例題を使いやすくまとめました。
というのが記事の内容です。

最終まとめ

以下のウェブサイトに、LPI-Japanの公式例題をすべて整理してまとめました。
sites.google.com

受験者のお役に立てれば幸いです。

Ubuntu 16.04 LTS に Virtualbox と Vagrant をインストールして、CentOSを動かしてみた

はじめに

Ubuntu 16.04 LTS に VirtualboxVagrant をインストールしました。
その上で、CentOSを動かしてみました。
この記事は、その操作ログというか自分用の備忘録というか、です。

操作ログ

まずは Ubuntu のバージョンをチェック

$ lsb_release -a | grep Description
Description:    Ubuntu 16.04.1 LTS


次に Ubuntuパッケージの中に、virtualboxvagrantがあるかチェック

$ apt-cache search virtualbox | grep ^virt
virtualbox - x86 virtualization solution - base binaries ★こいつ!
virtualbox-dbg - x86 virtualization solution - debugging symbols
virtualbox-dkms - x86 virtualization solution - kernel module sources for dkms
virtualbox-ext-pack - extra capabilities for VirtualBox, downloader.
virtualbox-guest-additions-iso - guest additions iso image for VirtualBox
virtualbox-guest-dkms - x86 virtualization solution - guest addition module source for dkms
virtualbox-guest-source - x86 virtualization solution - guest addition module source
virtualbox-guest-utils - x86 virtualization solution - non-X11 guest utilities
virtualbox-guest-x11 - x86 virtualization solution - X11 guest utilities
virtualbox-qt - x86 virtualization solution - Qt based user interface
virtualbox-source - x86 virtualization solution - kernel module source
$ 
$ apt-cache search vagrant | grep ^vag
vagrant - Tool for building and distributing virtualized development environments  ★こいつ!
vagrant-cachier - share a common package cache among similar VM instances
vagrant-lxc - Linux Containers provider for Vagrant


となると、話は簡単で、apt-get install するだけ。

$ sudo apt-get install virtualbox
  : インストールログは長いので省略します。
$ 
$ sudo apt-get install vagrant
  : インストールログは長いので省略します。


そして、起動するOSのイメージを取得します。(今回はCentOS)
取得先は以下参照
NREL Vagrant Base Boxes - Browse Files at SourceForge.net

操作方法は以下参照

$ vagrant box add base http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.5-x86_64-v20140504.box
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'base' (v0) for provider: 
    box: Downloading: http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.5-x86_64-v20140504.box
==> box: Successfully added box 'base' (v0) for 'virtualbox'!


ちゃんと取得できたことをチェックして

$ vagrant box list
base (virtualbox, 0)


初期化と起動をする、と。

$ vagrant init base
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
$ 
$ vagrant up
==> default: Importing base box 'base'...
==> default: Matching MAC address for NAT networking...
  :
  : 起動ログは長いから省略します。 
  :


起動が成功してそうなので、仮想マシン上のCent OSにログインしてみると、、、

$ vagrant ssh
Welcome to your Vagrant-built virtual machine.
[vagrant@localhost ~]$ echo $HOME
/home/vagrant
[vagrant@localhost ~]$ cat /etc/redhat-release
CentOS release 6.5 (Final)
[vagrant@localhost ~]$ logout
Connection to 127.0.0.1 closed.

ちゃんとログインできましたね。
OSもCentOSであることが確認できたので、めでたしめでたし。

余談

インターネットで検索してみると、同じようなことをやっている人がいて、変なトラブルを抱えていた人が散見されました。
でも、ありがたいことに、私には何も起きませんでしたね。
私が試したときの Ubuntuのバージョンが新しかったからかな?

同じことやろうとして困っている人は、Ubuntuのバージョン上げてみたらどうでしょうか?(無責任)

/bin/, /usr/bin/, /usr/local/bin/, の違いのまとめ

はじめに。

/bin/, /usr/bin/, /usr/local/bin/
たまにうっかりしていると、このディレクトリ達の用途の違いがわからなくなることありませんか?
そんな物忘れさんな人(主に自分)用に、その違いを簡潔にまとめておきましょう。

ちなみに、こういうのはFHSといいます。詳しくは以下参照。
Filesystem Hierarchy Standard - Wikipedia

それから、この内容は、自分用に大雑把にまとめただけなので、正確さに欠けるかもしれません。
詳しく知りたい人は↓を見たほうがいいです。
エンタープライズ: - 第14回:FHSによるディレクトリの規格化

この記事は、楽して大意を掴みたい人向けということで。
その点は含みおき下さい。


まとめてみました。

まとめたい対象のディレクトリは、以下の6つ

$ file /bin /sbin /usr/bin/ /usr/sbin/ /usr/local/bin/ /usr/local/sbin/ 
/bin:             directory
/sbin:            directory
/usr/bin/:        directory
/usr/sbin/:       directory
/usr/local/bin/:  directory
/usr/local/sbin/: directory

注: どのディレクトリも、実行ファイル(lsとかcpとかね)を格納しておくためのディレクトリです。

その分類の要点は以下の3つ。

  • /bin or /sbin

    • 一般ユーザ向けのコマンドが置いてあるのが、 /bin
    • システム管理者向けのコマンドが置いてあるのが、 /sbin

    これは、"/usr/bin or /usr/sbin" でも、"/usr/local/bin/ or /usr/local/sbin/" でも同じ。

  • OS起動やシステムメンテナンスに必須なもの or not

    • OS起動やシステムメンテナンスに必須なもの: /bin, /sbin
    • そうでないもの: /usr/bin/, /usr/sbin/, /usr/local/bin/, /usr/local/sbin/
  • /usr/ or /usr/local/

    • 付加的なアプリケーションをインストールしたいときは /usr/local/bin/, /usr/local/sbin/ に配置する。
    • それ以外は、/usr/bin/, /usr/sbin/"

    注:
    自分で書いておいて言うのも何ですが、ここの記述はかなりいい加減ですね。
    (たぶん私も正確に違いを把握出来ていない。)

    誤解を恐れずに、自分の感覚で言うと、

    • 自分で、apt-get とか yum でインストールしたものは、/usr/bin, /usr/sbin に置いてあるような気がする。
      (すべてがそうではない。)
    • /usr/local/bin/, /usr/local/sbin/ は /opt と同じような使い方をする気がする。
    • ソースコードだけが公開されていて、インストーラすら無いような、小さなユーティリティアプリケーションを格納したいときは、/usr/local/bin/, /usr/local/sbin/ のどっちかに配置すればよさそう。

以上、すごく大雑把なまとめでした。 (間違っていたらごめんなさい。)