カテゴリー: 技術系

  • Bitnami Redmine バージョンアップ後、ファイルを添付すると「500 Internal Server Error」になる。

    Bitnami Redmineを3.4にバージョンアップした後、ファイルを添付すると、「500 Internal Server Error」が発生する。 production.logを確認したところ、下記のエラーが発生していた。

    ActiveRecord::StatementInvalid (Mysql2::Error: Data too long for column 'digest' at row 1: INSERT INTO `attachments` (`filesize`, `author_id`, `filename`, `content_type`, `created_on`, `disk_directory`, `disk_filename`, `digest`) VALUES (3219456, 51, 'xxxxxxxxxxxxxxxxxxxxx.xls', 'application/vnd.ms-excel', '2019-01-22 13:32:06', '2019/01', '190122133206_888b6d3922b1328bb95a9axxxxxxxxx.xls', '7f983175713489027c14d233d23098f3daf8162a91a1a0e169f0e64xxxxxxxxxx')):
      app/controllers/attachments_controller.rb:97:in `upload'
      lib/redmine/sudo_mode.rb:63:in `sudo_mode'
    

    ファイルのアップロードはエラーになっておらず、DBへの書き込み(INSERT)でエラーになっていた。MySQLのテーブルの定義を調べると、「digest」の型が「varchar(30)」で、実際に書き込みを行っているのは、64文字であることが判明。もともと、ファイルのハッシュ値(チェックサム)をMD5でやっていたものが、バージョンアップのタイミングで、SHA256になり、テーブルの定義がアップデートされていなかったのが、原因だった。

    「digest」カラムをSHA256のハッシュ値を保存できるようにするため、テーブル定義を下記のAlter文で更新した。

    alter table attachment modify digest varchar(64);
    

    更新後は、無事にRedmineにファイル添付できるようになった。

  • 仮想マシン名が日本語のとき、エクスポートした仮想マシンをデプロイできない

    仮想マシン名が日本語のとき(正確にはASCII文字列以外)、VMware ESXiから、OVFファイル形式でエクスポートした仮想マシンを新しい環境でデプロイ(インポート)しようとしても、エラーになり、デプロイできない。

    ASCII文字列以外のとき、ACSIIから8ビットのUTFに変換するときに変な動作になってしまうとのこと。

    “This issue is caused by the ASCII to 8-bit Unicode Transformation Format (UTF-8) string conversion. If any of these fields contain a non-standard US-English ASCII character it can cause unexpected behavior to occur: ”

    http://kb.vmware.com/kb/1003866

    解決策としては、エクスポート時に「名前」の部分で日本語を含む仮想マシン名だった場合は、半角英数字のみの名前に変更する。これで、エクスポートされるフォルダおよびファイル名は、半角英数字になるので回避可能。

    もとの日本語の名前にしたいときは、デプロイ時(インポート時)に名前を付けることで対応できる。

  • vCenterServer6.7のアップデートを行ったところ、vCenterが503エラーでアクセスできない

    vCenterServer6.7のアップデートを行ったところ、vCenterが503エラーでアクセスできないという状態になった。その対処を行ったときのメモ。

    発生したエラー

    503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http20NamedPipeServiceSpecE:0x0000559b11f64ba0] _serverNamespace = / action = Allow _pipeName =/var/run/vmware/vpxd-webserver-pipe)
    

    いろいろと調べたところ、「vmware-vpxd」を起動すれば、よさそうなので、vCenter ServerのShellで下記のコマンドを使い、起動してみる。

    service-control --start vmware-vpxd
    

    そうすると、今度は下記のエラーが発生。

    root@vcenter67 [ ~ ]# service-control --start vmware-vpxd
    Operation not cancellable. Please wait for it to finish...
    Performing start operation on service vpxd...
    Error executing start on service vpxd. Details {
        "detail": [
            {
                "args": [
                    "vpxd"
                ],
                "localized": "An error occurred while starting service 'vpxd'",
                "id": "install.ciscommon.service.failstart",
                "translatable": "An error occurred while starting service '%(0)s'"
            }
        ],
        "problemId": null,
        "componentKey": null,
        "resolution": null
    }
    Service-control failed. Error: {
        "detail": [
            {
                "args": [
                    "vpxd"
                ],
                "localized": "An error occurred while starting service 'vpxd'",
                "id": "install.ciscommon.service.failstart",
                "translatable": "An error occurred while starting service '%(0)s'"
            }
        ],
        "problemId": null,
        "componentKey": null,
        "resolution": null
    }
    root@vcenter67 [ ~ ]#
    

    結局、エラーで起動しない。エラーの内容から、下記のURLを参考にして対処を行う。

    https://kb.vmware.com/s/article/2149010

    Shellを立ち上げて、サービスをすべて止める

    service-control --stop --all
    

    次にvCenterのリストアコマンドを実施する。

    vcenter-restore -u administrator -p 
    

    このコマンドを実施したところで、再度エラーになる。コマンドが正常に実行できない。

    結論としては、vCenter Server Applianceを作ったばかりだったこともあり、再度、デプロイというか再作成を実施した。設定しているときから、挙動で怪しいところはあったので、強引に進めるよりかは再作成を選んだ。

    再作成後は、同じようにvCenterのアップデートを実施したが、正常に起動した(503エラーは表示されず)。 原因を振り返ってみると、次のどちらかが原因になっている可能性が高い。

    • vCenter Server Applianceのインストール時に、ホスト名をデフォルトのままでデプロイし、そのホスト名ではアクセスできないので、ホスト名を変更した。そのとき、なかなか変更できず、何回か変更を行った。
    • vCenter Server Applianceでアップデート後、サービスをみたときに、起動中のものがいくつかあり、「vCenter Server」のサービスが起動していなかったので、手動で起動させエラーになった。そのため、OSごと再起動を行った。(多分、設定は続いていたので、少しの時間待てばよかったのかもしれない。デプロイのやり直し後は、アップデート後も30分程度の時間をおいておいたところ、あとから「vCenter Server」のサービスが起動した)
  • V2VでVMを新しいESXi上に持って行ったところ、LinuxのEth1が有効にならない

    仮想マシン(VM)をV2VでESXi 5.1から、ESXi 6.7に移行したところ、ネットワークに接続されてなかった。 ifconfigでIPアドレスとインターフェースの状況を確認したが、IPアドレスは表示されなかった。

    service network restart” でネットワークインターフェースを再起動したところ、下記のエラーを含む内容が表示された。

    Device eth1 has different MAC address than expected, ingoring
    

    デバイスのMacアドレスが異なるということなので、「/etc/sysconfig/network-script/ifcfg-eth1」を編集し、 「HWADDR=」の行を新しくESXiで割り当てられているMACアドレスで書き換える。 今回は、Eth1だったが、実際の環境に合わせて、Eth0などに読み替える。

    編集後、下記のコマンドでネットワークインターフェースを再起動する。

    service network restart
    

    無事にEth1が起動し、ネットワーク接続ができるようになった。

  • vCenter Server 6.7 のインストーラを実行したが起動しない

    Ubuntu 18.04 でvCenter Server 6.7 をインストールするために、インストーラをダブルクリックしたが、起動しない。 パスの問題かもしれないので、ターミナルからインストーラを起動させてみたところ、下記のエラーが表示された。

    zen@vCenterServer67:/media/zen/VMware VCSA/vcsa-ui-installer/lin64$ ./installer
    ./installer: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
    

    インストールに必要な「libgconf2-4」がUbuntu上にインストールされておらず、起動しないようだ。 なので、aptを使ってインストールする。

    念のため、パッケージがあるかどうかを確認してから、インストール。

    apt search libgconf2
    sudo apt install libgconf2-4
    

    正常にlibgconf2-4がインストールされた後に、vCenter Serverのインストーラを起動させたところ、正常にGUIが立ち上がった。

    インストールログ

    zen@vCenterServer67:~$ apt search libgconf2
    ソート中... 完了
    全文検索... 完了  
    libgconf2-4/bionic 3.2.6-4ubuntu1 amd64
      GNOME 設定データベースシステム (ダミーパッケージ)
    
    libgconf2-dev/bionic 3.2.6-4ubuntu1 amd64
      GNOME configuration database system (development)
    
    libgconf2-doc/bionic,bionic 3.2.6-4ubuntu1 all
      GNOME configuration database system (API reference)
    
    libgconf2.0-cil/bionic,bionic 2.24.2-4 all
      GConf 2.24 の CLI バインディング
    
    libgconf2.0-cil-dev/bionic,bionic 2.24.2-4 all
      GConf 2.24 の CLI バインディング
    
    zen@vCenterServer67:~$ 
    zen@vCenterServer67:~$ 
    zen@vCenterServer67:~$ sudo apt install libgconf2-4
    [sudo] zen のパスワード: 
    パッケージリストを読み込んでいます... 完了
    依存関係ツリーを作成しています                
    状態情報を読み取っています... 完了
    以下の追加パッケージがインストールされます:
      gconf-service gconf-service-backend gconf2-common libgconf-2-4
    以下のパッケージが新たにインストールされます:
      gconf-service gconf-service-backend gconf2-common libgconf-2-4 libgconf2-4
    アップグレード: 0 個、新規インストール: 5 個、削除: 0 個、保留: 0 個。
    847 kB のアーカイブを取得する必要があります。
    この操作後に追加で 8,422 kB のディスク容量が消費されます。
    続行しますか? [Y/n] Y
    取得:1 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 gconf2-common all 3.2.6-4ubuntu1 [700 kB]
    取得:2 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 libgconf-2-4 amd64 3.2.6-4ubuntu1 [84.8 kB]
    取得:3 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 gconf-service-backend amd64 3.2.6-4ubuntu1 [58.1 kB]
    取得:4 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 gconf-service amd64 3.2.6-4ubuntu1 [2,036 B]
    取得:5 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 libgconf2-4 amd64 3.2.6-4ubuntu1 [2,044 B]
    847 kB を 0秒 で取得しました (3,314 kB/s)
    以前に未選択のパッケージ gconf2-common を選択しています。
    (データベースを読み込んでいます ... 現在 171039 個のファイルとディレクトリがインストールされています。)
    .../gconf2-common_3.2.6-4ubuntu1_all.deb を展開する準備をしています ...
    gconf2-common (3.2.6-4ubuntu1) を展開しています...
    以前に未選択のパッケージ libgconf-2-4:amd64 を選択しています。
    .../libgconf-2-4_3.2.6-4ubuntu1_amd64.deb を展開する準備をしています ...
    libgconf-2-4:amd64 (3.2.6-4ubuntu1) を展開しています...
    以前に未選択のパッケージ gconf-service-backend を選択しています。
    .../gconf-service-backend_3.2.6-4ubuntu1_amd64.deb を展開する準備をしています ...
    gconf-service-backend (3.2.6-4ubuntu1) を展開しています...
    以前に未選択のパッケージ gconf-service を選択しています。
    .../gconf-service_3.2.6-4ubuntu1_amd64.deb を展開する準備をしています ...
    gconf-service (3.2.6-4ubuntu1) を展開しています...
    以前に未選択のパッケージ libgconf2-4:amd64 を選択しています。
    .../libgconf2-4_3.2.6-4ubuntu1_amd64.deb を展開する準備をしています ...
    libgconf2-4:amd64 (3.2.6-4ubuntu1) を展開しています...
    gconf2-common (3.2.6-4ubuntu1) を設定しています ...
    
    Creating config file /etc/gconf/2/path with new version
    libgconf-2-4:amd64 (3.2.6-4ubuntu1) を設定しています ...
    libc-bin (2.27-3ubuntu1) のトリガを処理しています ...
    gconf-service (3.2.6-4ubuntu1) を設定しています ...
    gconf-service-backend (3.2.6-4ubuntu1) を設定しています ...
    libgconf2-4:amd64 (3.2.6-4ubuntu1) を設定しています ...
    zen@vCenterServer67:~$
    
  • UbuntuにWindowsからRDPで接続する

    Linuxにアクセスするとき、通常はCLIで事足りるのでsshdの設定だけでよいのだが、いろいろとインストールするのに、GUIを使いたかった。Ubuntu(18.04 LTS)のデスクトップにリモートアクセスするときに、いろいろと調べていたら、xrdpを使えば、Windowsのリモートデスクトップクライアント(mstsc.exe)でアクセスできるとのこと。

    そんなわけで、xrdpをインストールして、設定してみた。

    xrdpをインストール

    ~$ sudo apt install xrdp
    

    次に、xrdpの設定を変更。「new_cursors」の設定を無効化する。そして、サービスを再起動。

    ~$ sudo sed -e 's/^new_cursors=true/new_cursors=false/g' -i /etc/xrdp/xrdp.ini
    ~$ sudo systemctl restart xrdp
    

    「.xsessionrc」を作成する。これは、参考にしたページで紹介されていたものをまるっと流用。

    ~$  D=/usr/share/ubuntu:/usr/local/share:/usr/share:/var/lib/snapd/desktop
    ~$ cat < ~/.xsessionrc
    > export GNOME_SHELL_SESSION_MODE=ubuntu
    > export XDG_CURRENT_DESKTOP=ubuntu:GNOME
    > export XDG_DATA_DIRS=${D}
    > export XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
    > EOF
    

    Authentication Requiredの回避設定を行う。これをやらないとダメだった(先人は偉大)。 「/etc/polkit-1/localauthority/50-local.d/xrdp-color-manager.pkla」の設定を変更する。

    ~$ sudo cat /etc/polkit-1/localauthority/50-local.d/xrdp-color-manager.pkla
    [Netowrkmanager]
    Identity=unix-user:*
    Action=org.freedesktop.color-manager.create-device
    ResultAny=no
    ResultInactive=no
    ResultActive=yes
    

    polkitのサービスを再起動する。

    sudo systemctl restart polkit
    

    Windowsからリモートデスクトップクライアントで接続する。

    参考: https://www.hiroom2.com/2018/04/28/ubuntu-1804-xrdp-gnome-ja/

    インストールしたときのログ

    zen@ubClient:~$
    zen@ubClient:~$ apt search xrdp
    ソート中... 完了
    全文検索... 完了
    xorgxrdp/bionic 0.9.5-2 amd64
      Remote Desktop Protocol (RDP) modules for X.org
    
    xrdp/bionic 0.9.5-2 amd64
      Remote Desktop Protocol (RDP) server
    
    xrdp-pulseaudio-installer/bionic 0.9.5-2 amd64
      Remote Desktop Protocol (RDP) server - PulseAudio module installer
    
    zen@ubClient:~$
    zen@ubClient:~$
    zen@ubClient:~$
    zen@ubClient:~$
    zen@ubClient:~$
    zen@ubClient:~$ sudo apt install xrdp
    [sudo] zen のパスワード:
    パッケージリストを読み込んでいます... 完了
    依存関係ツリーを作成しています
    状態情報を読み取っています... 完了
    以下の追加パッケージがインストールされます:
      xorgxrdp
    提案パッケージ:
      guacamole xrdp-pulseaudio-installer
    以下のパッケージが新たにインストールされます:
      xorgxrdp xrdp
    アップグレード: 0 個、新規インストール: 2 個、削除: 0 個、保留: 0 個。
    498 kB のアーカイブを取得する必要があります。
    この操作後に追加で 3,303 kB のディスク容量が消費されます。
    続行しますか? [Y/n] Y
    取得:1 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 xorgxrdp amd64 0.9.5-2 [78.7 kB] 
    取得:2 http://jp.archive.ubuntu.com/ubuntu bionic/universe amd64 xrdp amd64 0.9.5-2 [419 kB]
    498 kB を 0秒 で取得しました (3,298 kB/s)
    以前に未選択のパッケージ xorgxrdp を選択しています。
    (データベースを読み込んでいます ... 現在 170920 個のファイルとディレクトリがインストールされています。)
    .../xorgxrdp_0.9.5-2_amd64.deb を展開する準備をしています ...
    xorgxrdp (0.9.5-2) を展開しています...
    以前に未選択のパッケージ xrdp を選択しています。
    .../xrdp_0.9.5-2_amd64.deb を展開する準備をしています ...
    xrdp (0.9.5-2) を展開しています...
    ureadahead (0.100.0-20) のトリガを処理しています ...
    libc-bin (2.27-3ubuntu1) のトリガを処理しています ...
    xrdp (0.9.5-2) を設定しています ...
    
    Generating 2048 bit rsa key...
    
    ssl_gen_key_xrdp1 ok
    
    saving to /etc/xrdp/rsakeys.ini
    
    Created symlink /etc/systemd/system/multi-user.target.wants/xrdp-sesman.service → /lib/systemd/system/xrdp-sesman.service.
    Created symlink /etc/systemd/system/multi-user.target.wants/xrdp.service → /lib/systemd/system/xrdp.service.
    systemd (237-3ubuntu10.11) のトリガを処理しています ...
    man-db (2.8.3-2ubuntu0.1) のトリガを処理しています ...
    xorgxrdp (0.9.5-2) を設定しています ...
    libc-bin (2.27-3ubuntu1) のトリガを処理しています ...
    ureadahead (0.100.0-20) のトリガを処理しています ...
    zen@ubClient:~$
    zen@ubClient:~$ cat /etc/xrdp/xrdp.ini  | grep new_cursors
    new_cursors=true
    zen@ubClient:~$
    zen@ubClient:~$
    zen@ubClient:~$ sudo sed -e 's/^new_cursors=true/new_cursors=false/g' -i /etc/xrdp/xrdp.ini
    [sudo] zen のパスワード:
    zen@ubClient:~$
    zen@ubClient:~$ cat /etc/xrdp/xrdp.ini  | grep new_cursors
    new_cursors=false
    zen@ubClient:~$
    zen@ubClient:~$ sudo systemctl restart xrdp
    zen@ubClient:~$
    zen@ubClient:~$  D=/usr/share/ubuntu:/usr/local/share:/usr/share:/var/lib/snapd/desktop
    zen@ubClient:~$
    zen@ubClient:~$
    zen@ubClient:~$
    zen@ubClient:~$ cat < ~/.xsessionrc
    > export GNOME_SHELL_SESSION_MODE=ubuntu
    > export XDG_CURRENT_DESKTOP=ubuntu:GNOME
    > export XDG_DATA_DIRS=${D}
    > export XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg
    > EOF
    zen@ubClient:~$
    zen@ubClient:~$
    zen@ubClient:~$ sudo usermod -aG xrdp zen
    zen@ubClient:~$ sudo emacs /etc/polkit-1/localauthority/50-local.d/xrdp-c
    olor-manager.pkla
    zen@ubClient:~$ sudo cat /etc/polkit-1/localauthority/50-local.d/xrdp-color-manager.pkla
    [Netowrkmanager]
    Identity=unix-user:*
    Action=org.freedesktop.color-manager.create-device
    ResultAny=no
    ResultInactive=no
    ResultActive=yes
    zen@ubClient:~$
    zen@ubClient:~$ sudo systemctl restart polkit
    
  • UbuntuにSSH接続できるようにする

    Ubuntu(18.04.01 LTS)には、SSHクライアントはインストールされていたが、SSH Serverはインストールされておらず(デーモンがなく)、リモート接続できなかった。そのため、Openssh-Serverをインストールして、設定した。

    apt search ssh-Server
    sudo apt install openssh-server
    cd /etc/ssh
    sudo emacs sshd_config
    

    `/etc/ssh/sshd_config`の下記の行を更新する

    #PermitRootLogin without-password
    PermitRootLogin no
    

    sshのサービスを起動する

    sudo /etc/init.d/ssh start

    あとは、接続を試す。

  • Ubuntuでsudo権限を持っているか確認する

    Ubuntu(確認した環境は 18.04 LTS)で、ユーザがsudo権限をもっているかどうかを調べるには、 ユーザの所属するグループに、「sudo」が含まれているかどうかを確認する。 グループ「sudo」に入っていれば、sudo権限がある。

    コマンドで調べるには、grousコマンドを使用する。

    groups ユーザ名 

    この結果に、「sudo」が含まれていれば、sudo権限あり。

  • Bitnami Redmineが起動しない

    Windows版のBitnami Redmineをアップデートした後に、Apacheのポート番号などを変えていたら、Redmineが使えなくなった。 Bitnami Redmineの状態を調べてみると、ApacheとMySQLは起動していたが、下記のThin_redmineがStopedになっていた。

    • Thin_redmine
    • Thin_redmine2

    手動で起動してみたが、起動を10秒くらいでStopedに代わってしまう。 Apacheを設定変更前にしてみたが、変わらずStopedになってしまう。

    エラーを見ると、rubygemまわりのエラーのようだったので、bundle installを実施。

    bundle install

    追加でいろいろとインストールされた。いろいろとインストールされたので、念のため、OSを再起動。その後、Thin_redmineが起動するようになった。

  • Bitnami Redmineのバージョンアップのやり方

    Windows版のBitnami Redmineのバージョンアップを行ったので、その手順のメモ。バージョンは「3.3.3-1」から「3.4.6-4」へのバージョンアップ。

    バージョンアップの流れ

    1. Bitnamiのページから、Windows用のインストールファイルをダウンロードする。
    2. ダウンロードしたインストーラを起動し、Bitnami Redmineをインストールする。 (バージョンが違う場合は、別フォルダにインストールされるので、共存が可能。)
    3. 下記のフォルダを旧から新にコピーする。
      C:\Bitnami\redmine-X.X.X-X\apps\redmine\htdocs\files\
      C:\Bitnami\redmine-X.X.X-X\apps\redmine\htdocs\plugins\
    4. 旧のMySQLからダンプをとる
      mysqldump -u bitnami --password=password --all-databases  --default-character-set=binary --port=3306 > dump20190115.sql
      (passwordの部分は、\htdocs\config\database.ymlに記録されているので、そこから抜く)
      (mysqldumpへのパスが通っていない可能性があるので、C:\Bitnami\redmine-X.X.X-X\mysql\bin\)
    5. 新のMySQLにインポートする
      mysql -u bitnami --password=password --port=3307 < dump20190115.sql
      (passwordの部分は、\htdocs\config\database.ymlに記録されているので、そこから抜く)
      (ポート番号は、インストールするときに指定したポート番号。間違って古いMySQLに入れないように注意する)
    6. CMD(コマンドプロンプト)で、カレントフォルダを"C:\Bitnami\redmine-X.X.X-X\apps\redmine\htdocs\" に移動する
    7. 下記コマンドを実行し、マイグレーションを行う
      bundle exec rake db:migrate RAILS_ENV=production 
    8. エラーの内容をみて、対処する。下記のようなエラーが出た。
      If this is a development machine, remove the C:/Bitnami/redmine-3.4.6-4/apps/redmine/htdocs/Gemfile freeze
      by running `bundle install --no-deployment`.  
    9. エラー内容に従い、下記のコマンドを実行。
      bundle install --no-deployment
    10. 正常にRedmineが起動した。
    11. あとは、Apacheのポート番号などを修正、メール送信などは、configuration.yamlを修正

    参考: https://qiita.com/sugasaki/items/adc9a08320299c08b94a