20200722のLinuxに関する記事は9件です。

Ubuntu 18 -> 20 upgrade時に消えたGnome上のアイコンを復元させる

2b911aea.png

Ubuntu 18から20へのupgrade時に自分が遭遇した不具合。
gnome-shell-extension-desktop-iconsをインストールすれば解決する。

sudo apt install gnome-shell-extension-desktop-icons

Alt+F2 rでGnomeはリロードが可能。

references

18.04 - Ubuntu 20.04 desktop files and icons missing - Ask Ubuntu

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

crondが死んでたので zabbix で死活を監視する話

いつの間にか crond が死んでいました..。

Linux OOM Killerに殺されたのか、なにか他に原因があったのかは定かではありません。
そのせいで、let's encrypt の自動更新がされず、証明書が期限切れを起こしました。

これはいかん。

zabbixでcrondが死んだら警告を出さねば!

....アイテムがねぇ...orz

作ればいいんだろ、作ればよ〜。

とりあえず zabbix server で新規テンプレート Crond を作ります。
アイテムに crond を keyが proc.num[crond] で。

これでおおよそ大丈夫のはずですが、まれに
proc.num[crond] が取れていないzabbix-agentが...

そういった場合は、agent側から死活をサーバーに通知します。
crondの死活は status で確認できます。
/etc/rc.d/init.d/crond status

runningという文字があれば正常。なければ異常。
runningをカウントすることで確認できます。

/etc/rc.d/init.d/crond status|grep -e running |wc -l

その結果を zabbix-agent から出力します。
zabbix_agentd.conf
UserParameter=crond,/etc/rc.d/init.d/crond status|grep -e running |wc -l

Zabbixサーバー側でcrondをアイテムに追加し、トリガーを設定します。

監視中の数十あるzabbix-agentにコツコツ追加すればいいんだろ?クソがぁ!

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

サーバーサイドエンジニアがLinuC(Linux技術者検定)を受けるべき4つの理由

今回はサーバーエンジニアこそLinuC取得をおすすめする記事です。
新卒入社してから3年間で7個くらい技術系の資格を取得しましたが、
サーバーエンジニアとして最も取得してよかったと思った資格はLinuCでした。

サーバーサイドエンジニアとして成長するにあたり、誰もが対象のプログラミング言語の勉強や他の言語に裾野を広げることに注力しがちですが、一つの言語である程度の知識を得たら今すぐLinuCの勉強をおすすめします。

その理由を紹介していきましょう。

LinuCとは

2018年3月より提供が開始された日本独自のLinux技術者認定資格である。2000年7月に設立されたLinuxをはじめとするオープンテクノロジーのIT技術者の技術力の認定活動を行なっているLPI-Japanによって、企画・開発・運営されている。(wikipediaより)
https://ja.wikipedia.org/wiki/LinuC

簡単に言うとLinuxの技術指標を図るための資格です。2017年あたりまではLPICという名前でした(内容は一緒)。

Linuxってインフラエンジニアが学ぶ知識ではないの?と思う方、多いと思います。

今現在でエンジニアとして働いている方は、LAMP環境構築を一からしたことがありますでしょうか。
LAMP環境とは(Linux-Apache-MySQL-PHP)の略でWEBサービスを作成する上で基本となる構成になります。
近年は環境構築も簡単になっており、DockerやVagrantなどを使用してLAMP環境構築を簡潔化したような機能が提供されています。

会社で元々DockerやVagrantが整備されており、一から仮想サーバを立ち上げてapache設定をしてHello worldまで表示したことがあると言う人は意外と少ない印象です。

理由としては

ターミナル操作はなんだか難しそうだから

が多いと思います。

前段が長くなりましたが、サーバーサイドエンジニアがLinuCを取得した方がいい4つの理由を紹介していきます。

LinuCを取得するべき4つの理由

①障害発生時の調査能力があがるから

サービスを運営する上で、何かしら障害が発生することはあると思います。

画面にスタックトレースが出てくれれば原因特定も楽ですが、原因がなかなか特定できない障害もあるでしょう、その際の役に立つのがLinuCの知識です。

LinuCの知識があれば、

