openSUSEはnmapからどう見えるか

By ribbon @ 2019-12-18 00:11

セキュリティ的な観点からサーバの情報を調べるツールとしてnmapがあります。nmapを使うと、そのサーバがどのような種類かを外部から調べることができます。そこで、 nmapからopenSUSEサーバはどのように見えるかを簡単に調べてみました。

nmapはOSやディストリビューションごとにバージョンが異なります。できるだけ最新の方がよいので、openSUSE 15.1/15.0に含まれているものを使用しました。バージョンはどちらも7.70 です。
openSUSE 15.0から15.1に対してテストした結果は以下の通りです。

# nmap -O 172.31.255.189
Starting Nmap 7.70 ( https://nmap.org ) at 2019-12-14 16:42 JST
Nmap scan report for 172.31.255.189
Host is up (0.00051s latency).
(略)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 – 4.9

意外とおおざっぱな結果しか出ませんね。15.1から15.0へも同じ結果でした。
では、ほかのディストリビューションではどうでしょうか。手元ですぐに試せるものを試してみたところ、
CentOS 7.4

OS details: Linux 3.10 – 4.11, Linux 3.2 – 4.9

Windows 10

Running (JUST GUESSING): Microsoft Windows XP|7|2008 (87%)

Windows 8.1

Running: Microsoft Windows 2008|8.1|7|Phone|Vista

Windows Server 2012R2
という感じになりました。やはり以外とおおざっぱです。
ということで、 nmapで調べると、どの系統のOSか、という所くらいまでは分かる、という事がわかりました。

この記事はopenSUSE Advent Calendar 2019の13日目です。

今回は、openSUSEでパッケージをインストールする3つのメジャーな方法を紹介させて頂きます。

  • YaSTの「ソフトウエア管理」からインストール
  • コンソールからzypperコマンドでインストール
  • Webサイトから1-clickインストール

YaSTの「ソフトウエア管理」からインストール

簡単設定ツールYaSTの「ソフトウェア管理」で、パッケージをインストールしたりアップグレードしたりできます。YaSTは、左下のアプリケーションランチャーから、「アプリケーション > 設定 > 管理者設定(YaST)」で起動できます。

起動したら、「ソフトウエア管理」を選びましょう。リポジトリ情報などを取得した後、管理画面が開きます。

YaSTのメニュー
ソフトウエア管理でpodmanを検索

左上の場所にパッケージ名を入力して、「検索」をクリックすれば、右側に一覧が表示されます。インストールしたいパッケージを選択して、右下の「了解」をクリックしましょう。

コンソールからzypperコマンドでインストール

コマンド「zypper 」で、パッケージ管理ができます。パッケージを検索したい時は以下のコマンドです。

$ zypper se [検索したいパッケージ名]

seはsearchのseです。searchとフルでタイプしても大丈夫です。該当するパッケージがあれば、一覧が表示されます。

リポジトリのデータを読み込んでいます…
インストール済みのパッケージを読み込んでいます…

S  | 名前                   | 概要                                                                  | 種類             
—+————————+———————————————————————–+—————–
  | podman                 | Daemon-less container engine for managing containers, pods and images | ソースパッケージ
i+ | podman                 | Daemon-less container engine for managing containers, pods and images | パッケージ       
i  | podman-cni-config      | Basic CNI configuration for podman                                    | パッケージ       
  | python-podman          | A library to interact with a Podman server                            | ソースパッケージ
  | python-podman-compose  | A script to run docker-compose using podman                           | ソースパッケージ
  | python2-podman         | A library to interact with a Podman server                            | パッケージ       
  | python3-podman         | A library to interact with a Podman server                            | パッケージ       
  | python3-podman-compose | A script to run docker-compose using podman                           | パッケージ  

上記は「podman」で検索してみた例です。(折り返してしまっているので見にくくてすみません。)

ちなみに、左端の「i」がインストールされているという意味で、「i+」は、ユーザーが選んでインストールしたパッケージ、という意味です。

目当てのパッケージが見つかったら、インストールは以下のコマンドです。

$ zypper in [インストールしたいパッケージ]

inはinstallの略です。フルでinstallとタイプしても大丈夫です。

そうすると、同時にインストールすることが推奨されるパッケージや利用予定ディスク容量などが表示され、インストールするかを聞かれますので、Y(Yes)で答えればインストールです。なお、root権限が必要ですので、一般ユーザーの場合はsudoで実行するなどしましょう。

Webサイトから1-clickインストール

openSUSEにはソフトウェアサイトがあり、コミュニティ作成のパッケージや、実験的なパッケージをインストールすることもできます。(もちろん、自己責任となりますのでご注意ください。)

ソフトウェアサイトのトップページ

左側でディストリビューションを選べますので、希望のものを選びます。今ですと、Leap15.1になるでしょう。それからパッケージ名を検索します。そうすると、各パッケージのページに行くことができます。

podmanのパッケージのページ

ここから「直接インストール」を選択します。

あるいは、下部に利用可能な各ディストリビューションのコミュニティ作成パッケージや実験的パッケージが表示されますので、希望のものをえらび「1-クリックインストール」をクリックします。

podmanのleap15.1のパッケージ例

追加のリポジトリが必要な場合は、それを設定するか確認されます。「ちゃんと、変更内容わかってる?」と、かなり念を押してくれます。

まとめ

どの方法でも、zypperで操作できるパッケージ管理の配下に入っていきます。ですので、WebサイトからインストールしたものをYaSTで確認、などもできます。気になるパッケージもこれで手に入りますね。なお、Webサイトからですと実験的なものなども見れますので、他の方法で見つからない場合は覗いてみるのもアリだと思います。(くどいようですが、自己責任ですので・・)

  • リポジトリとパッケージの関係をとりまとめてブログに書きたい
  • libzyppとzypperとYaSTの関係図を書けるようになりたい
  • なんなら、zypperのソースを読んでみたい

Geeko Magazine表紙のキャラクター壁紙

By Syuta Hashimoto @ 2019-08-04 14:12
  • 2019/08/04 画像サイズが小さかったのを、フルサイズに修正しました。
  • 携帯用をアップしました。
  • ※※画像はサムネイル表示になっています。フルサイズは「名前をつけてリンク先を保存」で保存してください。※※
  • ** IMPORTANT ** image is thumbnail. If you want to get this wall papers, you should download which linked to.

openSUSE mini Summit 2019でも、「欲しい!」とお声を頂いた、Geeko Magazine表紙に描かれたキャラクターの壁紙をアップします。

ぜひぜひ、ダウンロードしていただいて、デスクトップをかわいらしく飾ってください!

イラスト作成者からのコメント「携帯壁紙とか希望があれば、コメントいただければ作りますよー」

※2019/08/04 ご希望を頂いたので、携帯壁紙作成して頂きました。希望くださった方、イラスト作成者さん、ともにありがとうございます!

【デスクトップ用】

【携帯壁紙用】

橋本修太です

Geeko Magazineに書いていたのですが、ちょっと前、確かkubernetes 1.12の時は、flannel 1.10を適応しようとすると、エラーとなって適用出来ませんでした。

それが、flannelがバージョンアップして解決したようです。今では以下のコマンドでネットからflannelを適応する事が出来ます。

kubectl apply -f https://0y.at/kubicflannel

Kubicが適応できるバージョンにショートネームをあてたようですね。

インストールの全体記事はこちらです。

それでは良いコンテナライフを。

橋本修太です

さて、突然ですが、今私のKubernetes環境はこんな感じになっています。

KVMは仮想マシン、KubicはopenSUSEのKubernetes専用ディストリビューション、masterやnodeはKubernetesクラスタでの役割を表しています。

ルーターに有線でデスクトップが繋がっていて、そこに3つKubicを走らせています。

また、ルーターはWiFiルーターに繋がっていて、WiFiでノートパソコンと通信、そのノートパソコンの上にも3つKubicが走っています。

それをですね、こうしたいのです。

デスクトップのnodeを、ノートパソコンのKubernetesクラスタに組み込みたいのです。

ノートパソコンは、メモリは16G積んでいて少し余裕はあるものの、CPUはcore i5で、KVMをこれ以上増やすのは難しいです。

そこで、クラスタの利点を活かして、デスクトップからnodeを引っ張ってくるわけです。

とりあえずこれでできました

KVMはデフォルトで閉じたネットワーク(ホストの外側からは中にアクセス出来ないネットワーク)を作成します。ただ、これはNATなので、ゲストからホストの外側にはアクセス出来ますが・・・

そこで、色々とやってみた結果、次のような方法でホストの外からのアクセスが出来ました。

  • 【ノートPC】KVMでバーチャルネットワークを作成、マスカレードで接続
  • 【デスクトップPC】ブリッジを作成

検証や調査等はおいおいやっていくとして、それぞれの設定を書いてみたいと思います。

今回は【ノートPC】編、次回は【デスクトップPC編】です

WiFi接続しているノートPCにブリッジを作成することに挫折

グーグル先生に教えてもらって、いくつかの方法を試したりしたのですが、どれも挫折してしまいました・・・

どうやら、ブリッジはレイヤー2で転送するものらしいのですが、WiFiはレイヤー2転送に対応していないというのが、WiFiでのブリッジ作成が難しい理由の大きなところらしいです。・・・いまいちピンとこないので、後ほど詳しく調べてみたいと思います。

parproutedやebtablesなどでレイヤー2転送を設定する

parproutedはarpをプロキシするものとの事です。また、etablesはEthernetフレーム用iptablesとの事です。parproutedはopenSUSE Leap15で上手く動かせられなかったり、ebtablesが意図した通り設定出来なかったりして、挫折してしまいました。

バーチャルネットワークを作成

Facebookでそんな事をなげいていたら、Saputro Aryuliant氏より、「KVMのバーチャルネットワーク設定して、iptablesでマスカレード設定すればいけるよ」とのお助けが。

「ホストPCの外から、ゲストPCにアクセスできる?」と聞くと、「iptables設定すればいけるよ」とのことでしたので、早速試してみることに。

KVMの設定

ルーティングでネットワークを作成します。

設定はvirt-managerでこんな感じです。

編集 > 接続の詳細

から、「仮想ネットワーク」タブを選んで、左下のプラスのアイコンをクリックして追加します。

デバイスにwlan0(WiFi)、方法にルーティングを指定している所がポイントです。

これ、デフォルトのNATネットワークだとだめなのかな?

iptablesの設定

まず、ノートPCでipv4のフォワードを有効にします。

sudo sysctl -w net.ipv4.ip_forward=1

これは再起動するとクリアされてしまいますので、常に設定したい場合は /etc/sysctl.d/の中に、{好きな名前}.confという名前で設定ファイルを作成して、その中に記述しておけばOKです。

確認は以下のコマンドで。

sudo sysctl -a

設定項目が表示されますので、grep -i forwardとかで絞ると楽に確認できます。

それから、同じくノートPCにマスカレードを設定します。

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -j MASQUERADE

  • -t nat パケット中のIPアドレスを書き換える用のテーブルを編集
  • -A POSTROUTING 転送でパケットが出ていく時に処理を行う
  • -s ここで指定した所から来た(Source)パケットに対する処理
  • -j 指定した処理を行う 今回はマスカレード

これで、ノートPCの上で走らせているKVM上のKubicが、自由に外にアクセスできるようになりました。

ノートPCの上で走らせているKVMにデスクトップPCからアクセスする

とりあえず、アクセスしたいマシンやKVM上のKubicで、以下の設定を行いました。

ip -4 route add 192.168.100.0/24 via 192.168.0.12

192.168.100.0/24行きのパケットは、192.168.0.12(ノートPCのIPアドレス)をデフォルトゲートウェイにしてね、という設定です。

これで、デスクトップや、そこで走っているKVM上のKubicから、ノートPC上のKubicにアクセスできるようになりました。

・・・もちろん、デスクトップ上のKVMも、ブリッジ設定して、ホストの外へアクセスできるようにすれば、です。その様子はまた次回に。

感想&課題

  • ネットワークの基礎が無いのでちょっときつい
  • レイヤー2ルーティングでブリッジ作成は可能?
  • そもそもルーティングによる接続ってなんだろう
  • ホスト外からアクセスする方法がスマートでない
  • この辺りをもうちょっとまとめたい

橋本修太です。

例によって例のごとく、よくわからないけど動かなくなって、よくわからないままに手探りで解決したので、覚書を残させて頂きます。

現象

kubectlでdeploymentのyamlをapplyしても、DESIREDからCURRENTに移行しなくなった

要するに、新しいpod(Dockerで言うところのコンテナ)が動かなくなった、という事です。

原因

不明

直前に、nginx-ingress入れたりしていたんですけど、それでしょうか・・・・

解決方法

crictlで、Exitedなkube-controller-manager-****を削除したら、動き出しました。

手順

現象発生時、何かを調べたとは思うのですが、忘れてしまいました・・・とりあえずKubernetesを再起動させました。

NODEの削除(masterでの作業)

$ kubectl drain <node name> –delete-local-data –force –ignore-daemonsets
$ kubectl delete node <node name>

NODEの再起動(master含む各NODEでの作業)

$ kubeadm reset

$ reboot

いつもこの方法なんですけど、これでいいんでしょうか?

そして、いつもどおり起動していきます。

master起動

kubeadm init –cri-socket=/var/run/crio/crio.sock –pod-network-cidr=10.244.0.0/16

cp -i /etc/kubernetes/admin.conf ~/.kube/config

kubectl apply -f ./kube-flannel.yml

最後の、flannelのymlは、githubから落としてきたものです。詳細はGeeko Magazineをご覧ください。ただ、README.mdに書いてある、以下のコマンドでも正しく動きそうですね。flannelかな?と思って、こちらで試してみたのですが、動作は同じようでした。masterなので、いつどういう動作をするかは、保証されないのでしょうが・・・

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

そして、同じ現象に出くわします。nodeの状態を以下のコマンドで確認するのですが、

kubectl get nodes

ずっと、STATUSはNotReadyのまま。

kube-system(というnamespaceで配置される、システム系のpod)を確認します。

kubectl get pods –all-namespace

すると、kube-controller-manager-****(****は、マスターのマシン名)のSTATUSが、CreateContainerErrorとなったまま。

ふーむ・・・ここでグーグル先生に泣き付く事小一時間。こんな感じで辿りました。

ログ確認

journalctl

Kubicは、Kubernetes関係のログはほぼここに入っています。いるはずです。いると思っています。

すると、こんな感じのログが立て続けに出力されていました。

pod_workers.go:190] Error syncing pod
****************** (“kube-controller-manager-linux-riis_kube-system(*********************)”), skipping: failed to “StartContainer” for “kube-controller-manager” with CreateContainerError: “the
container name \”k8s_kube-controller-manager_kube-controller-manager-linux-riis_kube-system_********************_**\” is already in use by \”************************************
\”. You have to remove that container to be able to reuse that name.: that name is already in use”

