カテゴリー
OS 社内SE

Update後にCollabora Onlineが動かなくなる

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
WRN Crash detected, will quarantine last version of …

Collabora Online ログ

原因はパッケージ”collaboraoffice”のアップデート漏れだった。

インストールは以下。

apt install coolwsd code-brand

アップグレードするときは以下。パッケージが違う・・。

apt install coolwsd code-brand collaboraoffice

このエラーで数日無駄にしてしまった・・。

カテゴリー
OS 社内SE

FreeBSD 13 Apacheの再起動が失敗する

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年みたいにすれば良いのに。

カテゴリー
OS 社内SE

FreeBSD 13.xでsshfsが動かない (解決)

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が動作するようになった。

カテゴリー
その他 社内SE

PRIMERGY TX150 S7の分解、CPU換装/メモリ換装/HDD->SSD換装

会社に古い富士通製のサーバ「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ファン
そこそこでかいCPUクーラー

CPUクーラーを外すときにRaidカードが邪魔なので外す。

CPUクーラーの横についてたRAIDカード

CPUクーラーを外したところ。

CPUが出てきた!

ヤフオクで買ったXEON X3470。X3480にしたかったのだが、自腹なのでヤフオクで2000円と安かったX3470。アルミホイルに包まれて送られてきた。

CPU換装。とりあえず、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枚しか刺さらないと思い諦めた。この時点でヤフオクの到着待ち2回発生で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はもうシラネ。

カテゴリー
その他 社内SE

システム改修:インボイス制度対応のまとめ

現在、2023年10月1日から始まるインボイス制度対応に向けて、当社でも絶賛システム改修中である。当社ではPOSから出すレシートと営業部が取引先に出す請求書が社内システムの修正対象だ。それ以外は経理が導入しているパッケージシステムで対応可能である。また、今回の修正ではインボイス制度の後にくる、2024年の電子帳簿法対応も合わせて行っている。

修正点はざっと以下だ。

  1. 交付した請求書(レシート)は保存して検索できるようにする。
  2. 登録番号や日付など法律の記載事項を請求書(レシート)に載せる。
  3. 返品などがあった場合は、返還適格請求書を発行する。
  4. 交付した請求書を修正した場合は、「修正した適格請求書」を発行する。

2と3は正直、たいした問題はない。現行のレシートや請求書のフォーマットを少し変えるだけの話だ。

問題は4の「修正した適格請求書」である。システム的なポイントは以下2点である。

  • 修正前と修正後の適格請求書は両方保存しなければならない。
  • 法律要件の記載事項以外の箇所、たとえば、単純な誤字修正(請求書の「請」の字を「正」と間違えたなど)であっても「修正した適格請求書」扱いとなる。

つまり、今後は、何か間違いを修正する場合は、元の請求書のレコードはそのまま保管しつつ、新しいレコードを修正データとして追加する必要がある。

これが当社のシステム上、非常に厄介であるし、恐らく多くの企業システムでも厄介になっていると思う。

これまでは何か間違っていたら、システム内のレコードを修正し、請求書やレシートを出し直せば、訂正された請求書が出てきていた。ものすごくシンプルで、誰もがわかりやすかった。

今後は、元のレコードと修正したレコードとに分かれるので、肌感的に分かりにくくなってしまうし、例えば、「今月の請求額」などの統計を取る際も、これまでのシンプルに全レコードを合計という形ではなく、修正前のレコードか修正後のレコードか、などを分けて考える必要が出てくる。

始めはもっとシンプルに考えていたのだが、インボイスコールセンターや国税局電話相談センターなど国税局に問い合わせをしていく中で上記が明らかになった。

この修正の何が最悪というと、この複雑な仕組みを作っても、誰も得しないことである。国税局も「修正後の適格請求書」があれば徴税は充分であり、企業側も「修正後の適格請求書」以外は使うことがない。要は、「修正前の適格請求書」を苦労して保存しておくようにしても、誰もそんなもの見ないし必要もないのである。

必要のないもののために、ものすごい労力を要することになる。特に小売りのレシートで「修正された適格請求書」なんて誰が必要とするのだろうか。元データを修正し「適格請求書」を再発行するのでも、国も企業も個人も誰も困らないのである。

恐らく、法律要件違反だとしても、「修正された適格請求書」の発行をしない、もしくは、要件には従わないと割り切る会社も多い気がする。

ただ、当社の場合、誰もコンプライアンス違反のリスクを負いたくないので、国税局の回答に従うことにした。