apache設定を見ることでサーバの特定がしやすい
ログ出力設定を発見しやすい&直近更新されたログファイルを特定しやすくエラーが出力されているか特定しやすい
エラーログの中から原因と思われるログの抽出するスピードが速くなる
ロードアベレージなどサーバ負荷やネットワークなどの原因切り分けができる
などLinuCの知識を元にした調査速度の向上が見込めると思います。

インフラ面に抵抗があるとターミナルに入ってcdとlsとcatコマンドしか打てないなんてことになってしまいます。

②ローカル環境構築をすることができるから

レガシーなコンテンツを運用していると、どうしてもローカルでの環境が構築されておらず、直接サーバーをvimで編集するなど、している方も多いのではないでしょうか。

vimmerの方からすれば何不自由ない環境かと思いますが、普通にエディタを使用している人からすれば大きな開発の妨げになると思います。

それを解決する手段が環境構築です。ローカル環境構築をすることができれば、仮想サーバに同等の環境を作成して、ローカルとマウントした上でエディタ編集をすることが可能です。

そのローカル構築したイメージをチーム内で共有することで他メンバーの開発効率もアップし、そんなことができればあなたはきっと評価されると思います。

③エンジニアとして評価されるから

自分は人事の採用などに携わることがたまにあるのですが、サーバサイドエンジニア歴が5~8年くらいの人でさえその経験がないという人をちらほら見ます。

履歴書にDockerやVagrantでの構築経験があり、と書いてあっても実際に聞いてみると既存で作られていた環境に対して「docker run」しただけとかよく聞きます。

こうなってしまうと技術的な幅が狭いのではないか、調査能力や環境構築周りのことが一切できないのではないかと言う採用側への不安要素になってしまいます。

何よりLinuCのlevel2程度を取得していれば、最低限のエンジニアとしての知識を保証する証明にもなると思います。

インフラサイドの知識があることは一つの武器になり、自信になります。

④クラウドサービスを扱うにあたり理解の助けになるから

近年AWSなどのクラウドサービスが広がる中で、インフラ知識はクラウドサービスと関連付けしてより深く理解する助けになります。

フルマネージドサービスが導入されることで、今までインフラに任せていた領域がサーバーサイドが実施するようになる会社も少なくないのではないでしょうか。

例えば、EC2を立ち上げるときにぽちぽちボタンを押してインスタンスを起動する際、裏で何が起きているか理解しているのと理解していないのとでは、今後AWSのアーキテクトをする上で大きく差が出ることは確かだと思います。

LinuCはひとまずLevel1を取得して、余裕があればLevel2を取得すると良い

上記のメリットをあげさせていただきました。次は実際にLinuCの出題範囲を記載します。

LinuC Level 1

LinuC Level 1の出題範囲

1.01.1Linuxのインストール、起動、接続、切断と停止
1.01.2仮想マシン・コンテナの概念と利用
1.01.3ブートプロセスとsystemd
1.01.4プロセスの生成、監視、終了
1.01.5デスクトップ環境の利用
1.02.1ファイルの所有者とパーミッション
1.02.2基本的なファイル管理の実行
1.02.3ハードリンクとシンボリックリンク
1.02.4ファイルの配置と検索
1.03.1コマンドラインの操作
1.03.2フィルタを使ったテキストストリームの処理
1.03.3ストリーム、パイプ、リダイレクトの使用
1.03.4正規表現を使用したテキストファイルの検索
1.03.5エディタを使った基本的なファイル編集の実行
1.04.1apt コマンドによるパッケージ管理
1.04.2Debianパッケージ管理
1.04.3yumコマンドによるパッケージ管理
1.04.4RPMパッケージ管理
1.05.1ハードウェアの基礎知識と設定
1.05.2ハードディスクのレイアウトとパーティション
1.05.3ファイルシステムの作成と管理、マウント
1.06.1シェル環境のカスタマイズ
1.06.2シェルスクリプト
1.07.1インターネットプロトコルの基礎
1.07.2基本的なネットワーク構成
1.07.3基本的なネットワークの問題解決
1.07.4クライアント側のDNS設定
1.08.1アカウント管理
1.08.2ジョブスケジューリング
1.08.3ローカライゼーションと国際化
1.09.1システム時刻の管理
1.09.2システムのログ
1.09.3メール配送エージェント(MTA)の基本
1.10.1セキュリティ管理業務の実施
1.10.2ホストのセキュリティ設定
1.10.3暗号化によるデータの保護
1.10.4クラウドセキュリティの基礎
1.11.1オープンソースの概念とライセンス
1.11.2オープンソースのコミュニティとエコシステム

