ボールペンリフィル(替え芯)の選び方

贈答品で頂いたボールペン、気に入って使っていてインクが無くなってしまったとき、何処にもメーカーも型番も書いていないし、替えインクを買いたくても諦めていたりしませんか?

ボールペンのインクの形状はJIS規格で定められており、A1、A2、B、D、E、F、G1、G2、Hの9種類に分かれています。同じ規格のリフィルであれば、他社製のリフィルでも使える可能性が高いです。HはA1~G2の何れにも一致しない規格ということなので、実質は8種類ですね。

ペン先直径、直径(一番太いところ)、全長の三つを計って以下のリストと比較してください。

規格ペン先の直径直径全長
A12.40mm3.20mm106.8mm
A21.60mm3.20mm106.8mm
B2.28mm3.00mm98.2mm
D2.35mm2.35mm67.0mm
E2.25mm3.00mm140.0mm
F2.30mm3.00mm143.0mm
G11.60mm5.00mm106.8mm
G22.54mm6.00mm98.1mm
H

だいたいG2規格が多いようです。A1~G2の規格に一致しない場合には、各メーカの独自規格と思われます。

その場合には日本筆記具工業会で公開している「油性ボールペン替芯互換表」「ゲルボールペン替芯互換表」を参照してみてください。各メーカーが出しているリフィルのペン先直径(外径)、直径(最大径)、全長が一覧表になっているので、その中から一致する型番を探してください。型番が絞られたらメーカーのページで、ペン先やお尻部分の形状が一致しているものを探す事になります。

PTAや自治会でIT活用が出来ない理由

2013年の国際成人力調査をご存じでしょうか?平均点で見ると、読解能力、数的思考力、IT活用能力の何れでも日本がトップなのです。調査結果は読解能力、数的思考を得点によってレベル1未満~レベル5までの6段階に、IT活用能力はレベル1未満~レベル3の4段階に分けて成人割合もだしています。各レベル毎の成人割合を見ると日本の特徴が際立ってきます。読解能力がレベル2以上となる成人割合は日本93.9%、ドイツ81.0%、米国78.3%。数的思考力がレベル2以上となる成人割合は日本90.6%、ドイツ80.1%、米国67.1%。IT活用能力がレベル2以上となる成人割合は日本34.6%、ドイツ36.0%、米国31.1%。

日本では読解能力、数的思考力が一様に高い水準にあり、レベル1やレベル1未満の割合が極端に少ないのです。

このことが日本においてPTA役員や自治会役員を持ち回りやくじ引きで決めることを可能にしています。紙と鉛筆で業務を行う限りにおいては、日本人ならほぼ誰でも業務を遂行できるだけの事務能力を持ち合わせているわけです。全員に一様に業務を割り振り、一人あたりの負担を減らすと共に、全員が公平に負担する仕組みを作ってきました。日本以外において、同じような役員の決め方をしたら、業務遂行能力を持たない役員が発生する確率が高く、成り立たないでしょう。

対して、IT活用能力においては、日本では成人の34.6%だけが高い能力を有しており、日本の平均値を世界でもトップレベルに引き上げています。

このことがPTA役員や町内会や自治会におけるIT活用の難問になります。ITを活用するなら、成人の35%しか業務を遂行できません。従来のように一様に全員が業務を負担することで公平性を保つ仕組みは維持できません。特定の人だけに業務が集中する事を容認し推奨するような価値観の変革が必要になるのです。

PowershellからBITS(Background Intelligent Transfer Service)を使用して大容量ファイルを配布する

BITSはMicrosoftがWindowsに標準機能として載せている分散ダウンロード機能です。WindowsUpdateもバックグラウンドでBITSを利用しており、LAN内の複数のPCからWindowsUpdateをダウンロードする場合には、他のパソコンが自動的にキャッシュサーバーとなることで、インターネットとの通信負荷を押させてくれます。このBITSはWindowsUpdate専用の機能というわけではなく、簡単なプログラムを用意すれば、大容量ファイルを配布するときに自由に活用することができます。