輪をかけて最悪なのは、営業部である。営業部は(意味不明だが)システムで生成した請求書をコピーし、エクセルや手書きで請求書を書き直している。(なぜかは不明だが)社印を押す必要がある、(なぜかは不明だが)お客様のフォーマットに合わせる必要がある、などの理由を述べられ、「お客様がそう言っている。」との伝家の宝刀に誰も逆らえず、(完全に不合理で意味不明だが)社内の力関係の都合もあり、営業部の要望は飲まざるを得ない。

これらの手作りの請求書もシステム上に保存することになり、改修箇所が当初の想定より大幅に膨らむこととなった。

せめて法令で修正前の請求書は保存しなくて良いとしてくれたら、みんな幸せになれたのにと思う。

カテゴリー
その他 社内SE

OCI:無料枠 2台目VM (VM.Standard.E2.1.Micro)をローカルネットワークに接続する

開発用にさくらインターネットの一番安い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のワーカー数を増やす。(処理が遅いので少ないワーカーではさばけなくなる。)
・ 使ってないサービスの停止

残念ながら、無料は無料です・・・。

カテゴリー
OS 社内SE

SSHでload key invalid format エラー

開発環境が複数あり、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回同じミスで時間を使うので備忘録。

カテゴリー
その他 社内SE

ActSecureクラウドメールセキュリティサービスを使ってみた話

少し古い話で恐縮だが、2020年3月から翌2021年9月にかけて、NECが提供する「ActSecureクラウドメールセキュリティサービス」を会社のメールのセキュリティとして使っていたので、その時の話をしたい。

もともとシマンテックのクラウドメールセキュリティを使っていたのだが、シマンテックが買収され、シマンテックの日本法人(と本社)が混乱、システムの年契約が更新できない事態が続いていた。

システム自体は未契約の状態のまま使えていたが、会社としては「サービス突然停止によるメールセキュリティ対策がされなくなる事態」を重視し、別のクラウドメールセキュリティサービスとして、上記のNECのサービスを利用することを決めた。

費用はシマンテックが年間25万ぐらいだったのに対し、NECは年間30万+初期費用5万と少し高いぐらいである。

実際に切り替えてわかったことは、日本のITの酷さだった。

シマンテックのサービスはWEB上でかゆいところ以上にいろいろ手が届く。メールの総量、スパムの率、誰が誰にメールをしたか、誰から誰にメールが来たか、メールサーバのログを調べる必要ほぼなくなり、しかもきれいなグラフィックで表示してくれる。誤検知で隔離されたメールも管理者のクリック一つで再配送できる。検索機能も豊富だ。

対してNECのサービスは、ログインして表示される画面は80年代かという酷さで、ログインしても対象のメールアドレスの追加ができるくらいで、ほとんど何もできない。誤検知だった場合の配慮もない。

このメールサービスを使う会社は、メールサーバを自前で持っていると思われるし、当社も自前でメールサーバを構築している。NECのサービスでやってくれることは、自前のメールサーバにセキュリティ機能を組み込めばほぼ同じことが出来る。

結局、1年ほど使って「この程度のサービスなら自前で組み込むから良い」となり、契約を打ち切った。社内からの問い合わせに対し、シマンテックのサービスならすぐ回答できたり対応できるものが、NECのサービスでは出来ない、もしくは、自分でメールサーバの大量のログと格闘しなければいけなくなったのが痛く、費用対効果が非常に薄いとの結論に至った。

それと関連は不明だが、このNECのサービスに切り替えた直後から大量のスパムが社内のいろいろなメールアドレスに届くようになった。関係ないかもしれないが、タイミングがあまりに近いため、それも契約解除の判断の遠因になった。

社内に英語ができる人間が多いため、海外のIT系サービスも検討の遡上に上がる。その際、国内のIT系のサービスのあまりの酷さに気が付き、うんざりすることがある。本件もその1つであった。

カテゴリー
その他 社内SE

“curl : リモート名を解決できませんでした。”が出た

WindowsでCURLが使えると知り、早速dos窓で「curl –version」とコマンドを打ったところ、”curl : リモート名を解決できませんでした。・・・”のエラーが出た。

curlが認識できなく、curl.exeなら認識できるらしい。「curl.exe –version」とコマンドを打ったところ素直にバージョンが表示された。

環境依存かもしれないが参考まで。

カテゴリー
OS 社内SE

Windows 7のシステムドライブをパーティションだけコピーしてHDDを入れ替えた話