いかがでしょうか。LinuC level1だけでもものすごく多いですよね。

この知識を他のサーバーサイドエンジニアより身に付けられたら、ものすごく差をつけられる気がしませんか?

個人的にはLinuC level2まで取得することがおすすめです。

以下に出題範囲を記載しておきます。

https://linuc.org/linuc2/range/

おすすめの勉強方法

最後におすすめの勉強方法を紹介します。

LinuC試験は4択問題のため、技術国家資格関連と比較して簡単です。

ただし、4択といっても内容をしっかり理解していないと解けない問題ばかりな印象なので、勉強する際は問題丸暗記にならないように注意しましょう。

おすすめの本は以下になります。

51ZgyX76KaL._SY346_.jpg

http://urx3.nu/6Ovn

赤本や黒本がありますがLevel1はスピードマスターで十分です。
Level2からは深く理解するために黒本を併用してもいいかもしれません。

オススメはアプリ

また、上記の本もおすすめなのですが何より最も効果的な勉強法はアプリです。

「リナ男とリナ子のLinuc問題集」がおすすめです。

有料ですがこれだけやればたぶん合格できるので参考書を買うよりコスパもいいと思います。

リナ男とリナ子のLinuC-1問題集_-_Google_Play_のアプリ.png

http://urx3.nu/44Wx

資格関係なくインフラ初心者にオススメの本

インフラ周りが苦手な方、少しでもインフラが身近に感じられるようなおすすめの本を紹介します。

51SDwVGgwHL.jpg

http://urx3.nu/Lavx

シス管系女子という漫画形式の本です。

一見可愛すぎて手が出にくいかもしれませんが中身は非常にわかりやすく、2020年時点で3巻まで発売されています。
2巻からはLinuC Level2相当の技術も取り上げられており、初心者だけでなく中級者向けだと思います。

以上、サーバーサイドエンジニアはLinuCを取るべきという記事でした。

是非ご参考にしてください。

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

Linuxについて

前提

Linuxについて学んだことを書いていきます。

Linuxのブートプロセスとsystemd

1、電源投入
2、ファームウェア(BIOS/UEFI)動作
- ブートローダを呼び出す
3、ブートローダ
- kernelとRAMディスク
4、カーネルを起動
- メモリ初期化やハードウェア認識
5、systemd(init)でサービス起動
6、ログインプロンプト表示

initとsystemd

・サービスを起動する仕組み
- init: SysVinit(System File Init)従来
- systemd: 現在のLinuxで採用

systemdのデーモン

・デーモン(バックグランドで常時起動しているプロセス)
- systemd(メイン)
- systemd-jouranl(ジャーナル管理プロセス、ログ管理)
- systemd-logind(ログイン処理)
- systemd-udevd(デバイス動的検知)

systemdとUnit

・Unit(処理単位)
- systemctlコマンドで制御
- タイプ
  ・service(各種サービス起動)httpd, sshdなど
  ・device(デバイス)
  ・mount(ファイルシステム)/etc/fstab
  ・swap(スワップ領域の有効化。ディスクをメモリに)
  ・target(複数Unitをグループ化)

systemctlコマンド

・start、stop、restart
・status
・is-active
・enable、disable(自動起動)
・list-units
・list-unit-files(unit-fileの一覧・ステータスなど)
・list-dependancies

サービスの有効化・無効化

【systemdの起動順序】
・default.targetが最初に呼ばれる。以下と関連づける
・ランベル(init)とターゲット(systemd)
 0、poweroff.target
 1、rescure.target(レスキューモード、シングルユーザモード)
 2〜4、multi-user.target(マルチユーザモード)
 5、graphical.target(GUIモード)以下のUnitも呼ばれる
  ・multi-user.target
    basic.target
 6、reboot.target(再起動)

