- 投稿日：2020-05-18T23:34:56+09:00
AWS EC2でAWS SDK for PHPインストール（PHP7.2＋Apache2.4.41 + OPCashe + Composer）
Amazon Linux EC2でAPI叩いてからDynamoDBに保存するときに
PHPでやりたかったので、AWS SDK for PHPを入れようとしました。しかし、色々課題が発生したので、備忘録にします。自分用ですが、
対象読者は、「色々やったけど調べる内に、ここに行き着いた人」です。
助力になれば、幸いです。$ cat /etc/system-release Amazon Linux release 2 (Karoo)AmazonLinux2 ExtrasLibraryで PHP7.2をインストール
＄ sudo amazon-linux-extras install php7.2 $ sudo yum install php php-mbstring $ sudo yum list installed | grep php php-cli.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2 php-common.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2 php-fpm.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2 php-json.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2 php-mysqlnd.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2 php-pdo.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2参考：https://qiita.com/owlbeck/items/20f3e5402cb782f6291e
Apache をインストール
$ sudo yum install httpd $ systemctl start httpd $ systemctl status httpd ● httpd.service - The Apache HTTP Server Active: active (running)OPCashe をインストール
sudo yum install php-opcacheComposer をインストール
$ curl -sS https://getcomposer.org/installer | php $ ls composer.phar $ php composer.phar $ mv composer.phar /usr/local/bin/composer $ composer最後の二行はPATHが通っている場所に引っ越しただけです。これでかっこいいロゴを表示できます。
参考：https://getcomposer.org/doc/00-intro.md
参考：https://qiita.com/kakijin/items/02364adacf36410f449eAWS SDK for PHP の使用開始
$ sudo -i $ cd /usr/local/bin/composer $ vi composer.json //jsonに書き込みcomposer.json{ "require": { "aws/aws-sdk-php": "2.*" } }$ php composer.phar installphpに書き込んで終了require '/path/to/sdk/vendor/autoload.php';終了
- 投稿日：2020-05-18T22:54:52+09:00
【CentOS7.7】デスクトップ環境インストール～リモートデスクトップ接続可能迄(最小限インストールから)
はじめに
WindowsからCentOSのGUI環境に業務でRDP接続するように設定する機会がありました。
今回は、ナレッジとしてこちらを残したいと思います。環境
端末 : Windows 10 Pro
OS: CentOS7.7[root@tspshell01 ~]# cat /etc/redhat-release CentOS Linux release 7.7.1908 (Core) [root@tspshell01 ~]#「最小限のインストール」にてOSインストール
前提条件
下記設定が完了していること
・ホスト名/IPアドレス設定
・DNS設定「/etc/yum.repos.d」直下が初期状態であること
※下記が初期状態[root@tspshell01 ~]# ll /etc/yum.repos.d/ 合計 32 -rw-r--r--. 1 root root 1664 9月 5 2019 CentOS-Base.repo -rw-r--r--. 1 root root 1309 9月 5 2019 CentOS-CR.repo -rw-r--r--. 1 root root 649 9月 5 2019 CentOS-Debuginfo.repo -rw-r--r--. 1 root root 630 9月 5 2019 CentOS-Media.repo -rw-r--r--. 1 root root 1331 9月 5 2019 CentOS-Sources.repo -rw-r--r--. 1 root root 6639 9月 5 2019 CentOS-Vault.repo -rw-r--r--. 1 root root 314 9月 5 2019 CentOS-fasttrack.repo [root@tspshell01 ~]#
- インターネット上に接続できていること
手順
手順についてはこちらになります。
①ファイアウォールを無効化する(もしくはポートを開放する)
②リポジトリファイルの読み込み
③GNOMEデスクトップのインストール
④epelリポジトリのインストール
⑤リモートデスクトップに必要なパッケージのインストール
⑥動作確認では、解説していきます。
①ファイアウォールを無効化する(もしくはポートを開放する)
- ファイアウォール無効化/自動起動無効
・ファイアウォール停止 systemctl status firewalld systemctl stop firewalld systemctl status firewalld ・ファイアウォール無効化 systemctl is-enabled firewalld systemctl disable firewalld systemctl is-enabled firewalld
- 3389ポート開放(ファイアウォールを停止しない場合)
firewall-cmd --permanent --zone=public --add-port=3389/tcp firewall-cmd --reload firewall-cmd --list-all②リポジトリファイルの読み込み
※リポジトリ(repository)とはファイルの保管場所になります。
「/etc/yum.repos.d」直下にファイルの保管場所へアクセスするための接続先が記載されたファイルが保存されています。
- yumのキャッシュクリア
yum clean all
- 「/etc/yum.repos.d」直下のファイルの読み込み
yum repolist all→「base/7/x86_64」が有効であることを確認
③GNOMEデスクトップのインストール
yum groupinstall "GNOME Desktop"※インストール直前に「yes」か「no」を聞かれるので、「y」を実行
④epelリポジトリのインストール
「epelリポジトリ」は「xrdp」のインストールに使用します。
- 「/etc/yum.repos.d」直下にepelリポジトリをインストール
yum install epel
- 「/etc/yum.repos.d」直下に「epel.repo」があることを確認
[root@tspshell01 yum.repos.d]# ll /etc/yum.repos.d/ 合計 36 -rw-r--r--. 1 root root 1664 9月 5 2019 CentOS-Base.repo -rw-r--r--. 1 root root 649 9月 5 2019 CentOS-Debuginfo.repo -rw-r--r--. 1 root root 630 9月 5 2019 CentOS-Media.repo -rw-r--r--. 1 root root 1331 9月 5 2019 CentOS-Sources.repo -rw-r--r--. 1 root root 6639 9月 5 2019 CentOS-Vault.repo -rw-r--r--. 1 root root 314 9月 5 2019 CentOS-fasttrack.repo -rw-r--r-- 1 root root 1050 10月 3 2017 epel-testing.repo -rw-r--r-- 1 root root 951 10月 3 2017 epel.repo [root@tspshell01 yum.repos.d]#
- yumのキャッシュクリアを実施
yum clean all
- 「/etc/yum.repos.d」直下のファイルの読み込み
yum repolist all⑤リモートデスクトップに必要なパッケージのインストール
- パッケージインストール
yum install tigervnc-server yum install xrdp※「yes」か「no」の選択肢については全て「y」にて実施
- xrdpサービス起動/自動起動
・xrdpサービス起動 systemctl status xrdp systemctl start xrdp systemctl status xrdp・xrdp自動起動 systemctl is-enabled xrdp systemctl enable xrdp systemctl is-enabled xrdp⑥動作確認
- リモートデスクトップを起動後、IPアドレスを入力&接続
(「mstsc」にて一発起動可能)
- 接続成功した場合、ログイン画面が表示される。 サーバーのユーザー名/パスワードを入力
- ログイン成功した場合は、このような画面が表示される。
リモートデスクトップができない場合(もしくはログインできない場合)
- セッションの変更
- 画面の色深さ設定
セッションの変更
※ログイン後に画面が真っ暗で表示されない場合の対処方法になります。
「Xvnc」→「Xorg」
- 設定ファイルバックアップ
cp -p /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini_`date "+%Y%m%d_%H%M%S"`
- ファイルバックアップの確認
[root@tspshell01 yum.repos.d]# ll /etc/xrdp | grep xrdp -rw-r--r-- 1 root root 5427 3月 11 19:53 xrdp.ini -rw-r--r-- 1 root root 5427 3月 11 19:53 xrdp.ini_20200518_223104 -rw-r--r-- 1 root root 3570 3月 11 19:53 xrdp_keyboard.ini [root@tspshell01 yum.repos.d]#
- ファイル内容変更
vi /etc/xrdp/xrdp.ini※「vi」の使用方法については割愛します。
修正前
#[Xorg] #name=Xorg #lib=libxup.so #username=ask #password=ask #ip=127.0.0.1 #port=-1 #code=20 [Xvnc] name=Xvnc lib=libvnc.so username=ask password=ask ip=127.0.0.1 port=-1 #xserverbpp=24 #delay_ms=2000修正後
[Xorg] name=Xorg lib=libxup.so username=ask password=ask ip=127.0.0.1 port=-1 code=20 #[Xvnc] #name=Xvnc #lib=libvnc.so #username=ask #password=ask #ip=127.0.0.1 #port=-1 #xserverbpp=24 #delay_ms=2000→ログイン画面に「Xorg」のみ表示させる設定
- バックアップファイルと比較
diff /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini_20200518_223104実行結果
[root@tspshell01 yum.repos.d]# diff /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini_20200518_223104 181,192c181,183 < [Xorg] < name=Xorg < lib=libxup.so < username=ask < password=ask < ip=127.0.0.1 < port=-1 < code=20 < < #[Xvnc] < #name=Xvnc < #lib=libvnc.so --- > #[Xorg] > #name=Xorg > #lib=libxup.so 196a188,196 > #code=20 > > [Xvnc] > name=Xvnc > lib=libvnc.so > username=ask > password=ask > ip=127.0.0.1 > port=-1 [root@tspshell01 yum.repos.d]#→編集した箇所のみ差異があること
- 「xrdp」サービス再起動
systemctl status xrdp systemctl restart xrdp systemctl status xrdp
- リモートデスクトップ実施
接続できることを確認(sessionが「Xorg」に変更されている)
画面の色深さ設定
※ログイン後にGUI画面の表示がおかしい場合の対処方法になります。
- 設定ファイルバックアップ
cp -p /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini_`date "+%Y%m%d_%H%M%S"`
- ファイルバックアップ確認
[root@tspshell01 yum.repos.d]# ll /etc/xrdp | grep xrdp -rw-r--r-- 1 root root 5426 5月 18 22:37 xrdp.ini -rw-r--r-- 1 root root 5427 3月 11 19:53 xrdp.ini_20200518_223104 -rw-r--r-- 1 root root 5426 5月 18 22:37 xrdp.ini_20200518_224629 -rw-r--r-- 1 root root 5426 5月 18 22:37 xrdp.ini_20200518_224633 -rw-r--r-- 1 root root 3570 3月 11 19:53 xrdp_keyboard.ini [root@tspshell01 yum.repos.d]#
- 設定ファイル変更
vi /etc/xrdp/xrdp.ini修正前
max_bpp=32修正後
max_bpp=24
- バックアップファイルと比較
[root@tspshell01 yum.repos.d]# diff /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.ini_202005 18_224633 73c73 < max_bpp=24 --- > max_bpp=32 [root@tspshell01 yum.repos.d]#→編集した箇所のみ差異があること
- 「xrdp」サービス再起動
systemctl status xrdp systemctl restart xrdp systemctl status xrdp
- リモートデスクトップ実施
接続できることを確認
参考ページ
CentOS7にxrdpを導入しWindowsからリモートデスクトップで接続
https://qiita.com/shinoere/items/35793d9c6155145cb37cxrdp
https://qiita.com/n-yamanaka/items/653af5cdac63721ff074主にインフラエンジニアのキャリアハック等について呟いています。**
https://twitter.com/satton6987
- 投稿日：2020-05-18T22:48:11+09:00
Secure ROS with AppArmor
Overview
ROS2(Robot Operating System 2) Security has access control via AppArmor, it is built on top of Linux Security MNodules, available on Linux 2.6.36.
Here describes the following,
- Background
- Linux Security Modules
- AppArmor Tutorial
Background
UNIX controls permission via user, group and so on as legacy access control. for specific access granted control we used to use root, but root is wide-open permission can access on anything. there was use case, user wants to have certain access permission but not root privileged access permission for security. against this situation, AppArmor or SELinux has been developed.
for my experience,
- SELinux is way more complicated to use, system perspective.
- AppArmor is easier to enable, application perspective.
also these are dependent on use cases, and precisely what you want to protect.
Linux Security Modules
LSM is Linux Kernel security framework. It is provided not only to AppArmor but also SELinux as base security framework in Linux. It is not loadable module, it is statically build with the following configuration.
>cat /boot/config-5.3.0-51-generic | grep CONFIG_LSM CONFIG_LSM_MMAP_MIN_ADDR=0 CONFIG_LSM="yama,integrity,apparmor"as implementation, refer to around https://github.com/torvalds/linux/blob/master/security/apparmor/lsm.c
e.g) static void apparmor_cred_free(struct cred *cred) { aa_put_label(cred_label(cred)); set_cred_label(cred, NULL); }These are dedicated AppArmor static functions will be registered as LSM hook callback. LSM provides generic interface to connect backend callbacks which are AppArmor implementation which set label and restrict the access from the application based on profile.
AppArmor Tutorial
LSM provides limitation and constrain to access based on the user specified profile. So that is user's responsibility to set appropriate access profile.
AppArmor has two modes,
- Complain Access will be checked, but not actually blocked. (such as SELinux permissive mode.)
- Enforce Access will be checked and blocked if not with access permission.
command line tool is available to check current status,
# aa-status apparmor module is loaded. 42 profiles are loaded. 39 profiles are in enforce mode. ...<snip>profile files are store in /etc/apparmor.d
# ls -F /etc/apparmor.d/ abstractions/ sbin.dhclient usr.lib.libreoffice.program.oosplash usr.sbin.cups-browsed cache/ tunables/ usr.lib.libreoffice.program.senddoc usr.sbin.cupsd disable/ usr.bin.evince usr.lib.libreoffice.program.soffice.bin usr.sbin.ippusbxd force-complain/ usr.bin.firefox usr.lib.libreoffice.program.xpdfimport usr.sbin.rsyslogd local/ usr.bin.man usr.lib.snapd.snap-confine.real usr.sbin.tcpdumplet's see what inside of profile,
# ls /etc/apparmor.d/usr.bin.man /etc/apparmor.d/usr.bin.manthis profile applied to /usr/bin/man
# cat /etc/apparmor.d/usr.bin.test #include <tunables/global> profile test /usr/lib/test/test_binary { #include <abstractions/base> # Main libraries and plugins /usr/share/TEST/** r, /usr/lib/TEST/** rm, # Configuration files and logs @{HOME}/.config/ r, @{HOME}/.config/TEST/** rw, }
r: readw: writem: memory map executablex: executable@: environmental variables, declared in /etc/apparmor.d/abstractions/ or /etc/apparmor.d/tunables/http://manpages.ubuntu.com/manpages/xenial/man5/apparmor.d.5.html
AppArmor will parse the profile into binary format when loading, so it takes time to be effective. This means boot time will be longer than usual sometimes, so it can cache the binary profile data in the file system.
# cat /etc/apparmor/parser.conf # parser.conf is a global AppArmor config file for the apparmor_parser # ...<snip> ## Turn creating/updating of the cache on by default #write-cacheuncomment above
write-cacheline to make it faster to boot up, also if you want you can addcache-loc=/path/to/locationto store the cached data.Reference
- 投稿日：2020-05-18T22:35:59+09:00
lessコマンドでよく使う使い方ベスト3
- 投稿日：2020-05-18T22:13:35+09:00
ファイルを保存時に自動でテストを実行する
テスト駆動開発において、「ファイルを更新」 -> 「コンソールでテストコマンドを実行」 というプロセスが面倒でした。
そこで、このプロセスを自動化する方法を記載します。動作イメージ
環境
- Ubuntu 18.04
準備
sudo apt install inotify-toolsコード
以下のスクリプトを作成し、プロジェクトのルートに配置します。
autorun.sh#!/usr/bin/env bash TEST_RUNNER="pytest -s tests" # 実行したいテストコマンドを指定 TARGETS="./src ./tests" # 監視したディレクトリを指定 while inotifywait -r -e modify -e create -e delete $TARGETS; do $TEST_RUNNER done実行権限も付与。
chmod +x ./autorun.sh実行
./autorun.sh参考
- 投稿日：2020-05-18T16:45:03+09:00
Linux基礎1 -シェルとは何か？-
内容
- Linux基礎
シェルとは何か？
Linuxでは、キーボードを使ってコマンドを入力することが基本操作になる。
このとき、LinuxカーネルとUserの橋渡しをしてくれるのがシェル。シェルとコマンド
- コマンド -> 処理を行うための命令のようなもの。日時を扱うdateや指定した文字列を表示するechoなどがある。
# dateコマンドの実行 [nossy@localhost ~]$ date 2020年 5月 18日 月曜日 15:00:00 JST # echoコマンドの実行 [nossy@localhost ~]$ echo Hello Helloシェルとカーネル
- カーネル -> OSの中核。CPUやメモリなどのハードウェアの管理とコマンド実行を処理するプロセス管理を行う。
- シェル -> アプリ起動に特化し、ユーザへのインターフェースとなっているソフト
シェルとカーネルの動作
- シェルはUserからのコマンド入力を受け付ける
- シェルはコマンドを探して、カーネルに実行を依頼する
- カーネルは依頼内容に応じたアプリを起動する
- シェルから起動されたアプリは、個別にユーザへ結果を出力する
※シェルを例えるなら「司会者」
進行指示に応じて色んな人に話を振って、実際に話をするのは、振られた各担当者詳しくはシェル(UNIX)のイメージのよくある誤解を参照のこと
なぜシェルとカーネルが別れているのか
- カーネルに手を加えずにシェルだけを自分好みに設定できる
- Linux以外のOSを利用する際も、シェルが移植されていれば操作を同様に行うことができる
- シェルがエラーや高負荷状態になってクラッシュしても、OS本体であるカーネルへの影響を最小限に抑えることができる
プロンプト
- プロンプト -> 何かコマンドを入力してください、というシェルの意思表示の現れ
[nossy@localhost ~]$
- nossyがユーザ名
- localhostがホスト名
- $がプロンプト記号
- スーパーユーザーの場合は #
- 一般ユーザの場合は $
ログインシェル
ログイン時に最初から起動されるシェルのこと
$ echo $SHELL #ログインシェルの確認コマンド /bin/bashこの場合のログインシェルは /binディレクトリのbash
対話型操作とシェルスクリプト
- 対話型 -> Userがキーボードと画面を利用して直接シェルを操作する方法(インタラクティブともいう)。
- シェルスクリプト -> 実行したいコマンド群をファイルに記述しておいて、そのファイルをシェルに指定することでまとめて実行することができる。一連の流れを記述したファイルのことをシェルスクリプトと呼ぶ
シェルの種類
シェル 概要 sh Bourne氏によって開発された、古くから存在するシェル。Bシェルと呼ばれる。古いため機能が少なく、対話的に使うには不便。現在ではログインシェルとして使われることはほとんどない。 csh Cシェルと呼ばれる。shに比べ、対話型操作が便利になる機能を実装したことで人気があったが、シェルスクリプトを書く上で欠陥がある。cshの後継のtcshがあるため、ほとんど使用されない。 bash shを基本として機能を拡張したシェル。shと後方互換性をもつため、単純にshを置き換える用途でも利用できる。対話型として十分な機能を持ち、多くのLinux環境でデフォルトのログインシェルとして使用されている。シェルスクリプトを記述するのにも向いている。 tcsh cshの光景をして開発されたCシェル系のシェル。対話型には便利な機能を持っているが、シェルスクリプトには不向き。なおtcshなどのCシェル系では、一般ユーザーのプロンプト記号として$ではなく%が用いられる。徐々に利用者は減っている模様。 zsh 比較的新しいシェル。bashやtcshをはじめとした他のシェルの機能を取り込み、機能面では他のシェルを圧倒している。全ての機能を使いこなせば非常に効率よく作業できることから人気の高いシェル。玄人向。 どのシェルを選ぶべきか
Linuxの学習にはbashがおすすめ
理由
- Linuxのデフォルトログインシェルとして採用されており、利用機会が多い
- 定和的に使うにも、シェルスクリプトを利用するにも、十分な機能を持っている
- shと後方互換性をもつため、既存のsh用のシェルスクリプトをそのまま利用できる。
- Linux以外にもFreeBSD/Solaris/Mac OS Xなど多くの環境に移植されている
- 利用者が多く、書籍やWebから情報が得やすい
shは重要なシェル
過去にshで書かれたシェルスクリプトは数多く、例えば、Linuxの起動処理では多くのshシェルスクリプトが使われている。
C系シェルはさほど重要ではない
シェルスクリプトを書くのに致命的な欠陥が多いため、過去のスクリプトを修正するという一部のケースを除いて使うべきではない。対話型として用いたい場合にもzshがあるため、それで良い。
シェルを一時的に切り替える
- シェルも1つのコマンド。単に使いたいシェルの名前を指定すれば切り替えが可能。実際は多重に起動しているため、重ねているという認識。下の図を参照。
- ログインシェルの変更はchshというコマンドで可能だが、操作を誤るとログインできなくなる可能性があるため玄人向け。
ターミナルとは
- ターミナル -> ユーザがコンピュータに入出力する際に利用する専用のハードウェアのこと。
現在のLinuxを利用する際に、ハードウェアとしてのターミナルが使われることはほとんどない。その代わりに物理的なターミナルをソフトウェアによって実装した、ターミナルエミュレータが利用される。ターミナルエミュレータはLinuxマシンを直接動作させることも可能。また、MaxOS Xなど一般的なパソコン上でアプリケーションとして利用可能。
主なターミナルエミュレータ
OS ターミナルエミュレータ windows Putty, Tera Term MacOS X ターミナル, iTerm2 Linux GNOME端末, Konsole ターミナルとシェル
ターミナルとシェルは全く違うソフトウェア。
ターミナルエミュレータは入出力のためのインターフェイス(画面)を提供しているだけ。ターミナルエミュレータのウィンドウの中で、Linuxマシンのシェルが動作している。
- 投稿日：2020-05-18T16:45:03+09:00
Linux基礎 -シェルとは何か？-
内容
- Linux基礎
シェルとは何か？
Linuxでは、キーボードを使ってコマンドを入力することが基本操作になる。
このとき、LinuxカーネルとUserの橋渡しをしてくれるのがシェル。シェルとコマンド
- コマンド -> 処理を行うための命令のようなもの。日時を扱うdateや指定した文字列を表示するechoなどがある。
# dateコマンドの実行 [nossy@localhost ~]$ date 2020年 5月 18日 月曜日 15:00:00 JST # echoコマンドの実行 [nossy@localhost ~]$ echo Hello Helloシェルとカーネル
- カーネル -> OSの中核。CPUやメモリなどのハードウェアの管理とコマンド実行を処理するプロセス管理を行う。
- シェル -> アプリ起動に特化し、ユーザへのインターフェースとなっているソフト
シェルとカーネルの動作
- シェルはUserからのコマンド入力を受け付ける
- シェルはコマンドを探して、カーネルに実行を依頼する
- カーネルは依頼内容に応じたアプリを起動する
- シェルから起動されたアプリは、個別にユーザへ結果を出力する
※シェルを例えるなら「司会者」
進行指示に応じて色んな人に話を振って、実際に話をするのは、振られた各担当者詳しくはシェル(UNIX)のイメージのよくある誤解を参照のこと
なぜシェルとカーネルが別れているのか
- カーネルに手を加えずにシェルだけを自分好みに設定できる
- Linux以外のOSを利用する際も、シェルが移植されていれば操作を同様に行うことができる
- シェルがエラーや高負荷状態になってクラッシュしても、OS本体であるカーネルへの影響を最小限に抑えることができる
プロンプト
- プロンプト -> 何かコマンドを入力してください、というシェルの意思表示の現れ
[nossy@localhost ~]$
- nossyがユーザ名
- localhostがホスト名
- $がプロンプト記号
- スーパーユーザーの場合は #
- 一般ユーザの場合は $
ログインシェル
ログイン時に最初から起動されるシェルのこと
$ echo $SHELL #ログインシェルの確認コマンド /bin/bashこの場合のログインシェルは /binディレクトリのbash
対話型操作とシェルスクリプト
- 対話型 -> Userがキーボードと画面を利用して直接シェルを操作する方法(インタラクティブともいう)。
- シェルスクリプト -> 実行したいコマンド群をファイルに記述しておいて、そのファイルをシェルに指定することでまとめて実行することができる。一連の流れを記述したファイルのことをシェルスクリプトと呼ぶ
シェルの種類
シェル 概要 sh Bourne氏によって開発された、古くから存在するシェル。Bシェルと呼ばれる。古いため機能が少なく、対話的に使うには不便。現在ではログインシェルとして使われることはほとんどない。 csh Cシェルと呼ばれる。shに比べ、対話型操作が便利になる機能を実装したことで人気があったが、シェルスクリプトを書く上で欠陥がある。cshの後継のtcshがあるため、ほとんど使用されない。 bash shを基本として機能を拡張したシェル。shと後方互換性をもつため、単純にshを置き換える用途でも利用できる。対話型として十分な機能を持ち、多くのLinux環境でデフォルトのログインシェルとして使用されている。シェルスクリプトを記述するのにも向いている。 tcsh cshの光景をして開発されたCシェル系のシェル。対話型には便利な機能を持っているが、シェルスクリプトには不向き。なおtcshなどのCシェル系では、一般ユーザーのプロンプト記号として$ではなく%が用いられる。徐々に利用者は減っている模様。 zsh 比較的新しいシェル。bashやtcshをはじめとした他のシェルの機能を取り込み、機能面では他のシェルを圧倒している。全ての機能を使いこなせば非常に効率よく作業できることから人気の高いシェル。玄人向。 どのシェルを選ぶべきか
Linuxの学習にはbashがおすすめ
理由
- Linuxのデフォルトログインシェルとして採用されており、利用機会が多い
- 定和的に使うにも、シェルスクリプトを利用するにも、十分な機能を持っている
- shと後方互換性をもつため、既存のsh用のシェルスクリプトをそのまま利用できる。
- Linux以外にもFreeBSD/Solaris/Mac OS Xなど多くの環境に移植されている
- 利用者が多く、書籍やWebから情報が得やすい
shは重要なシェル
過去にshで書かれたシェルスクリプトは数多く、例えば、Linuxの起動処理では多くのshシェルスクリプトが使われている。
C系シェルはさほど重要ではない
シェルスクリプトを書くのに致命的な欠陥が多いため、過去のスクリプトを修正するという一部のケースを除いて使うべきではない。対話型として用いたい場合にもzshがあるため、それで良い。
シェルを一時的に切り替える
- シェルも1つのコマンド。単に使いたいシェルの名前を指定すれば切り替えが可能。実際は多重に起動しているため、重ねているという認識。下の図を参照。
- ログインシェルの変更はchshというコマンドで可能だが、操作を誤るとログインできなくなる可能性があるため玄人向け。
ターミナルとは
- ターミナル -> ユーザがコンピュータに入出力する際に利用する専用のハードウェアのこと。
現在のLinuxを利用する際に、ハードウェアとしてのターミナルが使われることはほとんどない。その代わりに物理的なターミナルをソフトウェアによって実装した、ターミナルエミュレータが利用される。ターミナルエミュレータはLinuxマシンを直接動作させることも可能。また、MaxOS Xなど一般的なパソコン上でアプリケーションとして利用可能。
主なターミナルエミュレータ
OS ターミナルエミュレータ windows Putty, Tera Term MacOS X ターミナル, iTerm2 Linux GNOME端末, Konsole ターミナルとシェル
ターミナルとシェルは全く違うソフトウェア。
ターミナルエミュレータは入出力のためのインターフェイス(画面)を提供しているだけ。ターミナルエミュレータのウィンドウの中で、Linuxマシンのシェルが動作している。
- 投稿日：2020-05-18T06:34:37+09:00
USB Raw Gadget
https://www.kernel.org/doc/html/latest/usb/raw-gadget.html
Linux Kernel 5.7-rc1からサポートされた、USB Raw Gadget！
やったね！！ユーザー空間でうごくアプリケーションで、USB Gadgetが作れるようになったよ！
Docs » USB support » USB Raw Gadget
USB Raw Gadget
USB Raw Gadget is a kernel module that provides a userspace interface for the USB Gadget subsystem. Essentially it allows to emulate USB devices from userspace. Enabled with CONFIG_USB_RAW_GADGET. Raw Gadget is currently a strictly debugging feature and shouldn’t be used in production, use GadgetFS instead.
USB Raw Gadgetは、USB Gadget subsystemへのユーザー空間インタフェイスを提供するものです。本質的には、ユーザー空間からUSB deviceをエミュレーションすることを許容します。CONF_USB_RAW_GADGETを有効にしてください。Raw Gadgetは現在、厳密にデバッグ中の機能であり、製品では使わないでください。その代わりに、GadgetFSを使ってください。
Comparison to GadgetFS
Raw Gadget is similar to GadgetFS, but provides a more low-level and direct access to the USB Gadget layer for the userspace. The key differences are:
Raw GadgetはGadgetFSに似ていますが、ユーザー空間からUSB Gadget layerへ、低レベルで直接的なアクセスを提供します。主な差分は以下です。
１. Every USB request is passed to the userspace to get a response, while GadgetFS responds to some USB requests internally based on the provided descriptors. However note, that the UDC driver might respond to some requests on its own and never forward them to the Gadget layer.
１. すべてのUSB要求は、応答を得るためにユーザー空間へ渡されます。GadgetFSでは提供された記述子(descriptor)に応じて、内部的に一部のUSB要求へ応答をします。ただし、UDCドライバーは一部の要求に独自で応答し、それらをGadget Layerに転送しない場合があります。
２. GadgetFS performs some sanity checks on the provided USB descriptors, while Raw Gadget allows you to provide arbitrary data as responses to USB requests.
２. GadgetFSは提供されたUSB記述子において正当性を確認します。Raw GadgetではUSB要求への応答として任意のデータを提供することができます。
３. Raw Gadget provides a way to select a UDC device/driver to bind to, while GadgetFS currently binds to the first available UDC.
３. Raw Gadgetでは、バインドしたいUDC device/driverを選択する手段を提供しますが、GadgetFSでは現在、最初に有効なUDCをバインドします。
４. Raw Gadget uses predictable endpoint names (handles) across different UDCs (as long as UDCs have enough endpoints of each required transfer type)
４. Raw Gadgetは、異なるUDCを横断して、予想できるendpoint name(handke)を利用します(UDCに必要なとなるそれぞれの転送タイプ.のendpointが十分ある場合に限っては）。
５.Raw Gadget has ioctl-based interface instead of a filesystem-based one.
５. Raw Gadgeはfilesystem-basedの代わりに、uictl-baseのインタフェイスを提供します。
Userspace interface
To create a Raw Gadget instance open /dev/raw-gadget. Multiple raw-gadget instances (bound to different UDCs) can be used at the same time. The interaction with the opened file happens through the ioctl() calls, see comments in include/uapi/linux/usb/raw_gadget.h for details.
Raw Gadget instanceを作るためには、/dev/raw-gadetを開いてください。複数のraw-gadget instanceを（異なるUDCsのために）同じ時間で利用することができます。開いたファイルとの対話には、ioctl() を呼び出します。詳細については、include/uapi/linux/usb/raw_gadget.hのコメントを参照してください。
The typical usage of Raw Gadget looks like:
典型的なRaw Gadgetの使い方は以下になります。
１. Open Raw Gadget instance via /dev/raw-gadget.
２. Initialize the instance via USB_RAW_IOCTL_INIT.
３. Launch the instance with USB_RAW_IOCTL_RUN.
４. In a loop issue USB_RAW_IOCTL_EVENT_FETCH calls to receive events from Raw Gadget and react to those depending on what kind of USB device needs to be emulated.１．Raw Gadget instanceを、/dev/raw-gadetを介して開く。
２．USB_RAW_IOCTL_INITによって、インスタンスを初期化する。
３．USB_RAW_IOCTL_RUNによって、インスタンスを起動する。
４．RAW_IOCTL_EVENT_FETCHにより、Raw Gadgetからのイベントを受信しながらループを行い、エミュレーションするべきUSB deviceのような反応をする。Potential future improvements
・Implement ioctl’s for setting/clearing halt status on endpoints.
・Reporting more events (suspend, resume, etc.) through USB_RAW_IOCTL_EVENT_FETCH.
・Support O_NONBLOCK I/O.・endpointの停止ステータスを設定/クリアするための、ioctlの実装
・USB_RAW_IOCTL_EVENT_FETCHを介しての様々なイベント(suspend, resume, 他）のレポート。
・O_NONBLOCK I/Oのサポート。
もともと、Linux Kernelのソースコードの一部なので、GPLv2扱いになる（はずの認識）。
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing
- 投稿日：2020-05-18T00:21:17+09:00
ibusが行方不明になる症状改善策
ibusが行方不明になる症状改善策
備忘録です。
ibusが行方不明になる症状の改善策
On kde
ibus-daemon autostart
Open Ibus-Preferences (Press yes and start the daemon)
When Ibus-preferences window opens do not close it.Now goto application menu and search Input Method. Open it.
It will show a msg just press ok and then on the 2nd msg press yes to update it.
Then select Ibus and press ok.
You're done.Then goto application menu -> auto start-> add (ibus-daemon)