また明日見直そう……

gFTPだけの問題なら良いのだけれど

うーん、Windowsのクライアントはちゃんと動いてる

モジュール版PHPじゃないって書いてあるから速度が出ない可能性はありそう

WinSCPだとそんなにもたつかずにアップロードできる

基本的に互換性向上する側にしか設定変えてないはずなんだがなあ

これはちょっと明日の朝まで掛かるかも

なんか、gFTPだと426がやたら返ってくるな

静的サイトジェネレータとかそういう系

ライトだとDBないからリッチなCMSはキツそう

Asciidocが好きなので……

Antora
https://antora.org/

要求に合ってるか分からないけど、最近Antoraっていうのが気になってる

接続テスト

とりあえずあやしげなところは直った、はず

ううん、require_ssl_reuseは現状問題起きてないから安全側にしておくかあ

vsftpd.conf(5)とにらめっこする

@kanade_lab そうですね……！
ちょっと不備が多いので、点検してまたご連絡します

デフォルトのままで挙動がおかしいのはまだにしても自分で妙な設定してハマってるのはあれなので、他に変なことしてないかちゃんと確認しませう……

多分、デフォルト077に対して、ユーザー毎にグループがある構成だから、グループは2で良いでしょうってしたんだと思うけども、そもそもumaskが022なんだから、こっちも022にしておけば良かったのだよ

つまり、local_umask = 027になってたのです

確かにftpdとhttpdは別に連携しているわけじゃないから、お互いを考慮したパーミッションになるとは限らないけど、もしそうだとしたら、それは単にサーバーの使い勝手が悪いだけ……

FTPで受け取ったファイルをファイルシステムに設置するのはサーバ側のユーザーなんだから、サーバー側の設定になるのはそれはそうなのよな……

完全に勘違いしていた……

@kanade_lab 申し訳ありません！
サーバー側でパーミッション落としてる箇所ありました。設置したファイルのパーミッション設定はサーバー側の責任です、クライアント側は対応不要でした……

というか監査ログがゴリゴリ出てたから、先ずはそれに気付こうねっていうのはそう

このアカウントは、notestockで公開設定になっていません。

まあ、依存してるライブラリのシステムコールまで把握しろってのは無理な話ではある

想像だけど、TLS通信時のアルゴリズムによって、seccompに引っ掛かる場合と引っ掛からない場合があるんじゃないかな

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

@kanade_lab 対応しました、サーバー側の問題でアップロード時にFTPのプロセスが落ちていたようです……
問題箇所を修正して、WinSCP/さとりすとどちらからもアップロードできることを確認しました。

そんなことなかった

最初のさとりすとからのアップロードでエラー吐いてたのもこれなのではって気がする

どこ見てもseccomp切れという回答しかなくて悲しみを覚えている

> * New d/patches/0060-seccomp_sandbox.patch:
> - Set default of SECCOMP_SANDBOX to 0 (Closes: #735357).

えぇ……

これか？
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735357

alarm？

システムコールの37番

恐らく、seccomp有効にしてるから、それを超えるような何らかのことをしようとしたっぽい、けれども変化点が分からん

なんかvsftpdにSIGSYSが飛んできてるな？

再現したので解析しまする

おはおは