Macのルートディレクトリに、シンボリックリンクを作成する方法

私が持っているMacは、個人の開発用にも使っています。

その際 Linuxディレクトリ構成と同様に、/home 配下に任意のディレクトリを作っているのですが、Mac OS だと、/home配下にディレクトリを作ろうとすると、以下のようなエラーが発生します。

% sudo mkdir /home/hoge
Password:
mkdir: /home/hoge: Operation not supported

昔の Mac OS は、上記コマンドで問題なかったのですが、いつの頃からか MacOSSIP(=System Integrity Protection) が加わって以降、上述のようなエラーが発生するようになったようです。

で、 SIP を無効にすることも方法ではあるのですが、せっかくの SIP の機能を無効にすることの副作用がよくわからない(っというか、調べるのもしんどい)ので、他に方法がないかと探していました。

しかも、私がしたいのは /homeディレクトリを作ってデータをそこに配置したいのではなく、シンボリックリンクで他の場所を指せるだけでも良かったりします。

その観点で、何か方法ないかと調べてみたら、以下の方法でルートディレクトリにシンボリックリンクを作成できることがわかりましたので、方法を以下に記録しておきます。

  1. /etc/synthetic.confを作成します。
% sudo touch /etc/synthetic.conf
  1. /etc/synthetic.conf の中身を以下のように記述し、保存しますます。
home    /Users/[UserName]/work/home
  • /Users/[UserName]/は、自分の環境のホームディレクトリを指してください。
  • home と パスの間は、 TAB で区切ってください。スペースだとうまくいきません。

  • 端末を再起動します。

  • ルートディレクトリの状況を確認すると、意図した通りにシンボリックリンクが貼られているのがわかります。

%  ls -l /
・・・省略
lrwxr-xr-x   1 root  wheel    49  3 13 16:18 home@ -> /Users/[UserName]/work/home
・・・省略

Debian(Ubuntu)にPHP8をインストールする

動作環境

  • OS : Debian11

前提条件

  • 既にApache2がインストールされていること

さぁ、インストールしよう

aptを最新にします。

$ sudo apt update

Hit:1 http://ftp.jaist.ac.jp/debian bullseye InRelease
Get:2 http://ftp.jaist.ac.jp/debian bullseye-updates InRelease [39.4 kB]
Get:3 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB]
Get:4 http://security.debian.org/debian-security bullseye-security/main Sources [102 kB]
Get:5 http://security.debian.org/debian-security bullseye-security/main amd64 Packages [120 kB]
Get:6 http://security.debian.org/debian-security bullseye-security/main Translation-en [77.0 kB]
Fetched 382 kB in 1s (731 kB/s)                                  
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

PHP8をインストールするまでの事前準備

$ sudo apt install -y lsb-release ca-certificates apt-transport-https software-properties-common gnupg2
$ echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/sury-php.list
$ wget -qO - https://packages.sury.org/php/apt.gpg | sudo apt-key add -
  • ここに関しての操作は、このサイトを参考にしました。
  • ホントにうまくいくの?と内心ドキドキしました。

phpをインストールしていきます。

$ sudo apt install -y php8.1
$ sudo apt install -y php8.1-mbstring
$ sudo apt install -y php8.1-gd
$ sudo apt install -y php8.1-mcrypt
$ sudo apt install -y php8.1-pgsql
  • php8.1をインストールした後は、OSをリブートした方が良さそうです。

apache2を再起動しておきます。

$ sudo systemctl restart apache2

最後に

私の環境では、どうやら上述手順でうまくいったようです。 よかった^^

[user] sso is not in the sudoers file. This incident will be reported. と出てしまった

動作環境

なんでこのメッセージが出るの?原因は?

sudo コマンドを利用したときに、ユーザが sudoグループ に属していないからだそうです。 うん。単純。 なので、利用しているユーザを sudoグループに追加してみます。

方法

利用しているユーザの所属グループを調べます。

$ groups [ユーザ名]
[ユーザ名] : [グループ名]...
  • きっと、sudoグループには属していないことが確認できるはず

rootユーザに変更します。

$ su -l root
  • sudoコマンドが利用できないので、ひとまずrootユーザになりましょう。
  • rootユーザのパスワードは、OSインストールした人か、管理者に聞いてくださいね。

