カテゴリー: 技術系memo

  • Gitlab CE 13.10.3でapt upgradeしたらエラーになったので、個別にバージョンアップした

    Gitlab CE 13.10.3 がインストールされたUbuntuで、apt upgradeしたときに、Gitlabだけバージョンアップできずにエラーになった。古いままにもできないので、ステップを踏んでバージョンアップされたときのメモ。

    エラー

    (データベースを読み込んでいます ... 現在 327380 個のファイルとディレクトリがインストールされています。)
    .../gitlab-ce_14.2.3-ce.0_amd64.deb を展開する準備をしています ...
    gitlab preinstall: It seems you are upgrading from major version 13 to major version 14.
    gitlab preinstall: It is required to upgrade to the latest 14.0.x version first before proceeding.
    gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
    dpkg: アーカイブ /var/cache/apt/archives/gitlab-ce_14.2.3-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
     new gitlab-ce package pre-installation script subprocess returned error exit status 1
    処理中にエラーが発生しました:
     /var/cache/apt/archives/gitlab-ce_14.2.3-ce.0_amd64.deb
    E: Sub-process /usr/bin/dpkg returned an error code (1)

    下記のコマンドを順番に実行して、ステップを踏んでGitLabをバージョンさせた。 ”13.10.3”→”13.12.11”→”14.2.3”の順にバージョンアップさせた。”14.2.3”はバージョンアップをしたときの最新バージョン。

    sudo apt-get update
    sudo apt-cache madison gitlab-ce
    (各マイナーバージョンの最後のバージョンを調べて、次のインストールから指定した)
    sudo apt-get install gitlab-ce=13.12.11-ce.0
    sudo apt-get install gitlab-ce=14.0.10-ce.0
    sudo gitlab-ctl reconfigure
    sudo apt-get install gitlab-ce=14.2.3-ce.0

    Gitlab CE 14.2.3のインストールをしたときにエラーが表示されたが、実際には成功していたようだ。

    参考 https://docs.gitlab.com/ee/update/index.html#checking-for-background-migrations-before-upgrading

  • 小数点ありの数字のみを入力させるタグ

    ウェブの入力で、数値入力のみをさせるタグ。html5以降で、inputタグのタイプをnumberにすることで、数値入力専用になる。オプションの”step”で指定することにより、入力できる最小単位を決められるので、stepで少数を指定することで、入力を少数でできる。

    <input type="number" step="0.5" max="24" min="0"  value="0" class="chara4">

    解説

    • stepで、「0.5」を指定し、0.5単位の入力に限定している。(0.5, 1, 1.5, 2 のように0.5刻みで入力される)
    • maxで、最大の数をしている。ここでは最大で24まで。
    • minで、最小の数をしている。0を指定しない場合は、マイナスの数値も入力できる。
    • valueで、初期を指定。

    入力の枠の幅を”size”では指定できないので、CSSで指定した。下記では、4文字分の幅にしている。

    input[type="number"].chara4 { 
        width: 4em; 
    }
  • Windows10の21H1はデフォルトでWSL2になっている。

    Windows10 21H1で、WSLをインストールすると、最初から規定のバージョンが2になっている(デフォルトでWSL2になっている)。

    設定を変えなくても、WSL2の機能を使えるので楽。

  • SQL Serverの名前付きインスタンスはUDP 1434を使用する

    SQL Serverへの接続に使用するポートは、通常、TCPの1433番ポート。デフォルトでインストールしたSQL Server(既定のインスタンス)しかなければ、これで接続できる。名前付きで、SQL Serverをインストールした場合は、SQL Server Browerサービスを使用することにより、1434番ポートで、UDPを使用する。

    SQL Serverでポート番号を調べると、1433と1434が出てくるのだが、これをTCPだけで設定してしまうと、SQL Server Browerサービスを介した名前解決でエラーになる。エラー時には、エラー番号の26なので、SQL Server Browerサービスの起動を確認するのだが、これが起動されている場合には、UDPの1434番ポートが通信可能になっているかを通信経路上(SQL Serverのサーバと、経路のネットワークと、クライアント)で確認する。

    Provider: SQL Network Interface, error: 26

    さらに注意事項として、名前付きインスタンスが動的ポートで構成されるようになっている場合(デフォルトだと動的ポート)、1433番ポートを使用して、SQL Serverが起動していない。名前付きインスタンスの1つしかインストールされていない場合には、起動ポートを1433に固定することで、他のポートは空けなくてもよい。

    参考: https://docs.microsoft.com/ja-jp/troubleshoot/sql/connect/resolving-connectivity-errors

  • vRealize Operations 8.5 のサイジングガイドライン

    vROpsのサイジングのガイドライン。ガイドラインでの大きな指針は、CPU数とメモリサイズ。これが監視対象となるホストの数とゲストの数から、サイジングされる。データを保管するHDDサイズについては載っていない。HDDというかVMDKは追加できるから、ということだろう。

    vRealize Operations 8.5 Sizing Guidelines (85062) (vmware.com)
    https://kb.vmware.com/s/article/85062

  • Nginx上のPHPのページにアクセスすると「File not found.」と表示される

    NginxにPHPを動作させるための設定をいれたのだが、アクセスすると、「File not found.」と表示されて、PHPの処理がされない。Nginxのエラーログを見てみると、下記の表示があった。

    FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream,

    Nginxの「/etc/nginx/sites-available/default」のPHPに関連する設定は、下記のように設定していた。

         # pass PHP scripts to FastCGI server 
            # 
            location ~ \.php$ { 
                        include snippets/fastcgi-php.conf; 
            # 
            #       # With php-fpm (or other unix sockets): 
                    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; 
            #       # With php-cgi (or other tcp sockets): 
            #       fastcgi_pass 127.0.0.1:9000; 
                    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name; 
            }

    上記を、次のように修正したところ、正常にPHPの処理が行われた。

         # pass PHP scripts to FastCGI server 
            # 
            location ~ \.php$ { 
                     root     /var/www/html; 
                     include snippets/fastcgi-php.conf; 
            # 
            #       # With php-fpm (or other unix sockets): 
                    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; 
            #       # With php-cgi (or other tcp sockets): 
            #       fastcgi_pass 127.0.0.1:9000; 
                    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name; 
                    include fastcgi_params; 
            }

    そもそものエラーが、ファイルの場所がわからないということなので、「root  path」でドキュメントルートを指定したことにより、正常に処理ができるようになった。Nginxの設定は、何回やっても難解でどこからしらで躓く。

  • Nginxでファイルアップロードで「413 Request Entity Too Large」が表示される

    Nginx上で、Wordpressを動作させるために、PHP-FPMやMariaDBを設定して「動作した」と思ったら、アップロードで、下記のエラーが表示された。

    413 Request Entity Too Large

    アップロードしたファイルは1MBちょっとのファイルなのだが。これを調べていくと、PHP側のアップロードサイズとポストサイズは問題なかった。Nginx側は、サイズ指定されていないようなので、デフォルトのサイズだった。このNginxのデフォルトサイズが問題で、デフォルトだと、1mしかない。これが原因なので、Nginxのパラメータを書き換える。

    https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

    `/etc/nginx/sites-available/default` を編集し、「server {}」のところに、「client_max_body_size 30m;」を追加し、最大サイズを30mにした。

    # Default server configuration 
    # 
    server { 
            #listen 80 default_server; 
            #listen [::]:80 default_server; 
            listen 443 ssl default_server; 
            listen [::]:443 ssl default_server; 
            #listen 443 ssl; 
            ssl_certificate /etc/nginx/conf.d/server.crt; 
            ssl_certificate_key /etc/nginx/conf.d/server.key; 
            client_max_body_size 30m;

    あとは、Nginxを再起動するか、Nginxでコンフィグをリロードする。

    `sudo service nginx reload` でコンフィグのリロードか、` sudo service nginx restart` で再起動する。これでエラーがでなければOK。

  • リバースプロキシを使ったWordPressのアクセスでハマる

    リバースプロキシの後ろにWordpressをおいて、リバースプロキシ経由でアクセスさせようとしたところ、ハマった。いろいろと試しているが、現在進行系で格闘中だ。

    事象としては、

    • インストール時に、Wordpressのホスト名が「127.0.0.1:8080」で登録されてしまい、ログインしようとすると、127.0.0.1にアクセスしようとしてしまい、アクセスできず。
    • 上記の問題は、DBを直接書き換えることで対処するが、トップページにアクセスすると、「127.0.0.1」にリダイレクトされる。
    • WordPressのCSSの一部と、画像が表示されない

    という具合だ。前がNginxで、後ろがApache2.4。WordpressをCDNで配信するときの設定も試したが、うまく行かず。たぶん、根本的に何かが欠けていると思われる。簡単と思っていたけれど、思わぬところでハマるものだ。最初から考え直し。

  • インストールされているMariaDBが64ビットかどうかを確認する

    64bitでインストールされているはずだが、念のため、MariaDBが64bitでインストールされているかどうかを調べる方法について。DBに接続した状態で、下記のコマンドを実施する。MySQLでも同じように調べることができる。

    show variables like 'version_compile_machine';

    これの結果が、「X86_64」になっていれば、64bitでインストールされている。「i386」や「i686」の場合は、32bitでインストールされている。

    MariaDB [(none)]> show variables like 'version_compile_machine';
    +-------------------------+--------+
    | Variable_name           | Value  |
    +-------------------------+--------+
    | version_compile_machine | x86_64 |
    +-------------------------+--------+
    1 row in set (0.001 sec)
    MariaDB [(none)]>
  • ChromebookとYamahaマイク/スピーカーの接続させた

    Chromebookでも、会議用のマイク・スピーカーでウェブ会議が円滑にできるのか、が気になって、Lenovo Ideapad Duetに、USB Type-Cのハブ経由で、YAMAHAのYVC-200をUSB接続させてみた。

    結果としては、問題なく接続できて、Chromebook上でもマイクとスピーカーとして認識される。イヤホンマイクのように、USB経由のマイクとスピーカーとして認識される。Google MeetやZoomでも使うことができた。YAMAHAのマイク・スピーカーなので、集音性もよく、ミーティングも問題なし。

    このときの次いでとして、Androidのスマートフォンにも同じように接続させてみた。Androidのスマートフォン(京セラ Digno J、Digno BX)でも、同じようにYAMAHA YVC-200はマイクとスピーカーとして認識された。USB Type-Cハブ経由での拡張性は高い。