2018-05-10


 VMware ESXiやvCSAはログをsyslogとして出力する機能がある。
 ESXiのlog必要性は低いのだが、bug発生時の解析用途で取得しておくに越したことはない。ところで、ESXiは標準状態だとverboseなlogが大量に出力されるためsyslogが大量に発生してしまった。1日GB単位で増加するので流石に修正が必要である。

 先ずはVMwareのkb2000088を参照してログレベルを変更した。これでhostdとvpxaのログは変更できるのだが、rhttpporxyのログが非常に大量に出力され続けている。
 VMwareの有償サポートでは「変更方法は提供しておりません」との回答であったが、非公式情報ではあるものの、rhhtpproxyとfdmの変更も可能である。

 筆者の環境ではrhttpproxyのログが大量に発生しているため、これを修正した。

/etc/vmware/rhttpproxy/config.xml

 の

 <level>warning</level>

 の様に出力するレベルを変更すれば良い。
 Lenovo System x3550M5へVMware ESXi6.5U1 Lenovo customizedをインストール。2018/3時点のVMware提供updateを一式適用した環境があった。
 ESXiのタスクを見ると、1sec毎にdcuiのlogin,logoffが記録されている。

 Lenovoのサポートフォーラムでも類似の事象は報告されている(1)(2)のだが、Lenovoが組み込んだcronによるタスクは本来1分1回起動される筈。前述の様に1秒に1回以上の頻度では一瞬でタスク履歴とsyslogが溢れるし、運用上も支障がある。

 結論から書けば、LenovoのVMware用レポジトリをupdate managerへ追加し、2018/4頃追加されているLenovoのアップデートや2018/5頃追加されているVMware提供のsystem x用アップデートを適用したところ、1分に1回の頻度になった。


 LenovoのforumからlinkされていたIBMのsupportでは、Ethernet over USBを無効にしろ、とあったが効果はなかった。

Solution #1
1) attempt to disable the vusb0 interface first to confirm this is the source of the issue:
For a blade server:
1. Launch the IBM BladeCenter Advanced Management Module.
2. Go to Blade Tasks > Configuration> Information and Policy.
3. Select Advanced Blade Policy Settings.
4. Select Ethernet over USB.
5. Select the blade server where you want to disable the ethernet interface, then click Disable.
2) update the IMM firmware to current version

a) You may also be able to update the IBM CIM Providers via IBM Fix Central


 切り分けのため、crontabを編集してrefresh.shを起動しているcronの設定をコメントアウトすると、上記のlogon,logoffは止まった。但し、crontabを編集しても再起動すると無効になってしまうので、これ自体は恒久的な対応には出来なかった。
 バックアップを取得したところでraspbianをjessieからstretchへ更新してみる。基本はクリーンインストールとのことだが、sambaを再構築するのも非現実的なのでupgradeに挑戦。

 先人の記事を参考にしてみたが、手順で問題となる箇所は無し。

 raspberry pi 2で更新したのだが、途中で入力する箇所もあるので所要時間は一晩必要である。

 レポジトリ情報の更新は以下を実行。

sudo sed -i 's/jessie/stretch/g' /etc/apt/sources.list
sudo sed -i 's/jessie/stretch/g' /etc/apt/sources.list.d/raspi.list

 パッケージ情報の更新は以下を実行。

sudo apt-get update

 アップグレードは以下を実行。
 この際、「設定ファイルをそのまま残すか、新しい物で上書きするか」と数回質問が発生した。標準は「設定ファイルをそのまま残す」となっているので、随時enterを入力。
 また、「サービスを再起動しても良いか」は標準が「no」なので「yes」を選択。

 ログを眺めていると、パッケージの依存性で警告が数回表示されていたが、特段問題は無い様だ。


sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade
sudo reboot

---
設定ファイル '/etc/ntp.conf'
 ==> これはインストールしてから (あなたかスクリプトによって) 変更されています。
 ==> パッケージ配布元が更新版を提供しています。
   どうしますか? 以下の選択肢があります:
    Y か I  : パッケージメンテナのバージョンをインストールする
    N か O  : 現在インストールされている自分のバージョンを残す
      D     : 両バージョンの差異を表示する
      Z     : 状況を調査するためにシェルを開始する
 デフォルトでは現在使っている自分のバージョンを残します。
*** ntp.conf (Y/I/N/O/D/Z) [デフォルト=N] ? n
---


 最後に不要なパッケージを削除。以下を実行。

sudo apt-get --purge -y autoremove 

2018-05-05

 無事回復したraspberry piであるが、再度おかしくなると怖いのでバックアップを取得する。
 今まではSDカードを抜いてmacでSDカードの中身を.img形式に取得してきたのだが、時間が掛かることと、バックアップを書き戻す先のSDカードは容量がオリジナルと完全に等しいか大きいものとする必要があった。各所に書かれている通り16GBのSDカードと称していても微妙に容量が異なるのである。

 調べたところ、rpi-cloneが便利そうである。これはCLIで動作するのでjessie liteに適合する。

 git hubで公開されているので、先ずはgitを導入する。


