20190522のLinuxに関する記事は7件です。

SELinuxやFirewallは正義か?

はじめに

今どきのLinuxは、SELinuxやFirewall(ここではfirewalldやiptablesなどのソフトウェア実装を指す)がデフォルトで有効になっていることが多い。これらはインフラ屋にとって難しい存在で、セキュリティ強化をアシストしてくれる一方、これらの機能によって思い通りに操作できないことがある。

そのため

とりあえずSELinuxとFirewallは全部OFF

という人もいれば、

すぐにSELinuxとFirewallを無効にするのはエンジニアとして思考停止。お金をもらうプロフェッショナルならばセキュリティの重要度を考えるべし

と楽観主義者と原理主義者が対立している状況のような気もする。

独断と偏見で言わせてもらえば

「状況に応じて判断するべきもので、絶対的にどちらがいい」

だろう。もちろん、本番環境であれば、十分な対策を施したうえでのことではあるが。

他の代替策も考える

たとえばオンプレミスの場合、ルータでACLをがっちり固めていれば、OSのソフトウェアFWは正直なところ必要ないだろう。またクラウドではOS上のソフトウェアFWはトラブルにつながるので、そもそも無効化されていることがある(誤ったFW設定でssh接続できなくなる危険性など)。AWSでは当然それに変わる機能をクラウド側で備えている。

またSELinuxは、万が一潜入されても被害を最小限にできる機能だ。だからWAFを入れるなど、そもそも潜入させない仕組みも重要だろう。さらにその前に「クラウド上にログイン用のssh秘密鍵を置く」といったリテラシーの低い行為を徹底的に禁止すべきだ。

全体のメンバースキルも考える

とても困るのは、全体の状況やメンバーのスキルを考えない開発者で、自分のスキルに自信を持っているが故に、ガチガチに固めたうえ、ろくなドキュメントも無く、それを他人にも押しつけるケースだ。

これらを押しつけた結果、SELinuxやfirewalld/iptablesの操作が難しく開発・構築フェーズの生産性が上がらない。また運用フェーズで間違ったオペレーションをしてしまいトラブルが発生する。

さらに最悪なのは運用フェーズで何かトラブルがあっても、SELinuxやfirewalld/iptablesに精通しているメンバーが不在で、設定した本人以外はどうにもできないという状況だ。

セキュリティも重要だが、身の丈を超えたものは、他のトラブルを招く。

運用トラブルいろいろ

なんだか本題のSELinuxとFirewallから本題がそれてきた気がするが、このまま突っ走ることにする(笑)。

この手のトラブルはセキュリティ以外にもある。筆者は直接の当事者では無かったが、以下のような経験をしたことがある。

  1. 突如Webサーバが停止。Webにページアクセスできず
  2. 運用担当者がservice httpd statusで確認したところ停止していた
  3. 急いでservice httpd startでWebサーバ起動。しかし解決せず
  4. 運用手順書を見ると、独自の起動用スクリプトがあることを発見。それを使っても起動できず
  5. 最終的な原因はrpmでインストールする標準のhttpd以外に、別ディレクトリにソースコードからインストールしたWebサーバがあったこと。起動/停止には独自スクリプトを使う必要があったが、service httpd startでWebサーバを起動してしまったためにポートを確保。そのため独自の起動用スクリプトを使っても起動できなかった

ここから得られる反省点は、標準および標準化に対する認識が不足していたこと。標準のhttpd以外にhttpdがあるならば、標準のhttpdは削除しておくべきだし、依存性で削除できないならば、起動スクリプトを差し替えてワーニングのメッセージを出すのも一つだろう。

間違う可能性があるならば、それを徹底的に排除する対策をとることも重要だ。

利用者/運用者の目線を持つこと

一般的なエンタープライズシステムは、開発期間と比べて運用期間ははるかに長い。はるかに長いゆえ、開発時のことをよく知っていた運用担当者がいなくなり、保持しているノウハウも低下する。たとえ、いたとしても記憶は薄まる。

また開発者はそのとき注力しているため十分な知識があるが、利用者/運用者はそれほどの知識を持たない。

このことを十分に理解せず

「エンジニアならば、この程度のことはできるだろう」

という高い目線で設計やドキュメントすると、利用者/運用者が使いこなせず、トラブルや問い合わせ頻発というのも、ありがちな話だ。

まとめ

全然まとまっていないが、全体を俯瞰できる高い視点に立ち、ナルシストに陥らず、運用までを考慮することが重要だろう。なんだか、タイトルと全然違う内容になっている気がするけれど、ごめんなさい。

  • 全体を考えたバランス感
  • 自分だけで無く、運用担当者を含めた企業全体のリテラシーを考えた設計
  • 標準への順守。間違いづらい設計
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

