ユーザバックエンドがSQLのiredmailのSOGoでユーザがログインできない

2020/09/10追記

iRedMail内のパスワード文字列取り扱いについて「Password hashes」というドキュメントが公開された。

それによればmd5-cryptを使いたい場合は「{CRYPT}$1$5ulpxxxx$VS0xHxxKxMPBSIPQlXDXC/」という風に「{CRYPT}」という前置詞を追加すれば良いらしい。


qmail+vpopmailからパスワード暗号化文字列ごと移植したpostfix+dovecotベースの統合環境iredmail環境がある。

iredmailにはExchange互換サーバのSOGoもあるので、そちらでログインしようとしたらエラーになる。

roundcubeからだとログインができるし、dovecotを使うPOP3/IMAPアクセスでも問題無い。

/var/log/sogo/sogo.log へのエラーは下記の様になっていた。

Jul 04 13:15:04 sogod [9257]: SOGoRootPage Login from 'クライアントIPアドレス' for user 'ユーザ名@ドメイン名' might not have worked - password policy: 65535  grace: -1  expire: -1  bound: 0

iredmailのフォーラムに「Can’t configure password policy when using SOGo」といのがあり、sogo.confに「passwordPolicy = YES;」を追加すればいいじゃん?とあったのでやってみたが、変化はなし。

SOGo側のbug tracking system「 0003899: SQL authentication 」にてヒントを発見。

暗号化文字列の指定の問題のようだ。