pi@raspberrypi1:~ $ sudo apt-get install git
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
  git-man libcurl3-gnutls liberror-perl
(中略)
git-man (1:2.1.4-2.1+deb8u5) を設定しています ...
git (1:2.1.4-2.1+deb8u5) を設定しています ...
libc-bin (2.19-18+deb8u10) のトリガを処理しています ...

 導入後、rpi-cloneを導入する。

pi@raspberrypi1:~ $ sudo git clone https://github.com/billw2/rpi-clone.git
Cloning into 'rpi-clone'...
remote: Counting objects: 158, done.
remote: Total 158 (delta 0), reused 0 (delta 0), pack-reused 158
Receiving objects: 100% (158/158), 75.04 KiB | 0 bytes/s, done.
Resolving deltas: 100% (59/59), done.
Checking connectivity... done.

 導入後、一式を/usr/local/sbin以下にcopyする。

pi@raspberrypi1:~ $ ls
rpi-clone
pi@raspberrypi1:~/rpi-clone $ sudo cp rpi-clone /usr/local/sbin
pi@raspberrypi1:~/rpi-clone $ type rpi-clone
rpi-clone は /usr/local/sbin/rpi-clone です

 SDカードリーダにSDカードを挿入後、raspberry piへUSB接続。認識されているかを確認。認識されていない場合は再接続してみる。

pi@raspberrypi1:~/rpi-clone $ lsusb
Bus 001 Device 004: ID 0411:0259 BUFFALO INC. (formerly MelCo., Inc.)
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 マッピングを確認する。/dev/sdcとして認識された。

pi@raspberrypi1:~/rpi-clone $ sudo fdisk -l

Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
(中略)
Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1        8192   137215   129024   63M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      137216 31116287 30979072 14.8G 83 Linux

Disk /dev/sdc: 14.5 GiB, 15552479232 bytes, 30375936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdc1        8192 30375935 30367744 14.5G  c W95 FAT32 (LBA)

 認識された/dev/sdcへ書き込みをする。
 途中でext4のパーティションの名前をどうするか?と質問されるが、元々付与されていないので、そのままenterで続行して良い。
 完了したら、shutdown後、SDカードを入れ替えて起動してみる。


root@raspberrypi1:/home/pi/rpi-clone#  rpi-clone sdc --force-initialize

Booted disk: mmcblk0 15.9GB                Destination disk: sdc 15.6GB
---------------------------------------------------------------------------
Part      Size    FS     Label           Part   Size    FS  Label
1 /boot   66.0MB  fat16  --              1      15.5GB  --  --
2 root    15.9GB  ext4   --
---------------------------------------------------------------------------
== Initialize: IMAGE mmcblk0 partition table to sdc - forced by option ==
1 /boot               (23.6MB used)  : IMAGE     to sdc1  FSCK
2 root                (6.5GB used)   : RESIZE(15.5GB) MKFS SYNC to sdc2
---------------------------------------------------------------------------
Run setup script       : no
Verbose mode           : no
-----------------------:
** WARNING **          : All destination disk sdc data will be overwritten!
                       :   The partition structure will be imaged from mmcblk0.
-----------------------:

Initialize and clone to the destination disk sdc?  (yes/no): y
Optional destination  ext type file system label (16 chars max):

Initializing
  Imaging past the start of /boot partition 2.
  => dd if=/dev/mmcblk0 of=/dev/sdc bs=1M count=71 ...
  Resizing last partition to end of disk ...
    Resize success.
  Changing destination Disk ID ...
  Delaying so partprobe can update /dev entries ...
  => fsck -p /dev/sdc1 ...
  => mkfs -t ext4  /dev/sdc2 ...

Syncing file systems (can take a long time)
Syncing mounted partitions:
  Mounting /dev/sdc2 on /mnt/clone
  => rsync // /mnt/clone with-root-excludes ...
  Mounting /dev/sdc1 on /mnt/clone/boot
  => rsync /boot/ /mnt/clone/boot  ...

===============================
Done with clone to /dev/sdc
   Start - 08:34:08    End - 09:15:01    Elapsed Time - 40:53

Cloned partitions are mounted on /mnt/clone for inspection or customizing.

Hit Enter when ready to unmount the /dev/sdc partitions ...
  unmounting /mnt/clone/boot
  unmounting /mnt/clone
===============================


2018-05-04

 raspberry piのjessieでapt-getが急に動作しなくなった。

root@raspberrypi2:/home/pi# apt-get
apt-get: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libapt-private.so.0.0: undefined symbol: _ZN3APT6String8EndswithERKSsS2_

 さっぱり判らないので色々検索してみたが、apt-getをdpkgで再導入すれば良さそうである。
 先ずはaptのパッケージを再入手。