******はマスクです。ランダム英数字が入っています。また、linux-riisが、masterのマシン名です。

podのログも確認してみましたが、同じようなログが出力されていました。(はずです・・・もしかしたら、コンテナを生成できなかった、程度だったかもしれません・・・)

kubectl logs pods/kube-controller-manager-****(マシン名) -n kube-system

-nオプションで、namespaceを指定しないと、見つからないと言われるので注意です。

ふむふむ、どうも、IDだかがかぶってしまって、新しいkube-controller-managerを起動できないようです。

ここでイメージとコンテナの確認です。Kubicはcri-oを使っているため、コンテナ関連のコマンドはcrictl、サービスはcrioになります。crictlのホームページはこちら。Dockerと似たような感じで使えるのではないでしょうか。ちなみに、このコマンドが入っているパッケージはcri-toolsです。

サービスステータスをチェックします。

systemctl status crio

CNIのデフォルトネットワークが見つからないよ、というエラーが見えますが、flannelを適応すれば直るでしょう・・・直ると信じたいです。(事実、直りました。)

では、コンテナの確認です。

crictl ps -a

すると、Runningとなっているものと、Exitedとなっているもの、2つのkube-controller-manager-****が。その他にも、kube-apiserver-****や、kube-scheduler-****も同じように、二種類。