利用しているユーザをsudoグループに追加します

# /usr/sbin/usermod -aG sudo [ユーザ名]

動作確認

動作確認する前に、一度利用ユーザからログアウトしてからログインしてください。 そうしないと、「あれ、sudoグループに追加したのに、同じエラーが出るやん」となるので。

$ sudo apt list apache2
[sudo] password for [ユーザ名]: 
Listing... Done
apache2/stable-security 2.4.52-1~deb11u2 amd64
N: There is 1 additional version. Please use the '-a' switch to see it
  • apache2 のパッケージが apt にあるかどうかを、sudoコマンドを用いて確認してみました。
  • 無事にapache2がリストに出て来れば設定完了です。

nodenv で 新しいバージョンの Node.js をインストールします

nodenv で 新しいバージョンの Node.js をインストールします。

随分前に、自分のPCの nodenv をインストールしていました。その時の Node.js の最新バージョンは15系でした。

その時は、そのバージョンで問題はなかったのですが、一年ぐらい経つと流石に Node.js もバージョンアップしているらしく、現在では17系までアップデートしています。

これから作ろうとするプログラム(そんな大したものでは無いけど)では、最新でのNode.jsを使っていこうと思うこともあり、バージョンアップをしてみました。

node-build プラグインを利用してアップデートするようです。

さて、どうやってアップデートするのかと思って、調べてみると公式のサイトにその手順が記載ありました。

内容を読んでみると、「node-buid」プラグインを最新にしてねと書いてあったので、その手順に従って進めていきます。

f:id:itachi900:20220212174643p:plain
node-buidプラグイン

node-build をクローン

私の端末では、~/.nodenv/plugins/ に何もなかったので(=っというか、pluginディレクトリ自体もなかった)ので、ディレクトリの作成から始めます。

$ cd ~/.nodenv
$ mkdir plugins
$ cd plugins
$ git clone https://github.com/nodenv/node-build.git

node-build 導入してみて

node-build を導入することで、私の端末では node.js が利用できるバージョンが、15.9.0 -> 17.5.0まで利用できるようになりました。

よかった ^^

最近Macがの動作が重い・・・そうだ再インストール

動作環境

最近Macがの動作が重い・・・

最近、いつも利用しているMacを起動した時、動作が重たくなってきたなぁと感じてます。 特に、Google Chromeの起動がとてもとても遅いのです。

Google Chromeを起動すると、 - 起動自体が遅い - 起動しても「新しいタブ」が応答なしになる。 - URLにアドレスを入力しようとしても、入力が追いつかない という問題がありました。

そこで、MacOS全体を再インストールしてリカバリしようと思ったのですが、どうもそこまでの気力がなかったので、ひとまずGoogle Chromeの再インストールだけで、問題が解決しないか?と思ったので、実際にやってみました。

Google Chromeのアンインストール

アンインストール方法について、調べてみると以下のサイトが参考になりました。 Google Chrommeをアンインストールする

ひとまずこの手順通りにアンインストールしてみます。(アンインストール方法のスクショを載せておきます。)

f:id:itachi900:20220212163730p:plain
Google Chromeアンインストール

Google Chromeをインストール

インストール方法について、この手順を参考にしました。 Google Chrome をダウンロードしてインストールする

こちらも、手順通りにインストールしてみます。(インストール方法のスクショを載せておきます。) figure-image-fotolife" title="Google Chromeインストール方法">f:id:itachi900:20220212164301p:plain

Google Chromeインストール方法

なお、インストールの際には「使用統計や障害レポートを・・・」のオプションは外しておきました。自動送信することで動作が遅くならないなかなぁ・・・と思ったので。

再インストールした結果は。

OSの再起動後に、Google Chromeを起動してみました。 結果は、随分起動が早くなったかなぁと思います。まぁ、使っているうちにどんどんと遅くなってくる気もしますが。

ひとまず、今のところ結果オーライということでしばらく使ってみます。

同じ悩みを抱えている皆さん、一度再インストールしてみてはいかがでしょう ^^

ApacheでGitBucketをリバースプロキシしてみる

動作環境

