CentOS LXDコンテナのデフォルトユーザー名は?

CentOSコンテナで実験をしています。LXDコンテナを選んだ理由は、まずLXDコンテナを使ったことがなかったこと、そしてCentOSの「公式」Dockerイメージが見当たらなかったからです(存在はしますが非推奨になっていました)。LXDコンテナはContainer Stationのデフォルトアプリケーションテンプレートにありました。

ですが、CentOSのデフォルトのユーザー名とパスワードは何でしょうか?どこにもその設定がありません。そのため、Linuxシェルは利用できるのですが、ログインできません。

Hi @NA9D

これがあなたが直面している問題だと思いますか?

実際には、右上の「Execute」ボタンをクリックすると、CentOSコンソールにアクセスできます。

また、このコンソールで「passwd」コマンドを使ってパスワードを変更することもできます。

ありがとうございます。うまくいきました。

ここからが本題なのですが、もしかしたら助けていただけるかもしれません。

Linuxシステムインストールのマウントポイントデバイスを探そうとしています。なぜかというと、実際にはこれを別のソフトウェアで上書きして、コンテナ内で動作させたいからです。しかし、OSが実際にどこに保存されているのか見つけられません。

lsblk コマンドはすべてのボリュームとそのマウントポイントを表示します。しかし、これを実行するとNAS全体のボリュームが表示されてしまい(これは望んでいません)、ルート「/」のマウントポイントがありません:

[root@centos-1 ~]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0         7:0    0    64M  1 loop  
sda           8:0    0   1.8T  0 disk  
├─sda1        8:1    0 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─sda2        8:2    0 517.7M  0 part  
├─sda3        8:3    0   1.8T  0 part  
├─sda4        8:4    0 526.6M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─sda5        8:5    0  31.5G  0 part  
  └─md322     9:322  0  30.4G  0 raid1 [SWAP]
sdb           8:16   0   1.8T  0 disk  
├─sdb1        8:17   0 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─sdb2        8:18   0 517.7M  0 part  
├─sdb3        8:19   0   1.8T  0 part  
├─sdb4        8:20   0 526.6M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─sdb5        8:21   0  31.5G  0 part  
  └─md322     9:322  0  30.4G  0 raid1 [SWAP]
sdc           8:32   0   9.1T  0 disk  
├─sdc1        8:33   0 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─sdc2        8:34   0 517.7M  0 part  
├─sdc3        8:35   0   9.1T  0 part  
├─sdc4        8:36   0 526.8M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─sdc5        8:37   0  31.5G  0 part  
  └─md322     9:322  0  30.4G  0 raid1 [SWAP]
sdd           8:48   0   9.1T  0 disk  
├─sdd1        8:49   0 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─sdd2        8:50   0 517.7M  0 part  
├─sdd3        8:51   0   9.1T  0 part  
├─sdd4        8:52   0 526.8M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─sdd5        8:53   0  31.5G  0 part  
  └─md322     9:322  0  30.4G  0 raid1 [SWAP]
sde           8:64   0   9.1T  0 disk  
├─sde1        8:65   0 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─sde2        8:66   0 517.7M  0 part  
├─sde3        8:67   0   9.1T  0 part  
├─sde4        8:68   0 526.8M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─sde5        8:69   0  31.5G  0 part  
  └─md322     9:322  0  30.4G  0 raid1 [SWAP]
sdf           8:80   0   9.1T  0 disk  
├─sdf1        8:81   0 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─sdf2        8:82   0 517.7M  0 part  
├─sdf3        8:83   0   9.1T  0 part  
├─sdf4        8:84   0 526.8M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─sdf5        8:85   0  31.5G  0 part  
  └─md322     9:322  0  30.4G  0 raid1 [SWAP]
sdg           8:96   1   1.8T  0 disk  
├─sdg1        8:97   1 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─sdg2        8:98   1 517.7M  0 part  
├─sdg3        8:99   1   1.8T  0 part  
├─sdg4        8:100  1 526.6M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─sdg5        8:101  1  31.5G  0 part  
  └─md322     9:322  0  30.4G  0 raid1 [SWAP]
sdh           8:112  1 931.5G  0 disk  
├─sdh1        8:113  1 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─sdh2        8:114  1 517.7M  0 part  
├─sdh3        8:115  1   898G  0 part  
├─sdh4        8:116  1 526.2M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─sdh5        8:117  1  31.5G  0 part  
  └─md322     9:322  0  30.4G  0 raid1 [SWAP]