isolateモード変更

$ systemctl isolate rescue.target

OSのシャットダウン・再起動

shutdown -h +10 "this host will shutdown in 10 minutes"

-オプション
・h(halt) 停止
-r(reboot) 再起動
-k(test) 停止せずにテストを行う
・-c(cancel) カウントダウン待ちのシャットダウンを実施
-f(no fsck) 再起動時にファイルのチェックを行わない
-F(fsck) 再起動時にファイルのチェック

・15分後にシャットダウンするコマンドを実行し、キャンセル
-h (halt・停止)+ 分 "メッセージ"

$ su -
# shutdown in 15 "this host will shutdown in 15 minutes!!"
# shutdown -c

シャットダウンコマンドとwallコマンド

・類似コマンド
 停止
  ・halt, poweroff, init 0
  ・systemctl poweroff target
 再起動
  ・reboot, shutdown reboot, init6
  ・systemctl reboot.target
 通知
  ・wall(停止はせず一斉通知)

# wall "this host will stop 20:00 p.m."

psコマンドでプロセス一覧を表示

・プロセスの生成と消滅まで
 - コマンドを実行する
 - ファイルをメモリに読み込む(プロセスの生成)
 - CPUが処理を実行する
 - メモリ上から消滅(プロセスの終了)

・プロセスを確認するpsコマンド
 - PID:プロセスID

psコマンドのオプション
・BSDフォーマット
 - a(all), f(親子関係), l(詳細), x(端末無)
 - pstreeでfは代用可能

・Unixフォーマット
 - -e(すべて), -f(詳細), -l(詳細)
※BSDフォーマットが使われることが多い

プロセス管理関連コマンド
・pgrep(検索)
・top(3秒ごとの状況)
・uptime(稼働時間)
・free(free memory)

プロセスの停止

・kill オプション PID/ %job num.
 - 1 (HUP)hang up
 - 2 (INT)interrupt
 - 9 (KILL)kill/強制終了
 - 15 (TERM)terminate/終了
 - 20 (TSTP)suspend(Ctrl+D)

・killall プロセス名
・pkill プロセス名

デスクトップ環境の利用

統合デスクトップ環境

ファイル・ディレクトリの所有者

r = 4
w = 2
x = 1

rwxr-xr-x
(4+2+1)(4+0+1)(4+0+1)
= 755

所有者・グループ・権限の変更
・chown
 - change owner
・chgrp
 - change group
・chmod
 - change mode

chmodコマンドで読み書き権限

# chmod u-r hello.txt
# chmod u+r hello.txt

ファイルのアーカイブと圧縮・展開

・tarコマンd(tape archive)
 - オプション
  ・c(create)
  ・x(展開)
  ・t(情報表示)
  ・v(verbose)
  ・f(filename)
  ・z(gunzipで圧縮)
 - cvzf(作成)、xvzf/xzfをよく利用

・cpio、ddコマンド

シェルの機能

・シェルの役割
 - ユーザ入力を受付、カーネルに命令

・シェルの種類の確認

echo $SHELL
env | grep SHELL

シェル変数・環境変数

・LANGを確認

echo $LANG

・PATH変数

PATH=$PATH:追加したいPATH
PATH=$PATH:/home/h/temp

・シェル変数を環境変数に反映
 シェル変数は子プロセスから参照できない
 環境変数は別の子プロセスから参照できる

・say_hello
- #!/bin/bash
- echo Message
- echo $MSG
・MSG=”Hello Linux!”
・export MSG

manコマンド

・man[option][section]keyword
 - -a(all)
 - -f(完全一致)fully matched
 - -k(部分一致)keyword match

ファイルの参照

・cat: concatenate
 - -n:行番号表示
  ・nlコマンドで代用可
 - ファイルの内容を連結して出力
・head/tail
 - 行数、 -n 行数
 - -f(継続的表示)

リダイレクトとパイプ

・リダイレクト
 - 書き込みモード
  ・コマンド > ファイル(上書き)
  ・コマンド >> ファイル(append)
 - オプション
  ・コマンド2 > ファイル
  ・コマンド > ファイル2 > &1
  ・コマンド $ ファイル
  ・コマンド << EOF > ファイル