Exitedとなっているものは不要なので(不要で終了したのでExitedなはずなので)、削除しましょう。

crictl rm ****(コンテナIDです。先のcrictl ps時に表示されます。)

そして、システム系のpodを確認。

kubectl get pods –all-namespaces

すると、なんと、kube-controller-manager-****が、Runningに変わっているではありませんか!

ただ、ちょっと待ってkubectl get nodesしても、NotReadyだったので、同じくExitedだった、kube-apiserver-****と、kube-scheduler-*****のコンテナも、削除しました。

そして待っていると・・・・無事、masterがReadyになりました。

後は、ワーカーNodeのkubeadm joinもすんなり動き、正常稼働に戻りました。

課題&感想

  • 情報収集の方法をもっと知りたい
  • crictl知ったのは良かった
  • Kubicの再インストールを考えたけど、粘ってみてよかった。(いつもこうとは限らない)
  • 正常時のログとかを認識していないと、異常時にあたりを付けにくい
  • ingressは、Kubic用があるっぽい
  • 今見てみたら、kube-schedulerとか、Exitedなのがあった・・・

この記事は openSUSE Advent Calendar の 20日目です。完走も見えてきました。

さて、今日は Twitter などでときどき質問が飛ぶ Google Chrome のインストール方法です。

openSUSE では Google Chrome の OSS 版である Chromium がパッケージとして提供されています。普通のウェブサイトを見る分にはこれでよいのですが、Flash Player が必須なウェブサイトや、DRM で保護された不自由なコンテンツを見るために、ときどき Chrome が欲しくなるときがあります。

それでは、インストール方法です。

(1) Google のリポジトリのGPG 公開鍵のインポート

Chrome のパッケージを署名している鍵の公開鍵をインポートします。この手順を飛ばすとパッケージの署名チェックでエラーになってしまいます。

こちらのページにも手順が書かれています:
https://www.google.com/linuxrepositories/

(2) Chrome をダウンロードする

ブラウザで Linux 用の Chrome のrpmファイル(Fedora/openSUSE用)をダウンロードします。

https://www.google.com/chrome/

※Windows などからダウンロードする場合は、画面の下部に「他のプラットフォーム」というリンクから Linux 版のダウンロード画面にたどり着けます。

(3) セットアップを実行する

ダウンロードした rpmファイルを zypper でインストールします。

おわりに

以上、Chrome のインストール方法でした。Amazon Prime などの動画配信サイトが見られないといったような場合は、Chrome を試してみて下さい。

明日は「openSUSEでディスクの健康状態を取得」です。