sdi           8:128  0 372.6G  0 disk  
├─sdi1        8:129  0   200M  0 part  
└─sdi2        8:130  0 372.3G  0 part  
sdj           8:144  1   4.6G  0 disk  
├─sdj1        8:145  1   5.1M  0 part  
├─sdj2        8:146  1 488.4M  0 part  
├─sdj3        8:147  1 488.4M  0 part  
├─sdj4        8:148  1     1K  0 part  
├─sdj5        8:149  1   8.1M  0 part  
├─sdj6        8:150  1   8.5M  0 part  
└─sdj7        8:151  1   2.7G  0 part  
sdk           8:160  0  10.9T  0 disk  
└─sdk1        8:161  0  10.9T  0 part  
sdl           8:176  0   1.8T  0 disk  
└─sdl1        8:177  0   1.8T  0 part  
nbd0         43:0    0     0B  0 disk  
nbd1         43:32   0     0B  0 disk  
nbd2         43:64   0     0B  0 disk  
nbd3         43:96   0     0B  0 disk  
nbd4         43:128  0     0B  0 disk  
nbd5         43:160  0     0B  0 disk  
nbd6         43:192  0     0B  0 disk  
nbd7         43:224  0     0B  0 disk  
fbsnap0     250:0    0     0B  0 disk  
fbsnap1     250:1    0     0B  0 disk  
fbsnap2     250:2    0     0B  0 disk  
fbsnap3     250:3    0     0B  0 disk  
fbsnap4     250:4    0     0B  0 disk  
fbsnap5     250:5    0     0B  0 disk  
fbsnap6     250:6    0     0B  0 disk  
fbsnap7     250:7    0     0B  0 disk  
fbdisk0     251:0    0     0B  0 disk  
fbdisk1     251:1    0     0B  0 disk  
fbdisk2     251:2    0     0B  0 disk  
fbdisk3     251:3    0     0B  0 disk  
fbdisk4     251:4    0     0B  0 disk  
fbdisk5     251:5    0     0B  0 disk  
fbdisk6     251:6    0     0B  0 disk  
fbdisk7     251:7    0     0B  0 disk  
nvme1n1     259:0    0   1.8T  0 disk  
├─nvme1n1p1 259:1    0 517.7M  0 part  
│ └─md9       9:9    0 517.6M  0 raid1 
├─nvme1n1p2 259:2    0 517.7M  0 part  
├─nvme1n1p3 259:3    0   1.8T  0 part  
├─nvme1n1p4 259:4    0 526.6M  0 part  
│ └─md13      9:13   0 448.1M  0 raid1 
└─nvme1n1p5 259:5    0  31.5G  0 part  
  └─md321     9:321  0  30.4G  0 raid1 [SWAP]
nvme0n1     259:6    0   1.8T  0 disk  [root@centos-1 ~]#

さらに、Alpineコンテナ内ではマウントポイントを見つけることができました。新しいソフトウェアをコピーして、echo "b" > /proc/sysrq-trigger コマンドを実行し、これでLinuxインスタンスがコンテナ内で再起動することを期待しました。ところが、NAS全体が再起動してしまいました。これは非常に問題で、コンテナが思ったほど分離されていないことが明らかです。結局、私の試みはうまくいかず、Alpineインストールは何事もなかったかのように再起動しました…

これらのLinuxシェルがNAS全体を露出していることに懸念を感じています。

あ、メッセージを見逃していました。

「–privileged」設定を有効にしましたか?「NAS全体が再起動した」と言っていたので、それが原因だと思います。

Alpineでは、常に特権モードだと思います。

そして、いずれにせよ、コンテナの再起動を試みてもNAS自体が再起動されることは絶対にあってはなりません。

また、特権モードはコンテナ内でrootユーザーを有効にするはずですが、その場合にコンテナからNASにrootアクセスできるかどうかは疑問です。NASのファイルシステムへのアクセスは、指定されたマッピングストレージのみで許可されるべきです。それがコンテナの本来の目的です。

特権モードを有効にしていない場合、Container Station内でDockerやその他の類似プログラムを実行してコマンドを実行しても、QNAP QTSシステムが再起動することはありません。これは私自身のテストで確認済みです。

先ほどご指摘の状況は、特権モードを有効にしたことが原因である可能性が高いです。これらはすべてDockerの技術と設計の一部であり、通常のサーバーでのデプロイと挙動を比較することもできます。