root@raspberrypi2:/home/pi# wget https://archive.raspbian.org/raspbian/pool/main/a/apt/apt_1.0.9.8.4_armhf.deb

 その後、再導入してみたが、依存関係でエラーになってしまった。

root@raspberrypi2:/home/pi# dpkg -i apt_1.0.9.8.4_armhf.deb
(データベースを読み込んでいます ... 現在 34855 個のファイルとディレクトリがインストールされています。)
apt_1.0.9.8.4_armhf.deb を展開する準備をしています ...
apt (1.0.9.8.4) で (1.0.9.8.4 に) 上書き展開しています ...
dpkg: 依存関係の問題により apt の設定ができません:
 apt は以下に依存 (depends) します: libapt-pkg4.12 (>= 1.0.9.8.4) ...しかし:
  システム上の libapt-pkg4.12:armhf のバージョンは 0.9.7.9+rpi1+deb7u7 です。

dpkg: パッケージ apt の処理中にエラーが発生しました (--install):
 依存関係の問題 - 設定を見送ります
man-db (2.7.5-1~bpo8+1) のトリガを処理しています ...
処理中にエラーが発生しました:
 apt


 どうもlibapt-pkgが宜しく無い様子。これも再取得して再導入。
 その後、再度aptを導入したところ、正常に動作した。

root@raspberrypi2:/home/pi# wget http://ftp.us.debian.org/debian/pool/main/a/apt/libapt-pkg4.12_1.0.9.8.4_armhf.deb
--2018-05-04 22:23:22--  http://ftp.us.debian.org/debian/pool/main/a/apt/libapt-pkg4.12_1.0.9.8.4_armhf.deb
ftp.us.debian.org (ftp.us.debian.org) をDNSに問いあわせています... 208.80.154.15, 128.30.2.26, 128.61.240.89
ftp.us.debian.org (ftp.us.debian.org)|208.80.154.15|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK

root@raspberrypi2:/home/pi# dpkg -i libapt-pkg4.12_1.0.9.8.4_armhf.deb
(データベースを読み込んでいます ... 現在 34855 個のファイルとディレクトリがインストールされています。)
libapt-pkg4.12_1.0.9.8.4_armhf.deb を展開する準備をしています ...
libapt-pkg4.12:armhf (1.0.9.8.4) で (0.9.7.9+rpi1+deb7u7 に) 上書き展開しています ...
libapt-pkg4.12:armhf (1.0.9.8.4) を設定しています ...
libc-bin (2.19-18+deb8u10) のトリガを処理しています ...
root@raspberrypi2:/home/pi# dpkg -i apt_1.0.9.8.4_armhf.deb
(データベースを読み込んでいます ... 現在 34856 個のファイルとディレクトリがインストールされています。)
apt_1.0.9.8.4_armhf.deb を展開する準備をしています ...
apt (1.0.9.8.4) で (1.0.9.8.4 に) 上書き展開しています ...
apt (1.0.9.8.4) を設定しています ...
man-db (2.7.5-1~bpo8+1) のトリガを処理しています ...
libc-bin (2.19-18+deb8u10) のトリガを処理しています ...


 取り敢えずこれで稼働するようになったのだが、対処として正しいかは不明。

2018-04-07

 仕事でHP MAS2040とLenovo DS4200のEntry Storageを構築することがあったのだが、これらは自社製造ではなく、同じOEM元からの供給と思われる。というのはそれぞれのWeb managementの構成は同一であったから。加えてdefaultの管理者ID/Passwordもmanage/!manageと同一である。

 よく観察すると、微妙に仕様が異なる。例えばHDDユニットの奥行きが異なり、両製品でHDDやSDDは共用できない。それなりにOEMによる味付けは存在している。

 とは言え基本的な構成や出来る事は一緒である。両社とも販売店向けにコンペとの比較資料が用意されているが、上記の様な微妙な差異については触れているが根本的には同一製品であることは触れていない。公然の秘密、呉越同舟という事なのだろうか?

2018-04-05

 vCSAは自身のアップデート機能があり便利なのだが、何故かアップデート出来ない問題がある。

 vCSAのアップデートはhttpsでインターネット上のレポジトリを確認して最新版をダウンロードする構造になっている。インターネット接続に使用するプロキシはGUIで設定する。ところが設定すると何故かhttp使用時のみの設定となり、https使用時は設定されない。

 対応策は、手動でhttpsプロキシを設定する。具体的にはvCSAへsshで接続し/etc/sysconfig/proxyにhttps proxyを記述する。一般的にはhttp、https共に同一のプロキシを利用しているので、同一の設定を記述する。

自己紹介

自分の写真
東京都, Japan
憂鬱な凍死家です。こちらではmixiとは異なり固めの話題中心です。

Total Page View

Categories

Powered by Blogger.

Popular Posts

Blog Archive