今回、sogo.confは下記の様に「userPasswordAlgorithm = ssha512」となっており、パスワード暗号化文字列がssha512フォーマットである、ということになっている。

    SOGoUserSources = (
        {
            type = sql;
            id = users;
            viewURL = "mysql://sogo:~@127.0.0.1:3306/sogo/users";
            canAuthenticate = YES;

            // The algorithm used for password encryption when changing
            // passwords without Password Policies enabled.
            // Possible values are: plain, crypt, md5-crypt, ssha, ssha512.
            userPasswordAlgorithm = ssha512;
            prependPasswordScheme = YES;

            // Use `vmail.mailbox` as per-domain address book.
            isAddressBook = YES;
            displayName = "Domain Address Book";
            SOGoEnableDomainBasedUID = YES;
            DomainFieldName = "domain";
        },

しかし、今回、vpopmail時代の文字列「$1$5ulpxxxx$VS0xHxxKxMPBSIPQlXDXC/」という書式、つまりはmd5-cryptフォーマットを流用しているので認証できなかった、ということになる。

メインとなるiredmail側は新しくパスワードを設定した場合はssha512、移植したものはmd5-cryptという運用にしている。

ただ、postfix,dovecot,roundcubeの運用に関しては、ssha512でもmd5-cryptでも問題無くログインできている。

それに対してSOGo側は「SOGO Installation and Configuration Guide」を見ると userPasswordAlgorithm には1つの値しか指定はできないようだ。

セキュリティを考えると全体をmd5-cryptに下げる、という選択肢はとれないので、SOGoを使いたい場合は、パスワードを再設定する、ということになる。

パスワードを再設定すると以下のログとなる。

Jul 04 13:50:43 sogod [1094]: SOGoRootPage successful login from 'クライアントIPアドレス' for user 'ユーザ名@ドメイン名' - expire = -1  grace = -1

Arduino/ESP32/TTGO T-WatchのシステムクロックとRTC周りのメモ 2019/07/02

TTGO T-watchの腕時計の時刻表示がおかしいので調べていったことのメモ

・T-Watchでは画面オフ時にシステムクロックが止まる

T-watchでは左側の端っこボタンを押すと画面がオフになる。

この処理は、power_handle関数内の「LVGL_POWER_IRQ」イベントの「axp.isPEKShortPressIRQ()」( 左側の端っこボタン =PEKキー)で行われている。

オフ時に「rtc_clk_cpu_freq_set(RTC_CPU_FREQ_2M)」を実行して、CPU周波数を落としている(240M→2M)

これによりOS内のシステムクロックの進みも劇的に遅くなって、ほぼ止まっているように見える。

このことがあるので、T-Watchのソフトウェアでは、システムクロックからではなく、RTC上の時計から時刻を取得しているようだった。

・システムクロックの設定方法はsettimeofday(UNIX)

Arduino/ESP32環境でシステムクロックを簡単に設定する手法はNTPからの時刻を取得して、システムクロックを適用する、というもの。

    struct tm timeinfo;
    bool ret = false;
    int retry = 0;
    configTzTime("JST-9", "pool.ntp.org");
    do {
        ret = getLocalTime(&timeinfo);
        if (!ret) {
            Serial.printf("get ntp fail,retry : %d \n", retry++);
        }
    } while (!ret && retry < 3);

また、システムクロックをRTCに反映するのも簡単。(以下は、RTCモジュールがPCF8563の場合に使うPCF8563_Libraryの場合)

        rtc.setDateTime(timeinfo.tm_year, timeinfo.tm_mon + 1, timeinfo.tm_mday, timeinfo.tm_hour, timeinfo.tm_min, timeinfo.tm_sec);

しかし、逆にRTCからシステムクロックに対して時刻を反映させる手法がよく分からない。

RTCモジュールがDS1307RTCの場合の事例があるので Michael MargolisさんによるTimeモジュールを使ってみたが、時刻設定はできなかった。

void syncSystemTimeByRtc()
{
    Serial.print("Read RTC :");
    Serial.println(rtc.formatDateTime(PCF_TIMEFORMAT_YYYY_MM_DD_H_M_S));
    struct tm dt;
    getLocalTime(&dt);
    Serial.printf("getLocalTime is %d:%d:%d\n",dt.tm_hour,dt.tm_min,dt.tm_sec);
    RTC_Date d = rtc.getDateTime();
    Serial.printf("  %d,%d,%d,%d,%d,%d\n",d.hour,d.minute,d.second,d.day,d.month,d.year);
    setTime(d.hour,d.minute,d.second,d.day,d.month,d.year);
    Serial.println(timeStatus());
    getLocalTime(&dt);
    Serial.printf("getLocalTime override RTC clock, %d:%d:%d\n",dt.tm_hour,dt.tm_min,dt.tm_sec);
   
}

上記のデバグコードをいれて、画面オフ→オンイベントを起こしてみると、

10:16:18.034 -> LVGL_POWER_IRQ event
10:16:18.034 -> 
10:16:18.034 -> PEKShortPressIRQ to off
10:31:15.803 -> PEKShortPressIRQ to on
10:31:15.803 -> bma423_disable:0
10:31:15.803 -> Read RTC :2019-7-2/10:31:15
10:31:15.835 -> getLocalTime is 10:16:9
10:31:15.835 ->   10,31,15,2,7,2019
10:31:15.835 -> 2
10:31:15.835 -> getLocalTime override RTC clock, 10:16:9
10:31:24.715 -> RTC time is 2019-7-2/10:31:24
10:31:24.715 -> getLocalTime is 10:16:17

時刻が設定されていない・・・

UNIXだとどうやってシステムクロック設定できたかな?と調べて見たらsettimeofdayでunixtimeを指定する、ということが判明

#include <time.h>    // requried for settimeofday 
#include <sys/time.h>// requried for timeval

上記を冒頭に追加した上で、以下を書いた。

void syncSystemTimeByRtc()
{
    Serial.print("Read RTC :");
    Serial.println(rtc.formatDateTime(PCF_TIMEFORMAT_YYYY_MM_DD_H_M_S));
    struct tm dt;
    getLocalTime(&dt);
    Serial.printf("getLocalTime is %d:%d:%d\n",dt.tm_hour,dt.tm_min,dt.tm_sec);
    RTC_Date d = rtc.getDateTime();
    Serial.printf("  %d,%d,%d,%d,%d,%d\n",d.hour,d.minute,d.second,d.day,d.month,d.year);
    dt.tm_hour = d.hour;
    dt.tm_min  = d.minute;
    dt.tm_sec  = d.second;
    dt.tm_mday  = d.day;
    dt.tm_mon = d.month-1;
    dt.tm_year = d.year-1900; 
    time_t timertc = mktime(&dt);
    Serial.print("RTC unixtime is ");
    Serial.print(timertc);
    Serial.print(" ,system unixtime is ");
    time_t timesys = time(NULL);
    Serial.println(timesys);
    struct timeval tv ={
      .tv_sec = timertc
    };
    settimeofday(&tv,NULL);
    
    getLocalTime(&dt);
    Serial.printf("getLocalTime override RTC clock, %d:%d:%d\n",dt.tm_hour,dt.tm_min,dt.tm_sec);
   
}

これで期待通りにRTCの時刻をシステムクロックに反映することができるようになった。

13:23:48.103 -> PEKShortPressIRQ to on
13:23:48.103 -> bma423_disable:0
13:23:48.103 -> Read RTC :2019-7-2/13:23:47
13:23:48.103 -> getLocalTime is 13:17:30
13:23:48.103 ->   13,23,47,2,7,2019
13:23:48.103 -> RTC unixtime is 1562041427 ,system unixtime is 1562041050
13:23:48.103 -> getLocalTime override RTC clock, 13:23:47
13:23:57.121 -> RTC time is 2019-7-2/13:23:56
13:23:57.121 -> getLocalTime is 13:23:56

・rtc_cpu_freq_setは非推奨

コンパイル中に以下の警告が・・・

C:\Users\osakanataro\Documents\Arduino\TTGO-T-Watch-mod\TTGO-T-Watch-mod.ino:328:17: warning: 'void rtc_clk_cpu_freq_set(rtc_cpu_freq_t)' is deprecated [-Wdeprecated-declarations]

                 rtc_clk_cpu_freq_set(RTC_CPU_FREQ_240M);

https://github.com/espressif/arduino-esp32/blob/master/tools/sdk/include/soc/soc/rtc.h 」を確認したところ、「 rtc_clk_cpu_freq_config_set 」に置き換わった、とある。

・・・あるんだけど、 rtc_clk_cpu_freq_config_set に関する資料がでてこないってどういうこと???

grepしても定義無いし、試しに置き換えてみても定義されてない、というエラーになった。

ESP32腕時計TTGO T-Watchが届いた

ESP32を搭載した腕時計風のTTGO T-Watchを約49ドルで購入しました。

約2週間で届いたので早速遊んでみました。

資料系

メーカページ(LILYGO)
公式英語マニュアル
公式中国語マニュアル
サンプルソフトウェア

開梱

かわいらしい感じの梱包ですね。

内容物はこちら

T-Watch本体と、予備のボード?、T-Watchの横にあるコネクタから拡張するためのケーブル、Type-Cケーブル、腕時計用バンド、裏蓋取り外し用ネジ回しと予備のネジ

説明書には中を開けた時にどういう感じになっているのか書かれています。

とりあえずこちらも開けてみました。

元に戻して電源ON

最初はタッチパネルの検査プログラムが起動しタッチした座標を報告します、Type-Cコネクタの隣のボタンを押すと、今度は衝撃検知プログラムが起動しstepCountとして振り回した回数を表示します。

とりあえず、パソコンにつなげるとドライバがあれば「Silicon Labs CP210x USB to UART Bridge (COM?)」として認識します。

ドライバがインストールされていない場合は下記の様に「CP2104 USB to UART Bridge Controller」として認識されます。ドライバのインストールについては後述します。

デモ用のプログラムがgithubで公開されていますのでArduio IDEをセットアップします。

ただし、普通にインストールしただけでは認識せず、追加手順が必要となります。

必要なもの

Arduino IDE
git for Windows

T-watch ソフトウェア書き込み手順

TTGO公式の設定手順を参照しながらやりました。

その1:git for Windowsをインストール

以前に別の件でインストールしていたのでそのまま使っています。

その2:Arduino IDEをインストール

今回はArduino IDE ver 1.8.9をインストールしました。

その3: Arduino IDEのインストール先のhardwareディレクトリ内にespressifディレクトリを作る

標準インストールだとC:\Program Files (x86)\Arduino\hardware ディレクトリ内にespressifディレクトリを作る。

その4:作成したespressifディレクトリ内でコマンドプロンプトを開く

作成したC:\Program Files (x86)\Arduino\hardware\espressifディレクトリででコマンドプロンプトを開きます。

その5:gitでespressifのarduino-esp32レポジトリを取得する

espressifディレクトリで「git clone –recursive https://github.com/espressif/arduino-esp32.git esp32」(wordpress編集画面だと「-」が2個なのに1個だけになる・・・)を実行します。

そうすると、 C:\Program Files (x86)\Arduino\hardware\espressif\esp32 ディレクトリが作成されファイルが置かれていきます。

その6:esp32\toolsディレクトリにあるgetコマンドを実行し追加ファイルを取得

C:\Program Files (x86)\Arduino\hardware\espressif\esp32\tools\ ディレクトリ内にある「get.exe」を実行し、追加ファイルを取得します。

その7:Silicon Labs CP210xをインストール/アップデート

手順には明記されていないのですが、古いドライバ Ver6.7.4.261で書き込もうとするとエラーになりました。「T-WatchマニュアルのGetting started」に掲載されているCP2104-Win10(Ver10.1.8.2466)だと正常に動きますので、アップデートします。
(CP2104の製造メーカ公式ドライバダウンロードページ)

なお、書き込み時のエラーは下記の「A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header」です。

その8:T-Watchをパソコンに接続

その9:Arduino IDEを起動し、TTGO T-Watchを選択

Arduino IDEを起動し、「ツール」-「ボード」の一覧から「TTGO T-Watch」を選択します。

その10:T-Watchサンプルソフトを取得

git for Windowsを使って、 https://github.com/Xinyuan-LilyGO/TTGO-T-Watch で公開されているサンプルソフトウェアを取得します。

「git clone –recursive https://github.com/Xinyuan-LilyGO/TTGO-T-Watch」

取得完了後、「library」にあるディレクトリを、マイドキュメントの中にある「Arduino\library」内にコピーします。

その11:書き込み

Arduino IDEからサンプルソフトウェアを書き込みます。


サンプルソフトウェアを書き込んだのですが、うまいこと自宅のWiFiに接続できず、時計合わせに失敗しています。

また、タッチパネルの動作が若干微妙な感じもあります・・・

ESXi上でCentOS7なのにCentOS6だと言われる件

ESXi上でCentOS7をインストールした場合、open-vm-toolsをインストールされていても「CentOS6」だと言われてしまう件について調査した。

なお、何故かvCenter上から見た場合は警告されず、直接ESXi上で仮想マシンを見た際にだけ言われる。

結論めいたこと

open-vm-toolsのバグ(Fix CentOS 7.6 detection)で、open-vm-tools 10.3.10以降で修正されている。

しかし、2019/06/27時点でのCentOS7のopen-vm-toolsは10.2.5であり修正されていないバージョンであるため公式な手法では対処できない。

回避策としては2つある

/etc/centos-release を修正する

今回のバグは「CentOS Linux release 7.6.1810 (Core)」の文字列からOSバージョン判定をする際に「”6.”があればCentOS6」「”7.”があればCentOS7」「”8.”があればCentOS8」という順番で行っているせいで、「7.6.1810」の中にある「6.」を読み取ってしまい「CentOS6」と判定されていることにより発生している。

このため、/etc/centos-release 内の誤判定要素を無くすことで対処できなくもない。

例えば「 CentOS Linux release 7.6 1810 (Core) 」と、「.」を抜いてしまうとか。

ただ、このファイルは他のソフトウェアでもディストリビューション判別に使用されており、そこでの条件の書き方によっては正しく判定できなくなってしまう恐れもあるため、注意が必要である。

もしくはCentOS 7.7以降ではれば、「6.」に引っかかることがなくなるので、アップデートする、という手もとれる。

vSphere仮想マシンオプションのゲストOSを修正する

vSphere6.5以降(仮想マシンバージョン13以降)でCentOS7を使用する場合、仮想マシンオプションで「ゲストOS:Linux」と「ゲストOSのバージョン:CentOS 7(64ビット)」を設定する。

誤判定で「CentOS 6(64ビット)」と認識されているんだったら、仮想マシンオプションの「ゲストOSのバージョン」も「CentOS 6 (64ビット)」にしちゃえばいいじゃん。

という非常に雑な対応手法。

なんでこんなことに

githubにあるopen-vm-toolsのソースコードからopen-vm-tools/open-vm-tools/lib/misc/hostinfoPosix.c を見てみるとひたすら条件が列挙されている。

いままではバージョン表記の中に「.」が2個登場するという想定が無かったようで、Debianでも同様の手法で判定しています。

今回のCentOSでの対応は、いままで「6.」をキーにしていたものを「 6.」と数字の前にスペースが入っていることを検出するようにした、というものになっている。

個人的に結構意外だったのはRedHat Enterprise LinuxとCentOSの判定ルーチンが独立しているという点。

   if (strstr(distroLower, "red hat")) {
      if (strstr(distroLower, "enterprise")) {

         /*
          * Looking for "release x" here instead of "x" as there could be
          * build version which can be misleading. For example Red Hat
          * Enterprise Linux ES release 4 (Nahant Update 3)
          */

         int release = 0;
         char *releaseStart = strstr(distroLower, "release");

         if (releaseStart != NULL) {
            sscanf(releaseStart, "release %d", &release);
            if (release > 0) {
               snprintf(distroShort, distroShortSize, STR_OS_RED_HAT_EN"%d",
                        release);
            }
         }

         if (release <= 0) {
            Str_Strcpy(distroShort, STR_OS_RED_HAT_EN, distroShortSize);
         }

      } else {
         Str_Strcpy(distroShort, STR_OS_RED_HAT, distroShortSize);
      }
   }
   } else if (StrUtil_StartsWith(distroLower, "centos")) {
      if (strstr(distroLower, " 6.")) {
         Str_Strcpy(distroShort, STR_OS_CENTOS6, distroShortSize);
      } else if (strstr(distroLower, " 7.")) {
         Str_Strcpy(distroShort, STR_OS_CENTOS7, distroShortSize);
      } else if (strstr(distroLower, " 8.")) {
         Str_Strcpy(distroShort, STR_OS_CENTOS8, distroShortSize);
      } else {
         Str_Strcpy(distroShort, STR_OS_CENTOS, distroShortSize);
      }
   } 