昨今、プログラムやセキュリティパッチのフットプリント(ファイルサイズ)が大きく鳴り続ける、パッチ配布のネットワーク負荷が原因でインターネットが輻輳するなんて事件もありましたね。社内ネットワーク(WAN)はその構造上、どうしても一か所に負荷が集中しやすく、分散ダウンロードができると随分と助かりますね。

BITSでダウンロードするための一連の流れは次のようになります。

  1. HTTPサーバー上にダウンロード元となるファイルを用意します。
  2. Start-BitsTransferでBITSに新しいダウンロード要求を登録します。
  3. 定期的にGet-BitsTransferを呼び出しダウンロードの完了を待ちます。
  4. ダウンロード完了後にComplete-BitsTransferでファイルに書き出します。

上記をPowershell Scriptで記述したのが下記です。このスクリプトをダウンロードが完了するまで定周期で実行します。

$displayName = 'BITS_Sample'; # BITSにダウンロード要求を登録する時の表示名
$fromURL = 'http://www.example.co.jp/BITS_Sample.zip'; # ダウンロード元のURL
$destFile = 'C:\TEMP\BITS_Sample.zip'; # ダウンロード先のファイル名
$logFile = 'C:\TEMP\BITS_Sample.log' # ログ出力先のファイル名

$noBitsInstance = $true;
$completeDownload = $false;

Add-Content -Path $logFile -Value ('Start Script:' + (Get-Date));

# ダウンロード先フォルダが無ければ作成しておく
if ($false -eq (Test-Path 'C:\TEMP')){
    mkdir 'C:\TEMP';
}

# ダウンロードファイルが
if ($false -eq (Test-Path $destFile)){
    # BITSへのダウンロード要求を列挙する
    Get-BitsTransfer | Where-Object {
        Add-Content -Path $logFile -Value ('BITS Status:' + $_.DisplayName + '-' + $_.JobState);
        # 表示名の一致しているダウンロード要求が転送終了になるまで待機
        if ($_.DisplayName -eq $displayName){
            $noBitsInstance = $false;
            if ($_.JobState -eq "Transferred") {
         # ダウンロード完了した転送要求を完了させる
                Complete-BitsTransfer $_;
                $completeDownload = $true;
            }
        }
    }

    # BITSにダウンロード要求が登録されていなければ、新たに登録する。
    if ($noBitsInstance -eq $true){
        $delayMinute = Get-Random -Maximum 240;
        $kickDateTime = (Get-Date).AddMinutes($delayMinute);

        # 新規ダウンロード登録までランダムに待機する
        Add-Content -Path $logFile -Value ('Wait ' + $delayMinute + ' Minutes');
        While ($kickDateTime -ge (Get-Date)){
            Add-Content -Path $logFile -Value ('delay - ' + (Get-Date));
            sleep 60;
        }

        # 新規にダウンロードを登録する
        Add-Content -Path $logFile -Value ('Start BitsTransfer:' + $displayName + '-' + $destFile);
        Start-BitsTransfer -Source $fromURL -Destination $destFile -Asynchronous -Priority Normal -DisplayName $displayName
    }

    if ($completeDownload -eq $true){
        # ダウンロード完了後の処理
        Add-Content -Path $logFile -Value ('Complte Download:' + $displayName + '-' + $destFile);
    }
}
Add-Content -Path $logFile -Value ('End Script:' + (Get-Date));

私はActive Directoryのグループポリシーでログオンスクリプトとして登録しました。コントロールパネルのタスクで定周期に起動してもよいでしょう。

BITSで使用する帯域の制限などはレジストリに記述するか、ActiveDirectoryのグループポリシーで定義します。

Nextcloudに大きなファイルをアップロードするとRequestTimeTooSkewedが発生する