ApacheでGitBucketをリバースプロキシしてみる

  • Apacheでのリバースプロキシ設定はすでに実施済みである前提で進めます。

    • Apacheでのリバースプロキシの設定は、過去記事をみてくださいね。
  • リバースプロキシ用の設定ファイルを用意します。

<Proxy *>
  Order deny,allow
  Allow from all
</Proxy>

AllowEncodedSlashes NoDecode
ProxyPreserveHost On
ProxyPass /gitbucket http://[domain]:60001/gitbucket
ProxyPassReverse /gitbucket http://[domain]:60001/gitbucket
  • ひとまずローカルで作成するので、ログインユーザで作成できる任意の場所に作成してください。
  • ファイル名は、my-proxy.conf としておきましょう。

  • 作成したリバースプロキシファイルのコピー

$ sudo cp -p my-proxy.conf /etc/apache2/sites-available/.
$ sudo chown root:root /etc/apache2/sites-available/my-proxy.conf
  • ログインユーザで my-proxy.conf を作成していたので、コピーは sudo を使ってください。
  • コピー後は、ファイルの所有権を root に変更しています。

  • リバースプロキシを有効にします

$ sudo a2ensite my-proxy
  • /etc/apache2/sites-available 配下に存在する conf ファイルの接頭辞を指定します。
  • この結果として、sites-enabled ディレクトリにしシンボリックリンクが作成されているので確認しておいてください。
$ ls -l /etc/apache2/sites-enabled/
合計 8
drwxr-xr-x 2 root root 4096  2月  4 16:04 ./
drwxr-xr-x 8 root root 4096  1月 31 15:04 ../
lrwxrwxrwx 1 root root   35  1月 31 15:04 000-default.conf -> ../sites-available/000-default.conf
lrwxrwxrwx 1 root root   32  2月  4 16:04 my-proxy.conf -> ../sites-available/my-proxy.conf
  1. GitBucketへのアクセスパスを変更しておきます。
[Unit]
Description=The GitBucket Server

[Service]
User=develop
ExecStart=/usr/bin/java -jar [gitbucket.warを置いてあるフルパス]/gitbucket.war \
                        --gitbucket.home=[フルパスで任意の場所]] \
                        --port=60001 \
                        --prefix=/gitbucket \
                        --max_file_size=10485760 \
                        

[Install]
WantedBy=multi-user.target
  • 変更対象のファイルは、 /lib/systemd/system/gitbucket.service です。

  • 設定ファイルを再読み込みします。

$ sudo systemctl daemon-reload
  1. ApacheとGitBucketを再起動しておきましょう。
$ sudo systemctl restart apache2
$ sudo systemctl restart gitbucket
  • サーバが自由にできるなら、サーバ再起動でも良いですよ。

  • 動作確認

  • 以下のアドレスにアクセスして、GitBucketの初期画面が出てきたら成功。
http://[domain]/gitbucket/
  • 初期画面はこんなイメージ

f:id:itachi900:20220204163902p:plain
GitBucket初期画面

Apacheのリバースプロキシの設定

動作環境

Apacheのリバースプロキシの設定に至ったわけ

  • つい先日インストールした GitBucket を使おうと思ったのですが、このポート指定によるアクセスは面倒だなぁと。
    • ポート番号指定だと、こんな感じのURLに。http://[ドメイン]:60001
    • いちいちポート番号なんて覚えてられないし・・・
  • なので、Apacheにリバースプロキシを設定して、ポート番号の指定から解放されようと思います。

Apacheにリバースプロキシを設定してみる。

  1. リバースプロキシを有効にする。
$ sudo a2enmod proxy_http
[sudo] develop のパスワード: 
Considering dependency proxy for proxy_http:
Enabling module proxy.
Enabling module proxy_http.
To activate the new configuration, you need to run:
  systemctl restart apache2
  • なんか、CentOS系とかとやり方が違うんだなぁと。
  • コマンド一つで有効化できるのであれば、それはそれで簡単かなと。

  • Apacheの再起動

$ sudo systemctl restart apache2
  1. 実行結果