hivexregeditを使うとバックスラッシュが消えてしまう問題

BCDファイルからバックスラッシュが消える

 先日Windows10が壊れまして。どうもブートローダがおかしくなったっぽいので色々いじってたら回復環境すら起動しなくなり、 http://d.sunnyone.org/2015/11/uefi-windows-safe-mode-with-linux.html < こちらの記事を頼りにUSBブートしたlinuxからBCDを直接書き換えようとしたわけです。ところが、イマイチ上手くいかない。
 気づけば、この方法で編集したregファイルをmergeするとダブルクオートで囲まれているパスの文字列からバックスラッシュが消えていたのです。

解決方法

 どうしたらいいのこれ?と言うことで検索したところ、 http://libguestfs.org/hivexregedit.1.html のSHELL QUOTINGという項目が引っかかりました。
 なので、まずはダブルクオートになっているところをシングルクオートに直してmergeしましたが、これはダメ。シングルクオートはダブルクオートに直され、そしてその中のバックスラッシュはやはり消えています。
 結局ダブルクオートの中のバックスラッシュをダブルにしたところ、merge後もバックスラッシュが維持されました。

余談

 ちなみに壊れたWindows10なのですが、上記の方法でもセーフブートすらしない状況だったのが、最近はMacでもLinuxでもWindows10のブータブルUSBを作れるみたいで、そちらから無事再インストールして回復しました。
 こんなことができるのも、Microsoftが直々にWindows10のディスクを配布しているからなんですね。 > https://www.microsoft.com/ja-jp/software-download/windows10ISO
 こんな豪奢な配布があるとはつゆ知らず、ずいぶんな遠回りをしてしまいました。

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

php-pecl-mysql-xdevapiをインストールするとApacheのリロードに失敗する問題

はじめに

PHPのモジュールで、php-pecl-mysql-xdevapiをインストールしてから
Apacheが決まった時間帯に勝手に落ちる現象が発生していたので
その原因と対策について投稿してみます。

環境

CentOS Linux release 7.6.1810 (Core)
Server version: Apache/2.4.6 (CentOS)
PHP 7.3.5 (cli)

決まった時間に落ちるのでcronを確認

/var/log/cron をみてみる。

run-parts(/etc/cron.daily)[21871]: starting logrotate
run-parts(/etc/cron.daily)[21891]: finished logrotate

cron.dailyでlogrotateが動いている。

/var/log/httpd/配下のログを確認すると、Apacheが落ちるタイミングで
ログがローテートされている。

ログローテート設定の確認

/var/logrotate.d/httpd の中身を確認してみると