そして、Oracle LinuxはCentOSと同様の記載になっているという点。

   } else if (StrUtil_StartsWith(distroLower, "enterprise linux") ||
              StrUtil_StartsWith(distroLower, "oracle")) {
      /*
       * [root@localhost ~]# lsb_release -sd
       * "Enterprise Linux Enterprise Linux Server release 5.4 (Carthage)"
       *
       * Not sure why they didn't brand their releases as "Oracle Enterprise
       * Linux". Oh well. It's fixed in 6.0, though.
       */
      if (strstr(distroLower, "6.")) {
         Str_Strcpy(distroShort, STR_OS_ORACLE6, distroShortSize);
      } else if (strstr(distroLower, "7.")) {
         Str_Strcpy(distroShort, STR_OS_ORACLE7, distroShortSize);
      } else if (strstr(distroLower, "8.")) {
         Str_Strcpy(distroShort, STR_OS_ORACLE8, distroShortSize);
      } else {
         Str_Strcpy(distroShort, STR_OS_ORACLE, distroShortSize);
      }
   }

Oracle Linux 7の /etc/oracle-release の表記はどういう風になってるんだろうかな・・・

Steam版Blenderをインストールしたけど拡張子.blendの関連付けが行われない

Steam版Blender」が無料になっていたので入手してインストールした。

従来のBlenderもインストールしていたので、アプリケーション一覧だと以下のような感じになっていた。(上がSteam版)

デスクトップ上のアイコンだと下側の「Blender」がSteam版。

Blenderアプリのバージョンアップを自動で行いたいからSteam版Blenderをインストールしたので、従来版Blenderのアンインストールをしたところ問題が発生。

拡張子.blendの関連付けがなくなってしまった。Steam版Blenderもアンインストールし、Steam版Blenderだけを再インストールしてみても関連付けを行ってくれない。

検索したところ「.blend file association」にて対処方法を発見。

1. Library -> Software
2. Right Click “Blender” -> Properties -> Set Launch Options
3. Add “-R” without quotes
4. Hit OK
5. Launch Blender
6. You should see a command prompt window and a message saying “File extension registered for the current user. To register for all users, run as an administrator.”
7. Hit OK
8. Right Click “Blender” -> Properties -> Set Launch Options
9. Remove “-R”
10. Double click any .blend file and it should open with the Steam Blender version

Steamアプリの中からSteam版Blenderを起動する際、1回だけ「-R」オプションをつけて起動することで関連付け処理が行われる、とのこと。

これを実行してみたら問題なく動作するようになった。