家で2つほどサーバ的なものを建てている。1つはUbuntu22だが、1つはWindows 7である。Windows 7なんかやめたいのだが、録画サーバとして設置してあり、諸事情で10にもできずそのままになっている。もうほとんど録画もしていないが、稀に録画することがあり、手仕舞いできない。

そんなWin7の録画サーバの調子が悪い。HDDが古くディスクエラーが頻発しているので、SSDに乗り換えることにした。

Win7の現在のHDDの構成は300GBでCドライブに80GBを充てていて、これをWindowsの「バックアップと復元」で新しい128GBのSSDに載せ替えるつもりだったが、「ディスク容量不足」でどうしてもできない。Cドライブだけではなく、HDD全容量以上のディスクが必要らしい。あれやこれややってみたがうまく行かない。

仕方ないので、Ubuntu 22をUSBから起動(インストールディスクから「try ubuntu」)して対応した。手順としては、SSD側でfdiskでパーティション作成、HDDからSSDにパーティション単位でddコピー、SSDでWindows7起動確認後、ついでにgpartedで容量を80GBから128GBまで拡張した。

以下、備忘録として手順を示す。HDDは/dev/sda、SDDは/dev/sdbとする。

下準備

# ルートで作業
sudo su -
# なんとインストールできる!次回起動しても有効!
apt install ntfs-3g

手順1:/dev/sdaの現在のパーティション容量確認コマンド

#このコマンドの結果出てくる、/dev/sda1と/dev/sda2をコピーすることになる。
#そのため、コピー先に同じパーティション容量の/dev/sdb1と/dev/sdb2を作成する必要があるため、ここで/dev/sda1と/dev/sda2の容量を控えておく。
fdisk -l /dev/sda
# あまり覚えていないが以下のような感じで出てくる。
# 2048から9602のパーティションと96043から999999のパーティションを/dev/sdbに作成する。
/dev/sda1   *      2048      96042  123456   7  NTFS
/dev/sda2          96043     999999   123456    7  NTFS

手順2:/dev/sdbにパーティション作成。(NTFSではなく、sdb1はFAT32 (LBA))で作成する。)最後のwコマンドをするまで、実際には書き込まれないので安心して作業する。

fdisk /dev/sdb

コマンド (m でヘルプ): n 
コマンドアクション
    e   拡張
    p   基本領域 (1-4)
p # 基本pらしい

領域番号 (1-4): 1 #sda1のコピー先なので1

最初 シリンダ (1-652, default 1): 2048 # 上で控えた開始
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-652, default 652): 96042 # 上で控えた終了

# 2つ目を作成
コマンド (m でヘルプ): n
コマンドアクション
    e   拡張
    p   基本領域 (1-4)
p

領域番号 (1-4): 2 #sda2のコピー先なので2

# 上で控えた開始と終了の位置
最初 シリンダ (1-652, default 1): 96043
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-652, default 652): 9999999

コマンド (m でヘルプ): t
選択した領域 1
16進数コード (L コマンドでコードリスト表示): c # FAT32 (LBA)

コマンド (m でヘルプ): t
選択した領域 2
16進数コード (L コマンドでコードリスト表示): 7 # NTFS

# 起動パーティション指定
コマンド (m でヘルプ): a
Partition number (1-4): 1

# 現在の状況確認
コマンド (m でヘルプ): p
# なんか色々出る。

# 書き込み
コマンド (m でヘルプ): w

手順3:パーティションコピー bsオプションは値を上げればコピーが早くなるわけではないらしい。32Mとか64Mあたりでやる。

# sda1はすぐ終わる
dd bs=32M if=/dev/sda1 of=/dev/sdb1
# こっちは長い・・・
dd bs=32M if=/dev/sda2 of=/dev/sdb2

これでSSDから起動してみて起動できればOKである。NGだった場合は、fdisk -l /dev/sdbをよく見てみる。MBRの調整などは基本不要である。コピーが失敗していないか、ファイルシステムが違わないか、起動(boot)パーティションが指定されているかを確認する。

このあとはやらなくても良い(起動しなくなるリスク有り)のだが、gpartedを起動してパーティションサイズを拡張した。gpartedは必ずsudoコマンドで起動すること。

sudo gparted

GUIなので説明は割愛。対象のディスクを選んで、リサイズを選択してからドラッグしてリサイズする。

ローカルネットの中だけのサーバだが、そのうちセキュリティの問題でsambaが他のデバイスから繋がらなくなりそう。そうなったら破棄するか何かで対応しよう。。。