/var/log/httpd/*log {
    missingok
    notifempty
    sharedscripts
    compress
    delaycompress
    postrotate
    create 0644
        /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
    endscript
}

ログローテートの際に、systemctl reload httpd が実行されている。
リロードの際にApacheが落ちてる模様

Apacheのログを確認

落ちた時間付近の /var/log/httpd/error_log に気になるログが...

PHP Fatal error:  Class mysql_xdevapi\\XSession cannot extend from interface CURLMOPT_MAXCONNECTS in Unknown on line 0
[core:notice] [pid 17512] AH00060: seg fault or similar nasty error detected in the parent process

php-pecl-mysql-xdevapiが原因っぽいログがでてる。
どうやらこのモジュールが原因でリロードした際にApacheが起動してこない模様

Apacheをリロードしてみる

systemctl reload httpd

やはりApacheが起動してこない...
ログをみると先ほど出ていたログと同様のログがでてる。

php-pecl-mysql-xdevapiを削除してみる

yum remove php-pecl-mysql-xdevapi

削除!

再度Apacheをリロードしてみる

systemctl restart httpd

一回リスタートかけてリロード実施!

systemctl reload httpd

Apacheが落ちてない!

php-pecl-mysql-xdevapiをインストールした状態でApacheをリロードすると
Apacheが立ち上がらなくなる模様

対策

1.そもそもphp-pecl-mysql-xdevapiを使用しない

2.restartなら問題なく起動するので
 /etc/logrotate.d/httpd のreload部分をrestartに変更することで
 問題なく起動する。
 ただし、ログローテートの度にApacheのリスタートが実施される。

3.ローテートの設定を下記のように、postrotateとendscriptの間を
 copytruncateに変更するとリロードなくログローテートが行える。

/var/log/httpd/*log {
    missingok
    notifempty
    sharedscripts
    compress
    delaycompress
    postrotate
    copytruncate
    endscript
}

copytruncateはリロードなくログローテートできるが、ローテート最中にきた
アクセスについては記録できないとのこと

おわりに

エンジニアになり1年たったので、たまにはこうやって記事書いたりしていこうと
思います。(たぶん)

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

Puttyで踏み台を使ったポートフォワードを設定する方法

  • 環境
    • 接続元 : Windows10
    • 踏み台 : AWS上のLinux
    • 接続先 : AWS上のRed Hat Enterprise Linux Server release 5.11
    • Putty 0.70

踏み台を設定する

  1. image.png
    1. [Connection type]に「SSH」を選択する
    2. [Port]には「22」を入力する
    3. [Host Name]に踏み台のIPアドレスかホスト名を入力する
  2. image.png
    1. サイドメニューの[Connection] > [Data]を選択
    2. [Auto-login username]に踏み台のログインIDを入力する
  3. image.png
    1. サイドメニューの[Connection] > [SSH] > [Auth]を選択
    2. [Brows...]ボタンから踏み台のPutty用の鍵(.ppk)を選択する(.pemの場合はPuttygenで.ppkに変換する)

ポートフォワードを設定する

  1. image.png
    1. サイドメニューの[Connection] > [SSH] > [Tunnel]を選択
    2. [Sour port]に接続元で使いたいポート(★)を入力する
      1. 詳細な説明は PuTTY を用いた SSH ポート転送の手順 参照
    3. [Destination]に接続先のプライベートIPアドレスとポートを入力する
      1. EC2インスタンスのプライベートIPアドレスはインスタンスの一覧でインスタンスを選択すると画面下部の[説明]タブの[プライベート IP]に表示されている
    4. [Add]ボタンで[Forwarded ports:]に追加する

設定を保存する

  1. サイドメニューの[Session]を選択
  2. [Saved Sessions]にわかる名前を入力する
  3. [Save]ボタンで保存する

接続する

  1. [Open]ボタンで接続する
  2. ブラウザでhttp://localhost:{[Sour port]に入力したポート(★)}で接続する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

メモリ残容量を意図的に減らす方法

Linuxでメモリ残容量を意図的に減らす

  • テストの一環でメモリの残容量を減らして別システムにアラームが飛ぶかを確認していたが当初考えていた手順ではうまく動かなかったのでメモ
  • 環境
# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)

最初に考えていた手順

# /dev/null < $(yes)
# free -h -s 1

実際に返ってきた結果

-bash: xrealloc: cannot allocate 18446744071562067968 bytes (1945600 bytes allocated)
  • メモリの残容量が1.8GBあたりでとまってしまう → Why?

別の方法を試す

stress --vm 2 --vm-bytes 3G --timeout 2m
  • こうなった。orz
-bash: stress: command not found
  • 導入されているパッケージが絞られている仕様のためstressコマンドが存在しなかった

/dev/null < $(yes) だけで乗り切ろうと頑張る

  • xargsで並列処理を試みる
xargs -P64 -n1 /dev/null > ($yes)
  • なぜか最初の手順と結果が変わらず

  • バックグラウンドで実行してみる

# /dev/null < $(yes) & /dev/null < $(yes) & /dev/null < $(yes)
  • 結果、順調に残メモリが減少しアラームが通知された
              total        used        free      shared  buff/cache   available
Mem:           7.6G        4.7G        1.5G         16M        1.4G        2.5G
Swap:          4.0G          0B        4.0G

              total        used        free      shared  buff/cache   available
Mem:           7.6G        5.0G        1.2G         16M        1.4G        2.2G
Swap:          4.0G          0B        4.0G

              total        used        free      shared  buff/cache   available
Mem:           7.6G        5.3G        953M         16M        1.4G        1.9G
Swap:          4.0G          0B        4.0G

              total        used        free      shared  buff/cache   available
Mem:           7.6G        5.6G        650M         16M        1.4G        1.6G
Swap:          4.0G          0B        4.0G

              total        used        free      shared  buff/cache   available
Mem:           7.6G        5.9G        352M         16M        1.4G        1.3G
Swap:          4.0G          0B        4.0G

              total        used        free      shared  buff/cache   available
Mem:           7.6G        6.2G        130M         16M        1.3G        1.0G
Swap:          4.0G        2.0M        4.0G

めでたしめでたし

疑問点

↓これは何だろう?

-bash: xrealloc: cannot allocate 18446744071562067968 bytes (1945600 bytes allocated)

xargsがうまく動かなかった理由が不明

参考文献

[意図的にLinuxサーバに負荷をかける方法 stressコマンド編]
https://blog.supersonico.info/?p=223

【Linux】stressコマンドを使わずに手軽にメモリ負荷をかける方法
https://techblog.ap-com.co.jp/entry/linux-memory

Linuxコマンド(Bash)でバックグラウンド実行する方法のまとめメモ
https://qiita.com/inosy22/items/341cfc589494b8211844

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

How to fix SIGSEGV error while installing STM32CubeMx on Ubuntu 16.04

I got an error while installing

./SetupSTM32CubeMX-5.1.0.linux

(in my case, I am installing 5.1.0 version)
This is the error message:
May 22, 2019 1:16:30 PM INFO: Logging initialized at level 'INFO'
May 22, 2019 1:16:30 PM INFO: Commandline arguments:
May 22, 2019 1:16:30 PM INFO: Detected platform: ubuntu_linux,version=4.15.0-50-generic,arch=x64,symbolicName=null,javaVersion=9-internal

# A fatal error has been detected by the Java Runtime Environment:

# SIGSEGV (0xb) at pc=0x00007f31ecc9e009, pid=12799, tid=12891

# JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-2016-04-14-195246.buildd.src)
# Java VM: OpenJDK 64-Bit Server VM (9-internal+0-2016-04-14-195246.buildd.src, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C [libjava.so+0x1d009] JNU_GetEnv+0x19

# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /path_location/en.SetupSTM32CubeMX-5.1.0-RC6/core.12799)

# An error report file with more information is saved as:
# /path_location/en.SetupSTM32CubeMX-5.1.0-RC6/hs_err_pid12799.log

# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
Aborted (core dumped)

This is the solution:

$ sudo apt-get remove jdk*
$ sudo apt-get install default-jre

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

Linuxの環境変数とプロセス制御

名前と変数がペアになっている。
アプリがその内容によって影響される。

見てみる

$ printenv
TERM_PROGRAM=Apple_Terminal
SHELL=/bin/bash
TERM_PROGRAM_VERSION=421.1.1
USER=sebec
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
HOME=/Users/sebec
LOGNAME=sebec
LC_CTYPE=UTF-8
...

変数名=値という具合で構成されている。

変数名でprintすれば一つだけ検索もできる

$ printenv PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin

環境変数を作成

export 環境変数名="値"で作成できる

環境変数を削除したい場合は

unset 変数名

$ date
Wed May 22 05:58:33 JST 2019

$ export TZ="US/Pacific"
$ date
Tue May 21 14:01:59 PDT 2019

$ unset TZ
$ date
Wed May 22 06:02:17 JST 2019

環境変数を.bash_profileで作成

$vim .bash_profile

:i #insert

export TZ="US/Pacific"

:wq! #save and quit

$ echo $TZ
US/Pacific

$ date
Tue May 21 14:08:59 PDT 2019

上記の影響を確認したいときは

$ man date
DATE(1)                   BSD General Commands Manual                  DATE(1)

NAME
     date -- display or set date and time

SYNOPSIS
     date [-jRu] [-r seconds | filename] [-v [+|-]val[ymwdHMS]] ...
          [+output_fmt]
     date [-jnu] [[[mm]dd]HH]MM[[cc]yy][.ss]
     date [-jnRu] -f input_fmt new_date [+output_fmt]
     date [-d dst] [-t minutes_west]

DESCRIPTION
     When invoked without arguments, t
....

プロセス制御

# psで確認
$ ps
  PID TTY           TIME CMD
 4563 ttys001    0:00.11 -bash

# -pで指定して確認
$ ps -p 4563
  PID TTY           TIME CMD
 4563 ttys001    0:00.12 -bash

# もう少し詳しく
$ ps -f
  UID   PID  PPID   C STIME   TTY           TIME CMD
  501  4563  4562   0 12:39AM ttys001    0:00.12 -bash

ps -e #全てのプロセス表示
ps -ef #全てのプロセスを全表示
ps -eh #プロセスのツリー表示
ps -e --forest #プロセスのツリー表示
ps -e username #Userのプロセス表示
そのほかにもpstreetophtopなどでも表示可能

bg [%num] #後ろのプログラムを保留
fg [%num] #後ろのプログラムを前に持ってくる
kill #プロセス番号かPID指定でキルできる。

Ctrl-c #プロセスをキル
kill [-sig] pid #プロセスに信号を送る
kill -l #信号の一覧
kill 123 #123をキルできる
jobs [%num] #jobを表示

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