NextcloudでストレージにS3を使用している場合に、約500MBを超える大きなファイルをアップロードすると、以下のようなエラーが発生する場合がある。

An exception occurred while uploading parts to a multipart upload. The following parts had errors:
- Part 1: Error executing "UploadPart" on "https://nextcloud-xxxx.s3.us-west-1.wasabisys.com/xxxx"; AWS HTTP error: Client error: `PUT https://nextcloud-xxxx.s3.us-west-1.wasabisys.com/xxxx` resulted in a `403 Forbidden` response:
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>RequestTimeTooSkewed</Code><Message>The difference between the reque (truncated...)
RequestTimeTooSkewed (client): The difference between the request time and the current time is too large. - <?xml version="1.0" encoding="UTF-8"?>
<Error><Code>RequestTimeTooSkewed</Code><Message>The difference between the request time and the current time is too large.</Message><RequestTime>20220101T141414Z</RequestTime><ServerTime>2022-01-01T14:32:28Z</ServerTime><MaxAllowedSkewMilliseconds>900000</MaxAllowedSkewMilliseconds><RequestId>xxxx</RequestId><HostId>xxxx/xxxx</HostId></Error>

この問題を解決するには./html/config/config.phpに以下の行を追加し、500MBよりも適当に小さなサイズで分割してアップロードするように設定する。下記の例では約20MBに設定を変更している。

    array (
      'bucket' => 'nextcloud-bucket',
      'key' => '{key}',
      'secret' => '{secret}',
      'region' => 'us-west-1',
      'hostname' => 's3.us-west-1.wasabisys.com',
      'port' => '443',
      'objectPrefix' => 'urn:oid:',
      'autocreate' => false,
      'use_ssl' => true,
      'use_path_style' => false,
      'legacy_auth' => false,
      'uploadPartSize' => 20971520,
    ),

S3にsinglepartでアップロードできるファイルサイズの上限は5GBとなり、より大きなファイルをアップロードするときにはmultipartでアップロードする必要がある。標準設定のNextcloudでは約500MBを超えるファイルをアップロードするときにはmultipartアップロード を使用する。

S3のmultipartアップロードがもつ仕様上の問題で、通信帯域の不足等によりデータのアップロードに約15分以上かかると、HTTPヘッダに記載されている時刻とAWS側サーバーとの時刻の差がMaxAllowedSkewMillisecondsを超えるために”RequestTimeTooSkewed: The difference between the reque (truncated…)
RequestTimeTooSkewed (client): The difference between the request time and the current time is too large.”のエラーが発生する。

MaxAllowedSkewMillisecondsは900000msに固定されいる。HTTPのリクエストデータを複製することによる第三者の攻撃を防ぐために設けられている値で、ユーザー側でこの値を任意に変更する事は出来ない。この問題を避けるには15分以内にアップロードが終わる程度の適当なサイズに分割してアップロードする必要がある。