pipeとteeコマンド

・標準出力にもファイルにも出力する

・コマンド | tee ファイル名
 - パイプ(|)で最初のコマンドの実行結果をteeコマンドに投入
 - 標準出力にもファイルにも出力

xargsコマンド

・コマンド実行結果を次のコマンドの引数に

viエディター

・Linux/Unixに標準搭載
 - システム管理業務やサーバー設定に必須

・2種類のモード
 - コマンドモード <=> 入力モード
 - コマンドモードは検索、削除、コピー、ペースト
 - 入力モード(i,a,oで切替)テキスト入力

カーソルの移動

・h,j,k,l
- 左、下、上、右

・移動
- w(wordの先頭), b(前の単語)
- e(wordの末尾、end)
- 0(行の先頭)、$(行末)

・検索
- /kw, n(後方検索)
- ?kw, N(前方検索)

テキスト操作

・cw(単語置換)、c$(行末まで)
・y(copy)、yy(行コピー)
・cw(1文字削除)
・d(削除)、dd(行)、dw(単語)、d$(行末)
・p(paste)
・u(undo)
・r ファイル名(ファイル内容を挿入)

セキュリティ

SUIDとSGID

・特殊な3つのパーミッション

ネットワーク基礎

TCP/IPの仕組み

・通信プロトコル(規約の1つ)
- 通信手順、データフォーマットなどの技術標準
 ・IEEE、IETFなどで提案・標準化
- パケット(データ分割、ヘッダ付加)単位で送受信

ヘッダの各層(Layer)

・ヘッダの中にさらに4つの情報を格納
- ネットワークインターフェース層
  ・Ethernet, PPP,,,
- インターネット層
  ・IP, ICMP(*ping), ARP(MACアドレス)
- トランスポート層
  ・TCP, UDP(*streaming)
- アプリケーション層
  ・FTP, SSH, Telnet, DNS, HTTP, IMAP4, POP3,,,

TCPとUDP

・TCPはデータの到着を確認
- 不足すればパケット再送

・UDPは確認ぜず、一方的にパケット送信
- ビデオ配信などリアルタイム性が高い用途

ポード番号

・ホストはIPアドレスで識別
・通信ポートを使い分けて通信(/etc/services)
- well-known port
- 20/21(FTP)
- 22(SSH)
- 25(SMTP)
- 53(DNS)
- 80/443(HTTP/HTTPS)
- 123(NTP)
- 143(IMAP)
- 389(LDAP)

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

Ubuntu Server 20.x をインストールした後のシステム周りの設定

Raspberry Pi 3 で Ubuntu Server 20.x を起動した際に諸々の設定が必要になったのでメモとしてまとめてみました。

ホスト名の設定

$ sudo hostnamectl set-hostname <HOSTNAME>

ネットワーク周りの設定(netplan)