$ ls -l /etc/apache2/mods-enabled
合計 8
drwxr-xr-x 2 root root 4096  2月  3 19:50 ./
drwxr-xr-x 8 root root 4096  1月 31 15:04 ../
lrwxrwxrwx 1 root root   36  1月 31 15:04 access_compat.load -> ../mods-available/access_compat.load
lrwxrwxrwx 1 root root   28  1月 31 15:04 alias.conf -> ../mods-available/alias.conf
lrwxrwxrwx 1 root root   28  1月 31 15:04 alias.load -> ../mods-available/alias.load
lrwxrwxrwx 1 root root   33  1月 31 15:04 auth_basic.load -> ../mods-available/auth_basic.load
lrwxrwxrwx 1 root root   33  1月 31 15:04 authn_core.load -> ../mods-available/authn_core.load
lrwxrwxrwx 1 root root   33  1月 31 15:04 authn_file.load -> ../mods-available/authn_file.load
lrwxrwxrwx 1 root root   33  1月 31 15:04 authz_core.load -> ../mods-available/authz_core.load
lrwxrwxrwx 1 root root   33  1月 31 15:04 authz_host.load -> ../mods-available/authz_host.load
lrwxrwxrwx 1 root root   33  1月 31 15:04 authz_user.load -> ../mods-available/authz_user.load
lrwxrwxrwx 1 root root   32  1月 31 15:04 autoindex.conf -> ../mods-available/autoindex.conf
lrwxrwxrwx 1 root root   32  1月 31 15:04 autoindex.load -> ../mods-available/autoindex.load
lrwxrwxrwx 1 root root   30  1月 31 15:04 deflate.conf -> ../mods-available/deflate.conf
lrwxrwxrwx 1 root root   30  1月 31 15:04 deflate.load -> ../mods-available/deflate.load
lrwxrwxrwx 1 root root   26  1月 31 15:04 dir.conf -> ../mods-available/dir.conf
lrwxrwxrwx 1 root root   26  1月 31 15:04 dir.load -> ../mods-available/dir.load
lrwxrwxrwx 1 root root   26  1月 31 15:04 env.load -> ../mods-available/env.load
lrwxrwxrwx 1 root root   29  1月 31 15:04 filter.load -> ../mods-available/filter.load
lrwxrwxrwx 1 root root   27  1月 31 15:04 mime.conf -> ../mods-available/mime.conf
lrwxrwxrwx 1 root root   27  1月 31 15:04 mime.load -> ../mods-available/mime.load
lrwxrwxrwx 1 root root   32  1月 31 15:04 mpm_event.conf -> ../mods-available/mpm_event.conf
lrwxrwxrwx 1 root root   32  1月 31 15:04 mpm_event.load -> ../mods-available/mpm_event.load
lrwxrwxrwx 1 root root   34  1月 31 15:04 negotiation.conf -> ../mods-available/negotiation.conf
lrwxrwxrwx 1 root root   34  1月 31 15:04 negotiation.load -> ../mods-available/negotiation.load
lrwxrwxrwx 1 root root   28  2月  3 19:50 proxy.conf -> ../mods-available/proxy.conf
lrwxrwxrwx 1 root root   28  2月  3 19:50 proxy.load -> ../mods-available/proxy.load
lrwxrwxrwx 1 root root   33  2月  3 19:50 proxy_http.load -> ../mods-available/proxy_http.load
lrwxrwxrwx 1 root root   33  1月 31 15:04 reqtimeout.conf -> ../mods-available/reqtimeout.conf
lrwxrwxrwx 1 root root   33  1月 31 15:04 reqtimeout.load -> ../mods-available/reqtimeout.load
lrwxrwxrwx 1 root root   31  1月 31 15:04 setenvif.conf -> ../mods-available/setenvif.conf
lrwxrwxrwx 1 root root   31  1月 31 15:04 setenvif.load -> ../mods-available/setenvif.load
lrwxrwxrwx 1 root root   29  1月 31 15:04 status.conf -> ../mods-available/status.conf
lrwxrwxrwx 1 root root   29  1月 31 15:04 status.load -> ../mods-available/status.load
  • 実行したことで、新たに proxy.conf / proxy.load / proxy_http.loadシンボリックリンクが生成されていました。
  • これで有効になるのであれば、意外に簡単でした。
  • さぁ、これで GitBucket のリバースプロキシ対応に進めるぞーっと。