ただし小さく分割するとS3にアップロードできる最大ファイルサイズが小さくなる事にも注意しなくてはならない。S3には最大で5TBのファイルを保管できるが、 multipart アップロード時には10,000分割以上に分ける事ができない。仮に上記のように20MBで分割した場合には、200GBを超えるファイルをアップロード出来ない。(Amazon S3 multipart upload limits

日本は解雇規制が厳しいのか?

非 正規労働者の増加とか、雇用の流動性低下とか、終身雇用なんかの話しになると、必ず「日本は解雇規制が厳しいから~」的な発言が出てくる。本当に日本の解雇規制が厳しいのだろうか?

解雇規制の厳しさを表す国債指標がとして、EPL 指標(Employment Protection Legislation Indicator)と言うものがある。2019年の調査結果では、日本のEPL指標は2.08、OECD平均が2.27だから、日本は解雇規制のやや緩い国といえる。日本が比較対象とする事の多い、米国は1.31、英国は1.90、独国は2.33、韓国は2.35だ。

日本は既に解雇規制がやや緩い国であって、安易にさらに解雇規制を緩めるべきでは無い。

正規労働者を解雇できない理由

日本で正社員の解雇が難しい要因は、かなりの部分で日本的な労働契約が原因になっている。能力や成果、職責、職務を明確にせずに雇用契約を結んでいるため、これらを解雇理由として解雇したり、雇用条件を変更することが出来ない。まだ判例が少なく、実際の線引きは難しいものがあるが、現に日本国内においても外資系企業は解雇を実施している。(判例:フォード自動車事件

国内企業も非正規労働者の解雇(雇い止め)を実施している。非正規労働者と正規労働者の間に法律上の差があるわけでは無い。非正規労働者は職務、職責、勤務地、雇用期間などを明確にして雇用契約を結んでいるからこそ、雇用契約に沿って解雇を行えているに過ぎない。

非正規労働者が増えている原因

平成21年度 年次経済財政報告」を見ると解雇規制の厳しい国は非正規労働者の割合が高くなる傾向にある。では日本は解雇規制が厳しいから非正規労働者の割合が高いのかというとそうではない。日本は解雇規制が緩いわりに、突出して非正規労働者の多い国になっている。

要員の一つは非正規雇用と正規雇用を比較した場合に、非正規雇用者の方が極端に解雇しやすくなっている事にある。非正規社員の方が解雇しやすいのであれば、非正規社員の比率が増える方向に働く。非正規社員を減らしたいのであれば、このバランスを取るように政策を定める事が望ましい。必要なのは正社員を解雇しやすくする事では無い。

例えば正社員を整理解雇するときに、会社側が特定の誰かを指定する事は出来ない。非正規社員にも同じ規制を設けるなら、契約満了するときに、契約更新する対象と、雇い止めする対象を、会社側が選択してはならないはずだ。

ちなみにドイツも非正規労働者の解雇規制の弱い国だが、非正規労働者率は低く抑えられている。調べてみると正規労働者を100とした場合、フルタイム非正規労働者の賃金は91と、同一労働同一賃金がかなり守られている。ただフルタイムでは無い非正規労働者の賃金は55と日本並みに低い。(参照:有期雇用の日独比較

正規社員の賃金を100とした場合、日本では非正規社員の賃金が56.6とかなり低い。この事も非正規労働差を増やす原因となっていると考えられる。(参照:地方公共団体の短時間勤務の在り方に関する研究会 同一労働同一賃金について

NextcloudでRedisによるLock管理を有効にする

NextcloudのWindowsアプリからフォルダの同期を行っている途中、~ Locked errorが度々表示されていました。Nextcloudはデフォルトだとmysqlを使用してロック管理をしていますが、高負荷時に問題がおこる場合があるようです。ファイルのロックにかかる問題を回避するために、Redisを導入してTransactional file lockingを有効にします。

Docker環境でRedisを有効にするにはdocker-conpose.ymlに、redisのイメージを追加し、nextcloudのenvironemntにREDIS_HOST、REDIS_HOST_PORT、REDIS_HOST_PASSWORDを、下記の様に追加します。

version: '3'

volumes:
  nextcloud:
  nextcloud-db:
  nextcloud-redis:

services:
  nextcloud-redis:
    image: redis
    ports:
      - 6379:6379
    volumes:
      - ./redis:/data

  nextcloud-db:
    image: mariadb
      ...

  nextcloud:
    image: nextcloud
      ...
    environment:
      - REDIS_HOST=nextcloud-redis
      - REDIS_HOST_PORT=6379
      - REDIS_HOST_PASSWORD=${redis_password}

その後、以下のコマンドを実行します。

$ sudo docker-compose up -d

docker-compose.ymlの設定だけでは Transactional file locking は有効になっていません。./html/config/config.phpを編集して、「’filelocking.enabled’ => true,」を追記します。

  'filelocking.enabled' => true,
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => 'nextcloud-redis',
    'password' => '',
    'port' => 6379,
  ),

Nextcloudの暗号化を有効にするときの覚書

Nextcloud:Encryption configuration

暗号鍵の保存場所

暗号化を有効にしたとき、暗号鍵は./html/data/files_encryptionおよび ./html/data/ユーザー名/files_encryptionに保存されます。基本的にアップロードしたデータと同じ場所に鍵も保管されるため、プライマリストレージをS3等のストレージに変更しているか、あるいは外部ストレージを使用していない限り暗号化によるセキュリティ向上の恩恵はありません。

またこれらの暗号鍵を安全な場所にバックアップしておく必要があります。

回復パスワードの保存

上記フォルダの暗号鍵はログインパスワードを元にして暗号化されているため、ログインパスワードが分からなくなった場合に、パスワードの初期化を行うと暗号化したファイルを読むことが出来なくなります。

これを避ける為には事前に回復パスワードを作成しておく必要があります。

LDAPなど外部の認証システムとの連携

前項の理由により、LDAPなど外部の認証システムと連携している場合に、ファイブのシステム上でパスワードの変更を行う場合、そのままでは暗号ファイルを読み取ることが出来なくなります。Nextcloud上で新旧のパスワード入力を求められるため、そこで旧パスワードを入力する必要があります。

NextCloudでアップロード時に不明なエラーが発生する。

大きなファイルをアップロードしていると「不明なエラー」が発生します。ログを見ると以下の様なエラーが発生していました。どうも帯域が狭いために、アップロード中にタイムアウトエラーが発生しているようです。

Sabre\DAV\Exception\BadRequest: Expected filesize of 10485760 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 5368032 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.

10,485,760 bytesは標準のチャンクサイズです。Nextcloudではアップロードをチャンクサイズのデータに分解して処理しています。10MB分送信する前にタイムアウトが発生してしまっていたようです。

タイムアウトを長くしても良いのですが、設定対象が多岐に渡るので、ここはチャンクサイズを5MBに調整する方向で対処します。occコマンドで設定を変更できますので、以下のコマンドを実行してチャンクサイズを変更します。

$ sudo docker-compose exec --user www-data nextcloud php occ config:app:set files max_chunk_size --value 5242880
Config value max_chunk_size for app files set to 5242880

再度ファイルをアップロードしたところ、エラーになる事無く上手く動いているようです。

NextCloudのアクセスログ管理

Nextcloudには標準で監査ログ機能があります。インターネットから接続出来る状態で運用するなら、監理者の責任としてログぐらいは残して起きたいところです。Docker上で動作させているNextCloudのログ設定をおこないます。

監査ログ出力のための設定

「Auditing / Logging」プラグインが有効になっていることを確認して下さい。標準で有効になっているはずです。

以下のコマンドを実行してログの設定をログレベル:1、タイムズーんを日本に変更します。現時点(バージョン23.0.0)では–rotate-sizeの設定は機能しません。明示的にNextcloudのLog Rotateを無効にしておき、別にlogrotateを設定する事にします。

$ sudo docker-compose exec --user www-data nextcloud php occ log:manage --level=info --timezone Asia/Tokyo
Enabled logging backend: file
Log level: Info (1)
Log timezone: Asia/Tokyo

$ sudo docker-compose exec --user www-data nextcloud php occ log:file --rotate-size=0
Log backend file: enabled
Log file: /var/www/html/data/nextcloud.log
Rotate at: disabled

これで./html/data/audit.logに監査ログが出力されるようになるはずです。

Log Rotateの設定

/etc/logrotate.d/nextcloudを以下の通り作成します。パス名の/var/docker-nextcloudは自信の環境に置き換えて下さい。

/var/docker-nextcloud/html/data/nextcloud.log {
  monthly
  rotate 12
  missingok
  notifempty
  compress
  delaycompress
  postrotate
    touch /var/docker-nextcloud/html/data/nextcloud.log
    chown www-data:www-data /var/docker-nextcloud/html/data/nextcloud.log
    chmod 640 /var/docker-nextcloud/html/data/nextcloud.log
  endscript
}

/etc/logrotate.d/nextcloudauditを以下の通り作成します。

/var/docker-nextcloud/html/data/audit.log {
  monthly
  rotate 12
  missingok
  notifempty
  compress
  delaycompress
  postrotate
    touch /var/docker-nextcloud/html/data/audit.log
    chown www-data:www-data /var/docker-nextcloud/html/data/audit.log
    chmod 640 /var/docker-nextcloud/html/data/audit.log
  endscript
}

以下の通りlogrotateデーモンを再起動します。

$ sudo service logrotate restart

以上で毎月ログが圧縮されて別ファイルとなり、12ヶ月でローテーションされます。

NextCloud設定画面のセキュリティ&セットアップ警告に対応する

NextCloudでWEBストレージサービスを自前で作成する」でNextCloudのDocker環境を構築しましたが、そのままだと設定→概要でセキュリティ警告が表示されています。消せる警告は消していきたいと思います。

信頼できるプロキシーの設定

docker-compose.ymlにTRUSTED_PROXIESとOVERWRITEHOSTを追加します。

services:
  nextcloud:
    ...
    environment:
      ...
      - TRUSTED_PROXIES=127.0.0.1
      - OVERWRITEHOST=next.code-lab.net
      - OVERWRITEPROTOCOL=https
      ...

以下のコマンドを実行して設定を反映します。

sudo docker-compose up -d

「リバースプロキシヘッダーの構成が正しくないか、信頼できるプロキシからNextcloudにアクセスしています。そうでない場合、これはセキュリティに問題があり、攻撃者がNextcloudを表示できるようにIPアドレスを偽装することができます。詳細については、ドキュメント↗をご覧ください。」の警告が消えて居ることを確認して下さい。

Strict-Transport-Securityの設定

リバースプロキシサーバーにはNginxを使用しているので、/etc/nginx/sites-available/next.code-lab.net.confを編集して「add_header Strict-Transport-Security ‘max-age=15552000; includeSubDomains; preload’;」を追加します。

server {
    ...
    add_header Strict-Transport-Security 'max-age=15552000; includeSubDomains; preload';
    ...
}

以下のコマンドを実行して設定を反映します。

sudo service nginx restart

「Strict-Transport-Security “HTTP ヘッダーの秒数が少なくとも”15552000” に設定されていません。セキュリティを強化するには、セキュリティのヒント↗で説明されているようにHSTSを有効にすることをお勧めします。」 の警告が消えて居ることを確認して下さい。

default_phone_regionの設定

./html/config/config.phpを編集してdefault_phone_regionを追加します。残念ながらDockerの環境変数から指定する事はできないようです。

<?php
$CONFIG = array (
 ...
 'default_phone_region' => 'JP',
 ...
);

以下のコマンドを実行して設定を反映します。

sudo docker-compose restart

「ご使用のシステムには、デフォルトの電話地域が設定されていません。これは、国コードなしでプロファイル設定の電話番号を検証するために必要です。国コードなしで番号を許可するには、地域のそれぞれの ISO3166-1コード↗とともに “default_phone_region” を設定ファイルに追加してください。」 の警告が消えて居ることを確認して下さい。

DBにインデックスを作成する

以下のコマンドを実行します。

$ sudo docker-compose exec --user www-data nextcloud php occ db:add-missing-indices
Check indices of the share table.
Check indices of the filecache table.
Adding additional size index to the filecache table, this can take some time...
Filecache table updated successfully.
Adding additional path index to the filecache table, this can take some time...
Filecache table updated successfully.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.

「データベースにいくつかのインデックスがありません。~」 の警告が消えて居ることを確認して下さい。

「php-imagickモジュールはSVGをサポートしていません。」の警告が残っています。Dockerイメージを更新すれば良さそうですが、メリットが薄そうなのでこの警告は容認する事とします。