/etc/netplan/*.yaml がファイル名順に処理され、重複する設定項目は後から処理されるファイルで上書きされる。
なので、一番最後に処理されるようなファイル名で作成する

$ sudo vi /etc/netplan/99-manual-config.yaml 

設定反映

$ sudo netplan apply

DNSリゾルバ設定

$ sudo vi /etc/systemd/resolved.conf

DNS= 行にネームサーバのIPアドレスを指定する
複数サーバを指定する場合は空白で区切って指定する

設定反映

$ sudo systemctl restart systemd-resolved.service

設定状況確認

$ resolvectl status

タイムゾーンの設定

$ sudo timedatectl set-timezone Asia/Tokyo

時刻同期設定

$ sudo vi /etc/systemd/timesyncd.conf

NTP= 行に NTP サーバを指定する
複数サーバを指定する場合には空白で区切って指定する

設定反映

$ sudo systemctl restart systemd-timesyncd

パッケージマネージャの更新とアップグレード

$ sudo apt -y update
$ sudo apt -y upgrade

ロケールの設定

$ sudo apt -y install language-pack-ja
$ sudo update-locale LANG=ja_JP.UTF-8
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Ubuntu Server 20.x をインストールした後のホスト名やnetplanなどの設定

Raspberry Pi 3 で Ubuntu Server 20.x を起動した際に諸々の設定が必要になったのでメモとしてまとめてみました。

ホスト名の設定

$ sudo hostnamectl set-hostname <HOSTNAME>

ネットワーク周りの設定(netplan)

/etc/netplan/*.yaml がファイル名順に処理され、重複する設定項目は後から処理されるファイルで上書きされる。
なので、一番最後に処理されるようなファイル名で作成する

$ sudo vi /etc/netplan/99-manual-config.yaml 

設定反映

$ sudo netplan apply

DNSリゾルバ設定

$ sudo vi /etc/systemd/resolved.conf

DNS= 行にネームサーバのIPアドレスを指定する
複数サーバを指定する場合は空白で区切って指定する

設定反映

$ sudo systemctl restart systemd-resolved.service

設定状況確認

$ resolvectl status

タイムゾーンの設定

$ sudo timedatectl set-timezone Asia/Tokyo

時刻同期設定

$ sudo vi /etc/systemd/timesyncd.conf

NTP= 行に NTP サーバを指定する
複数サーバを指定する場合には空白で区切って指定する

設定反映

$ sudo systemctl restart systemd-timesyncd

パッケージマネージャの更新とアップグレード

$ sudo apt -y update
$ sudo apt -y upgrade

ロケールの設定

$ sudo apt -y install language-pack-ja
$ sudo update-locale LANG=ja_JP.UTF-8
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

良く忘れるcron設定!

cronとは?

定期的に指定したコマンド(ジョブ)を実行してくれるやつ

どうやって設定するの?

/etc/crontabにコマンドを記載しましょう。
$ crontab -eでも設定できますが、 推奨しません。
ユーザの指定が面倒だったり、全削除の危ないオプションがあるため。
実行した瞬間に頭が真っ白になります

/etc/crontabの記載

/etc/crontabに記載例が書いてあるのでその通りに追記しましょう。

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

記載例

例:毎時0分にec2-userユーザでディスク使用状況を取得する場合
*/0 * * * * ec2-user df -h >> /tmp/diskusage_`date +'%Y%m%d_%hh%mm'`

メールが飛ぶ?

cronの実行結果がメールが飛びますが、不要な場合は
/etc/crontabのMAILTO=rootMAILTO=""に変更しましょう。

動作しないとき

1.サービスが起動しているか確認しましょう

Cent6.x/RHEL6.x系
$ service crond status
Cent7.x/RHEL7.x系
$ systemctl status crond

2.ログを見ましょう

$ tail -f /var/log/cron

3.コマンドのフォーマットが正しいか確認しましょう

$ less /etc/crontab

終わりに

読んでいただいてありがとうございます。
素敵なcronライフを!

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

良く忘れるcron設定!(RHEL6.x, 7x系)

2020/07/22 追記:
error_401さんにいただいたコメントを元に記事を大幅に修正しました。

cronとは?

定期的に指定したコマンド(ジョブ)を実行してくれるやつ

どうやって設定するの?

REHL 6公式ガイド
REHL 7公式ガイド
を参照して設定しましょう!

終わりに

素敵なcronライフを!

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

ConoHa で立ち上げた Laravel イメージだと ZipArchive が使えなかった。

状況

手元の Homestead 上では普通に使えてたので、気にせず開発していたのだけど、デプロイしたらエラー吐いたので困った。
とりあえず拡張を確認する。

$ php --ri zip
Extension 'zip' not present.

ないね。

環境

  • ConoHa VPS Laravel イメージ
  • PHP 7.2.16
  • Laravel Framework 5.8.36
  • CentOS Linux release 7.6.1810 (Core)
  • yum リポジトリは remi-php72 と remi-safe が使える

インストール

$ sudo yum install --enablerepo=remi,remi-php72 php-pecl-zip

apache 再起動

$ sudo systemctl restart httpd.service

確認

$ php --ri zip

zip

Zip => enabled
Zip version => 1.19.0
Libzip headers version => 1.7.0
Libzip library version => 1.7.3
BZIP2 compression => Yes
XZ compression => Yes
AES-128 encryption => Yes
AES-192 encryption => Yes
AES-256 encryption => Yes
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む