openlitespeedを設定していて、正しく設定していてもログが出力されない件があった。
■ 環境
Ubuntu 24.04 / OpenLiteSpeed 1.8.2
ユーザとグループをwww-dataに変更し、バーチャルホストをいくつか設定、バーチャルホストのログを、/usr/local/lsws/logsの下にファイル名を分けて出力するように設定したが、当該ログファイルは作成されるものの、ログの書き込みは行われない。
結論から言うと「/usr/local/lsws/logs」の所有者／グループも実行ユーザのwww-dataに変更すると動作するようになった。
chown -R www-data:www-data /usr/local/lsws/logs
ログファイルが作られるのと、なぜか設定していない「/usr/local/lsws/logs/access.log」にログが出力されたため、権限の問題だとは思えず、解決まで時間がかかった。
NextCloud連携用にインストールしていたCollabora Onlineを22から23にアップデートしたところ、NextCloudでオフィス系ファイルを開くと以下のようなエラーが出てくるようになった。(Ubuntu 22.04)
Failed to establish socket connection or socket connection closed unexpectedly.
NextCloud error
Collabora Onlineのログを見るとエラーは出ていないものの以下のwarningが出ている。
WRN Successfully sent ‘segfaultcount’ message segfaultcount 1
Collabora Online ログ
WRN Crash detected, will quarantine last version of …
原因はパッケージ”collaboraoffice”のアップデート漏れだった。
インストールは以下。
apt install coolwsd code-brand
アップグレードするときは以下。パッケージが違う・・。
apt install coolwsd code-brand collaboraoffice
このエラーで数日無駄にしてしまった・・。
apachectl restartはOKだが、apachectl reloadやapachectl gracefulなどは停止したまま起動しなくなる。mod_phpでopcacheを使用している場合に発生するバグらしい。
翌日気が付くとApacheが”なぜか”停止している。調べてもわからず、落ちたら起動するプログラムを組んで、落ちた時間を調べてみると”newsyslog”でログがローテートされたタイミングでおち、”letsencrypt”のcertbotのチェックのタイミングで落ちていた。
“newsyslog”では、httpd.pidにシグナル(30 SIGUSR1)を送る形で再起動しており、apachectlも内部的には同じようにシグナルを送って操作しているらしいので、いろいろググっていると以下のバグレポートを発見。
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268318
仕方ないので、”newsyslog”の設定のお尻からシグナルを送る部分である”/var/run/httpd.pid 30″を削除し、syslogを実行した後の時間あたりでcronを使って以下のコマンドをたたくように変更した。
/usr/local/etc/rc.d/apache24 gracefulstop && /usr/local/etc/rc.d/apache24 start
ログのローテートまでシェルで書けば良いのだが、virtual hostの設定毎にログを分けているため、テストするのも面倒＆そのうちバグフィックスされるまでのつなぎと思い、上の仮対応で良しとした。
certbotもpost-hookのとこを上記に変更した。
FreeBSDのApacheはWEBサイト表示では最速だと思っているが、サポート期間が短く、ギリギリまで放置すると3ヵ月毎にOSのアップグレードが発生する。数回再起動しなければならないうえ、こういうバグ対応まで考えると保守性は低い。ubuntuみたいに無償5年、有償10年みたいにすれば良いのに。
FreeBSD 12.4 => 13.2にアップグレードしたところ、sshfsが動作しなくなってしまった。sshfsでマウントすると以下のようなエラーが出る。
# sshfs -o allow_other,default_permissions,uid=1001,gid=1001 XXXX XXXXX fuse: failed to open fuse device: No such file or directory
kldstatで見るとfuse.koが無い。ロードしようとしてもエラー。
# kldload fuse.ko kldload: can't load fuse.ko: No such file or directory
13.xからfuse.koはなくなり、fusefs.koになったらしい。とりあえず、fusefs-sshfsとfusefs-libsを再インストールし、/boot/loader.confと/etc/rc.confを修正＆再起動。（再起動しなくても”kldload fusefs.ko”でOKだったがconf系の動作確認で再起動）
pkg -y install fusefs-sshfs fusefs-libs vi /boot/loader.conf --- # 追加 fusefs_load="YES" --- vi /etc/rc.conf --- # 追加 enable_fusefs="YES" ---
これでsshfsが動作するようになった。
会社に古い富士通製のサーバ「PRIMERGY TX150 S7」がある。
スペックは以下。
CPU : XEON X3430(4コア 4スレッド)
メモリ : 4GB
ストレージ : HDD RAID1 500GB
これを以下にする。
CPU : XEON X3470(4コア 8スレッド)
メモリ : 16GB
ストレージ : SSD RAID1 1TB
下の画像がサーバのサイドパネルを開いたところである。ネジ外しも不要で緑の箇所を動かせば、各ユニットが外れる設計となっており、作業はとてもやりやすい。
CPUファンとクーラー。CPUファンはメモリやRaidカードまで冷やすようになっている。外すときはファンの電源ケーブルに注意するくらいでこれも簡単。
CPUクーラーを外すときにRaidカードが邪魔なので外す。
CPUクーラーを外したところ。
ヤフオクで買ったXEON X3470。X3480にしたかったのだが、自腹なのでヤフオクで2000円と安かったX3470。アルミホイルに包まれて送られてきた。
CPU換装。とりあえず、CPUだけ変えて動作確認。問題なし。
次はメモリ。メモリは結局16GBではなく8GBとなった。スペック表には「4GB DDR3 1333 UDIMM」対応と書いている。UDIMMが何なのかわからないが、サーバ用のRDIMMじゃないから、多分PC用のメモリでも動くのね！と喜んで、PC用の4GB DDR3 1333の新品4枚を5000円ぐらいで購入。動かず。今更DDR3の4GB 1333なんてPCでも使わないので、動かなかった時点でゴミ決定。まさに無駄。
新品を買うお金がなくなったので、ヤフオクで「4GB × 4 ECC Registered DDR3 1066」を2000円ぐらいで買う。写真を撮らなかったがこれも動かず、またもゴミ確定。メモリが悪いのか、相性なのかわからないが、とりあえず出品者は最高評価にしておいた。
ちなみにこのメモリを1枚づつ挿して、動作確認していた際に電源を落とさずにメモリを引っこ抜く失態。突然電源が落ち、何かショートしたかと思ったが起動して一安心。
困ったので、今ついているメモリと同じ型番のメモリをヤフオクで探し「2GB × 2 ECC Registered DDR3 1066」を送料込みの500円で買う。ネコポスで届くが、出品者は利益あるのかなど色々不安。問題なく動く。当然出品者は最高評価。
2スロット余っているので、できればもう2枚つけて12GBにしたいが、仕様書に「UDIMM×4、1066 RDIMM×4もしくは1333 RDIMM×6まで搭載可能」とあるので、4枚しか刺さらないと思い諦めた。この時点でヤフオクの到着待ち２回発生で4回ぐらいサーバを開いて汗だくで自腹切りまくりなので「もういいや」状態。
ここから先は写真を撮るのを忘れたので文章だけになるが、このサーバー、フロントパネルを外してHDDマウンタの取ってを引っ張ると、HDDを簡単に引っこ抜ける。素晴らしいが、3.5インチのみ対応。なので、今回買った2.5インチSSDはそもそもこのサーバのマウンタが付かない。2.5->3.5インチ変換マウンタをかませてみたが無理。
とりあえず、2.5インチSSDをSATAソケットに差し込む。軽いので宙ぶらりんだが何とかいけそう。なので、今回ゴミになったメモリの入っていたケースをSSDの下にテープで貼って高さを出すと宙ぶらりんも解消した。とりあえずこれで良いや。
誤算はハードウェアRaid1にしたかったのだが、どうもWindowsかRedhatからしかRaidカードが制御できないっぽい。仕方ないのでUbuntuのインストール時にソフトウェアRaidにした。10年選手のHDD500GBはハードウェアRaidが動いているっぽいので、バックアップ用としてマウント。
サーバは、Ubuntu + samba 4でADサーバに生まれ変わり。オフィスに30人しかいない小売の中小企業が使うには充分でしょう。Ubuntuに感謝。Redhatはもうシラネ。
現在、2023年10月1日から始まるインボイス制度対応に向けて、当社でも絶賛システム改修中である。当社ではPOSから出すレシートと営業部が取引先に出す請求書が社内システムの修正対象だ。それ以外は経理が導入しているパッケージシステムで対応可能である。また、今回の修正ではインボイス制度の後にくる、2024年の電子帳簿法対応も合わせて行っている。
修正点はざっと以下だ。
２と３は正直、たいした問題はない。現行のレシートや請求書のフォーマットを少し変えるだけの話だ。
問題は４の「修正した適格請求書」である。システム的なポイントは以下2点である。
つまり、今後は、何か間違いを修正する場合は、元の請求書のレコードはそのまま保管しつつ、新しいレコードを修正データとして追加する必要がある。
これが当社のシステム上、非常に厄介であるし、恐らく多くの企業システムでも厄介になっていると思う。
これまでは何か間違っていたら、システム内のレコードを修正し、請求書やレシートを出し直せば、訂正された請求書が出てきていた。ものすごくシンプルで、誰もがわかりやすかった。
今後は、元のレコードと修正したレコードとに分かれるので、肌感的に分かりにくくなってしまうし、例えば、「今月の請求額」などの統計を取る際も、これまでのシンプルに全レコードを合計という形ではなく、修正前のレコードか修正後のレコードか、などを分けて考える必要が出てくる。
始めはもっとシンプルに考えていたのだが、インボイスコールセンターや国税局電話相談センターなど国税局に問い合わせをしていく中で上記が明らかになった。
この修正の何が最悪というと、この複雑な仕組みを作っても、誰も得しないことである。国税局も「修正後の適格請求書」があれば徴税は充分であり、企業側も「修正後の適格請求書」以外は使うことがない。要は、「修正前の適格請求書」を苦労して保存しておくようにしても、誰もそんなもの見ないし必要もないのである。
必要のないもののために、ものすごい労力を要することになる。特に小売りのレシートで「修正された適格請求書」なんて誰が必要とするのだろうか。元データを修正し「適格請求書」を再発行するのでも、国も企業も個人も誰も困らないのである。
恐らく、法律要件違反だとしても、「修正された適格請求書」の発行をしない、もしくは、要件には従わないと割り切る会社も多い気がする。
ただ、当社の場合、誰もコンプライアンス違反のリスクを負いたくないので、国税局の回答に従うことにした。
輪をかけて最悪なのは、営業部である。営業部は（意味不明だが）システムで生成した請求書をコピーし、エクセルや手書きで請求書を書き直している。（なぜかは不明だが）社印を押す必要がある、（なぜかは不明だが）お客様のフォーマットに合わせる必要がある、などの理由を述べられ、「お客様がそう言っている。」との伝家の宝刀に誰も逆らえず、（完全に不合理で意味不明だが）社内の力関係の都合もあり、営業部の要望は飲まざるを得ない。
これらの手作りの請求書もシステム上に保存することになり、改修箇所が当初の想定より大幅に膨らむこととなった。
せめて法令で修正前の請求書は保存しなくて良いとしてくれたら、みんな幸せになれたのにと思う。
開発用にさくらインターネットの一番安いVPSプラン(512M)を使っていたのだが、メモリが少なすぎてubuntu 22.04にアップグレードできない。仕方ないのでOracle cloudの無料枠でVM.Standard.E2.1.Microを立ち上げてそちらに移行することにした。が、実際に移行してみるととても重い。
■ UnixBenchの結果
さくら 512M => 1674.1
OCI VM.Standard.E2.1.Micro => 504
1/3の性能しかない・・・。さくらは1CPU/メモリ512MB、OCIは2CPU/メモリ1GBなのに、1/3の性能しかない・・・。CPUの処理速度、メモリアクセス速度、ディスクアクセス速度、全てがさくらより遅い。
しかたないので、無料枠で2台目を立ち上げ、そこにDBを移動することにした。各VMに2枚目のNICを追加して、そこにローカルネットワークを構築するイメージでいたのだが、どうもOCIは違うらしい。
考えても仕方ないので、1台目と同じようにインスタンスを作成し、 Networkingの設定の場所で
=> 1台目で使ったものと同じVNICを選択
=> Assign a public IPv4 addressをチェック
=> Show advanced optionsを選択
=> Private IP addressに適当なIPアドレスを指定（10.0.0.20など）
としたところ、1台目のVMから10.0.0.20宛てで接続可能であった。（ちょっと不思議だが、割り当てたpublic IPからも接続可能である。）
ただし、2台間で特定の通信をするにはIngress ruleにルールを追加する必要があった。今回はmariaDB(mysql)だったので、sorceに10.0.0.0/16を指定して、宛先Port3306で登録したところ通信できるようになった。
ちなみに、それでも重かったため、1台目のサーバで以下を行ったところ、大分使える範囲まで落ち着いた。
・swapの追加 (OCIのubuntuのイメージにはswapがない。)
・nginxやopnelitespeedのワーカー数を増やす。（処理が遅いので少ないワーカーではさばけなくなる。）
・ 使ってないサービスの停止
残念ながら、無料は無料です・・・。
開発環境が複数あり、ssh keyは使いまわしている。今回もWindowsで使っていたssh keyをたまに使うLinux環境(ChromeOS)にコピーして、SSHしたところ「load key “/home/xxxxxx/.ssh/test03/id_rsa” : invalid format」で”Permission denied (publickey).”となった。
結論から言うと、keyファイルの改行コードがCRLFとなっていて、LFに直したら動作した。
vimで修正するには
:e ++ff=unix :%s/^M//g # ^Mは[Ctrl] ＋ [V] キーを押してから、[Ctrl] ＋ [M] キーを押せば入力可能
何年かに1回同じミスで時間を使うので備忘録。
少し古い話で恐縮だが、2020年3月から翌2021年9月にかけて、NECが提供する「ActSecureクラウドメールセキュリティサービス」を会社のメールのセキュリティとして使っていたので、その時の話をしたい。
もともとシマンテックのクラウドメールセキュリティを使っていたのだが、シマンテックが買収され、シマンテックの日本法人（と本社）が混乱、システムの年契約が更新できない事態が続いていた。
システム自体は未契約の状態のまま使えていたが、会社としては「サービス突然停止によるメールセキュリティ対策がされなくなる事態」を重視し、別のクラウドメールセキュリティサービスとして、上記のNECのサービスを利用することを決めた。
費用はシマンテックが年間25万ぐらいだったのに対し、NECは年間30万＋初期費用5万と少し高いぐらいである。
実際に切り替えてわかったことは、日本のITの酷さだった。
シマンテックのサービスはWEB上でかゆいところ以上にいろいろ手が届く。メールの総量、スパムの率、誰が誰にメールをしたか、誰から誰にメールが来たか、メールサーバのログを調べる必要ほぼなくなり、しかもきれいなグラフィックで表示してくれる。誤検知で隔離されたメールも管理者のクリック一つで再配送できる。検索機能も豊富だ。
対してNECのサービスは、ログインして表示される画面は８０年代かという酷さで、ログインしても対象のメールアドレスの追加ができるくらいで、ほとんど何もできない。誤検知だった場合の配慮もない。
このメールサービスを使う会社は、メールサーバを自前で持っていると思われるし、当社も自前でメールサーバを構築している。NECのサービスでやってくれることは、自前のメールサーバにセキュリティ機能を組み込めばほぼ同じことが出来る。
結局、1年ほど使って「この程度のサービスなら自前で組み込むから良い」となり、契約を打ち切った。社内からの問い合わせに対し、シマンテックのサービスならすぐ回答できたり対応できるものが、NECのサービスでは出来ない、もしくは、自分でメールサーバの大量のログと格闘しなければいけなくなったのが痛く、費用対効果が非常に薄いとの結論に至った。
それと関連は不明だが、このＮＥＣのサービスに切り替えた直後から大量のスパムが社内のいろいろなメールアドレスに届くようになった。関係ないかもしれないが、タイミングがあまりに近いため、それも契約解除の判断の遠因になった。
社内に英語ができる人間が多いため、海外のIT系サービスも検討の遡上に上がる。その際、国内のIT系のサービスのあまりの酷さに気が付き、うんざりすることがある。本件もその１つであった。
WindowsでCURLが使えると知り、早速dos窓で「curl –version」とコマンドを打ったところ、”curl : リモート名を解決できませんでした。・・・”のエラーが出た。
curlが認識できなく、curl.exeなら認識できるらしい。「curl.exe –version」とコマンドを打ったところ素直にバージョンが表示された。
環境依存かもしれないが参考まで。