No.14, No.13, No.12, No.11, No.10, No.9, No.8［7件］
現在、自鯖本を電子書籍か何かで出そうかなって格闘しているけれど、内容をここのサイトに適宜載せていくか悩み中。
因みにもしも載せるとなったら、コマンド系の表示用CSSを頑張って作らなきゃなぁ（遠い目）ってのが一番のネックになってる。
【追記】
現時点で表に出せそうなものをnote記事にしたら6つも記事を増やすことになって大草原。
因みにもしも載せるとなったら、コマンド系の表示用CSSを頑張って作らなきゃなぁ（遠い目）ってのが一番のネックになってる。
【追記】
現時点で表に出せそうなものをnote記事にしたら6つも記事を増やすことになって大草原。
絵文字3つ追加
配布絵文字におやつシリーズを追加し、3種類のおやつを追加しました。
#おやつ
配布絵文字におやつシリーズを追加し、3種類のおやつを追加しました。
#おやつ
絵文字1つ追加
文字系絵文字に絵文字を1つ追加しました。
#文字系絵文字
文字系絵文字に絵文字を1つ追加しました。
#文字系絵文字
そう言えば、最近はゆるっと鯖缶情報まとめをひっそり運用してますが、わーさんの独断と偏見で、わーさんまで流れてきた鯖缶情報網からのアレコレをゆるっと投げてますので、鍵運用です。
わーさんが信用してないと、フォロー承認されません。拡散防止のため、現在は基本的にフォロワー限定投稿しかしてません。
中身が気になる方は、一回わーさんの本体に聞いてみましょう。そこで該当スクショが出てきたら、フォロー申請も承諾される可能性が高いです。
わーさんが信用してないと、フォロー承認されません。拡散防止のため、現在は基本的にフォロワー限定投稿しかしてません。
中身が気になる方は、一回わーさんの本体に聞いてみましょう。そこで該当スクショが出てきたら、フォロー申請も承諾される可能性が高いです。
SNS共有ボタン群およびリンク集への追加
MaMiShareさんを利用して、トップページと当チラシ裏に各種SNSなどへの共有ボタン群を設置してみました。
チラシ裏で個別の記事にリンクを貼りたい場合は、記事の日付から個別記事に飛んだ上で共有ボタンを利用すると便利です。
MaMiShareさんについては、リンク集にもリンクを作成しました。
#わーさんがやってみた
MaMiShareさんを利用して、トップページと当チラシ裏に各種SNSなどへの共有ボタン群を設置してみました。
チラシ裏で個別の記事にリンクを貼りたい場合は、記事の日付から個別記事に飛んだ上で共有ボタンを利用すると便利です。
MaMiShareさんについては、リンク集にもリンクを作成しました。
#わーさんがやってみた
kmyblue引っ越してみたメモ
例によって長いので、畳みます。
後ほど、先達さんも記事を上げてくれるらしいです、楽しみ。
#わーさんがやってみた
kmyblueサーバー移行 やったこと
* 新鯖にkmyblueを新規インストール(参照0)して、mastodon:setup開始直前まで進める(mastodon:setupは行わない、データベースユーザーmastodonのパスワードは念のため旧鯖にそろえる)
* 旧鯖止める(参照1)
* .env.productionを移行(live下隠しファイル)
* バックアップするべき容量を減らす(参照2)
* Postgresのダンプとロードを行う(参照3)
* 旧鯖のローカルファイルを圧縮、新鯖に持って行って解凍(参照4)
* RAILS_ENV=production bundle exec rails assets:precompile を実行し、Mastodon をコンパイル
* 各ユーザーのホームタイムラインを再構築するために RAILS_ENV=production ./bin/tootctl feeds build を実行(しなかったので、タイムライン消えまくりｗ)
* 新しいサーバーでマストドンを起動
* DNS 設定を更新
* Nginxの設定を更新またはコピーし、必要に応じてLetsEncryptを再実行(参照0に則って新規設定し直ししたが、参照5を試しても良かった)
参照0
https://github.com/kmycode/mastodon/wiki/Installation
参照1
sudo systemctl stop mastodon-{web,sidekiq,streaming}
参照2
# どのファイルが容量を食っているのか算出
RAILS_ENV=production bundle exec bin/tootctl media usage
# 過去の投稿を削除。日数は適宜調整
RAILS_ENV=production bundle exec bin/tootctl status remove --days=90
# プレビューカードを削除。日数は適宜調整
RAILS_ENV=production bundle exec bin/tootctl preview_cards remove --days=180
# リモートメディアを削除
RAILS_ENV=production bundle exec bin/tootctl media remove --days=0
# 孤立メディアを削除
RAILS_ENV=production bundle exec bin/tootctl media remove-orphans
参照3
mastodon:setup を実行する代わりに、template0 データベースを使用して空の Postgres データベースを作成 。
(これは Postgres のダンプをリストアするときに便利だそう。pg_dump のドキュメントに記載)
古いシステムの mastodon ユーザーで以下を実行。
pg_dump -Fc mastodon_production -f backup.dump
rsync または scp を使って backup.dump ファイルをコピー。
次に、新しいシステムで mastodon ユーザで空のデータベースを作成。
createdb -T template0 mastodon_production
そして、コピーしたバックアップをインポート。
（念のため、旧鯖と同じ位置にインポート、ユーザー権限やパーミッションもそろえておく）
chown --recursive mastodon: /home/mastodon/backup.dump
chmod 664 /home/mastodon/backup.dump
pg_restore -Fc -U mastodon -n public --no-owner --role=mastodon \
-d mastodon_production backup.dump
(新しいサーバでユーザ名が mastodon でない場合、上記の -U と --role の値を変更する必要があることに注意。なお、2つのサーバ間でユーザ名が異なっていても問題ない模様)
参照4
旧鯖にて
tar czf systemfiles.tar.gz /home/mastodon/live/public/system
これが作業ユーザーに入ったら新鯖に持っていく
解凍は（必要に応じてsudo入れつつ）
tar -xvf systemfiles.tar.gz
すると作業ユーザーの下に新たにhomeから増えたので、以下で持っていく（指定なければ作業ディレクトリ内の解凍らしいので、移動前パスは適宜探してください）
sudo mv /home/(ユーザ名)/home/mastodon/live/public/system /home/mastodon/live/public/.
参照5
Let's Encrypt SSL証明書の再発行
移行先サーバにて、 Let's Encrypt SSL証明書の再発行を行う。
sudo certbot certonly --standalone -d yourdomain.tld
(SSL証明書そのものをコピーしてこればいい説もあるが。。。)
Nginx の起動
↓ 一般ユーザ作業
# SSL証明書が正しく取得・インストールされていれば、問題なく立ち上がる
sudo systemctl start nginx
sudo systemctl start mastodon-{web,sidekiq,streaming}
参考サイト
https://github.com/kmycode/mastodon/wiki/Installation
https://dolphilia.com/translation/mastodon/running/migrating
https://qiita.com/neustrashimy/items/520838806e4524b229b9
後で発見したサイト
https://www.nan1.casa/blog/2023-06-12-backup-mastodon/
畳む
例によって長いので、畳みます。
後ほど、先達さんも記事を上げてくれるらしいです、楽しみ。
#わーさんがやってみた
kmyblueサーバー移行 やったこと
* 新鯖にkmyblueを新規インストール(参照0)して、mastodon:setup開始直前まで進める(mastodon:setupは行わない、データベースユーザーmastodonのパスワードは念のため旧鯖にそろえる)
* 旧鯖止める(参照1)
* .env.productionを移行(live下隠しファイル)
* バックアップするべき容量を減らす(参照2)
* Postgresのダンプとロードを行う(参照3)
* 旧鯖のローカルファイルを圧縮、新鯖に持って行って解凍(参照4)
* RAILS_ENV=production bundle exec rails assets:precompile を実行し、Mastodon をコンパイル
* 各ユーザーのホームタイムラインを再構築するために RAILS_ENV=production ./bin/tootctl feeds build を実行(しなかったので、タイムライン消えまくりｗ)
* 新しいサーバーでマストドンを起動
* DNS 設定を更新
* Nginxの設定を更新またはコピーし、必要に応じてLetsEncryptを再実行(参照0に則って新規設定し直ししたが、参照5を試しても良かった)
参照0
https://github.com/kmycode/mastodon/wiki/Installation
参照1
sudo systemctl stop mastodon-{web,sidekiq,streaming}
参照2
# どのファイルが容量を食っているのか算出
RAILS_ENV=production bundle exec bin/tootctl media usage
# 過去の投稿を削除。日数は適宜調整
RAILS_ENV=production bundle exec bin/tootctl status remove --days=90
# プレビューカードを削除。日数は適宜調整
RAILS_ENV=production bundle exec bin/tootctl preview_cards remove --days=180
# リモートメディアを削除
RAILS_ENV=production bundle exec bin/tootctl media remove --days=0
# 孤立メディアを削除
RAILS_ENV=production bundle exec bin/tootctl media remove-orphans
参照3
mastodon:setup を実行する代わりに、template0 データベースを使用して空の Postgres データベースを作成 。
(これは Postgres のダンプをリストアするときに便利だそう。pg_dump のドキュメントに記載)
古いシステムの mastodon ユーザーで以下を実行。
pg_dump -Fc mastodon_production -f backup.dump
rsync または scp を使って backup.dump ファイルをコピー。
次に、新しいシステムで mastodon ユーザで空のデータベースを作成。
createdb -T template0 mastodon_production
そして、コピーしたバックアップをインポート。
（念のため、旧鯖と同じ位置にインポート、ユーザー権限やパーミッションもそろえておく）
chown --recursive mastodon: /home/mastodon/backup.dump
chmod 664 /home/mastodon/backup.dump
pg_restore -Fc -U mastodon -n public --no-owner --role=mastodon \
-d mastodon_production backup.dump
(新しいサーバでユーザ名が mastodon でない場合、上記の -U と --role の値を変更する必要があることに注意。なお、2つのサーバ間でユーザ名が異なっていても問題ない模様)
参照4
旧鯖にて
tar czf systemfiles.tar.gz /home/mastodon/live/public/system
これが作業ユーザーに入ったら新鯖に持っていく
解凍は（必要に応じてsudo入れつつ）
tar -xvf systemfiles.tar.gz
すると作業ユーザーの下に新たにhomeから増えたので、以下で持っていく（指定なければ作業ディレクトリ内の解凍らしいので、移動前パスは適宜探してください）
sudo mv /home/(ユーザ名)/home/mastodon/live/public/system /home/mastodon/live/public/.
参照5
Let's Encrypt SSL証明書の再発行
移行先サーバにて、 Let's Encrypt SSL証明書の再発行を行う。
sudo certbot certonly --standalone -d yourdomain.tld
(SSL証明書そのものをコピーしてこればいい説もあるが。。。)
Nginx の起動
↓ 一般ユーザ作業
# SSL証明書が正しく取得・インストールされていれば、問題なく立ち上がる
sudo systemctl start nginx
sudo systemctl start mastodon-{web,sidekiq,streaming}
参考サイト
https://github.com/kmycode/mastodon/wiki/Installation
https://dolphilia.com/translation/mastodon/running/migrating
https://qiita.com/neustrashimy/items/520838806e4524b229b9
後で発見したサイト
https://www.nan1.casa/blog/2023-06-12-backup-mastodon/
畳む
Spam attack on Twitter/X rival Mastodon highlights ‘fediverse’ vulnerabilities 和訳挑戦
元サイト： https://techcrunch.com/2024/02/20/spam-attack-on-twitter-x-rival-mastodon-highlights-fediverse-vulne...
かなり大雑把な翻訳ですが、長くなるので畳みます。
なお、個人的には、繊細な方には続きを読むことはオススメしません。語気強い方々の意見も出てましたので。
ついでに、元記事そのものが本当に正しいことを書いているのか、についても各々で精査をお願いしたいところ……（わーさんが読んだ範囲だけでも色々怪しい）
そんなわけで、
【めっちゃ雑な要約】スパム湧いたよ、みんなちゃんと戸締まりしようね！
Twitter/XのライバルであるMastodonにスパム攻撃がおこなれ、「フェディバース」の脆弱性が浮き彫りになる
スパムによる攻撃がMastodonやMisskeyなどのフェディバースを襲った。ここ数日では、攻撃者はMastodonの、主に小規模サーバーを対象として、登録が開放されているのを良いことに自動でスパムアカウントを作成し続けた。Mastodonの創設者、兼CEOであるEugen Rochko氏は、週末にこの攻撃について言及し、Mastodonサーバーの管理者たちに対し、登録を承認制にすることと使い捨てアドレスのプロバイダーをブロックすることが問題解決の助けになると述べた。
フェディバースがスパム攻撃に晒されるのは初めてではないとはいえ、Rochko氏が言うには、今まではMastodon.socialのような大規模サーバーのみが標的とされることがほとんどで、しかもMastodon.socialは開発陣によるサーバーであるため、自ら攻撃を凌ぐことができていた。しかし今回は小規模の、むしろ放置されているようなサーバーが狙われたため、急激なスパムアカウントの登録とスパム投稿が可能となった。
（訳註：元記事ではここに、該当投稿のスクリーンショット。上記の他、Rochko氏は、MastodonがhCaptchaも使えることを述べている）
このスクリプトにより全自動化されたスパム攻撃は、Discord上の紛争に端を発している。Mastodonのレポートによると、Discord上のとあるサーバーをBANさせようとしたようだ。（訳註：リンク先はMisskey系のサーバーの投稿で、内容も、Discordのbotに損害を与えられたのが発端らしいと書いている模様）攻撃の対象はMastodonにとどまらず、Misskeyにも及んだ。スパムの文章が最初は日本語であったことから、日本でも多くの攻撃が行われた。
スパムによる攻撃は、フェディバースの構造上の脆弱性の1つを浮き彫りにした。Mastodonはソースが公開されており、誰でも自分のサーバーを立て、連合できるようになっている。
小規模サーバーの多くは愛好家が趣味で立てるため、このようなスパム攻撃に対して対策が後手に回ることになった。普段からサーバーの状態に注意を払わず、登録も公開していた管理者のサーバーが、スパムの踏み台になったのである。
自身もサーバーの管理者である@Chris@mastodon.cosmicnation.coは、次のように言及した。
「今回のことで、自分がサーバーを持っていたと思い出した管理者もいる。更に、まだまだ多くの無防備な放置サーバーの存在があることがわかったんだ」
ここ数日で、サーバー管理者たちは協力しあって、サーバーをスパムから守るブロックリスト作成の助けとなればと、放置サーバーのリストを作成した。また、多くのサーバーが管理者の判断により攻撃が止まるまで連合を切る（訳註：鎖国する）こととなった。
Tapbotsによる有名なMastodonサードパーティアプリのIvoryは、緊急アップデートによりスパムらしきメンションを弾くフィルターを実装したが、それでもプッシュ通知はどうにもできなかったとのことである。
スパム攻撃は今朝方から収束に向かっているようにも見え、この4日間の中で初めてスパムアカウントの凍結数が40を下回ったと報告する管理者もいる。MastodonがTechCrunch（訳註：記事の発行元）に言うには、活動している管理者、もしくはモデレーションチームの有効なサーバーであれば、Mastodonには自動アカウント作成を防ぐようなツールが多くある。その中には承認制やCAPTCHA、ブロックのための豊富な設定が含まれるため、素早く対応できたのであろうと。また、今回の騒ぎの発端となった紛争が収まりつつあることも影響しているだろうとのことであった。
フェディバースの脆弱性が明らかになったことで、さらなる対応策ができると前向きに考える人もいる一方で、Rochko氏がスパム攻撃の始まった頃に反応しなかったことを腹立たしく思っている人もいる。サーバー管理者の中には、諦めたくなった人もいたようだ。
MastodonのCTOであるRenaud Chaput氏は、攻撃を受けることでソフトウェアは堅牢に洗練されていくのだという見解を示した。
「現状、この問題はアプリに何かを組み込むことでサクッと解決するようなものではないが（何せフェディバースの連合は複雑なので！）、ソフトウェアの改善は続けていく。また、デフォルトで登録を公開状態にしないようにする、登録を公開するときには管理人に対し、しっかりとモデレーションする必要があるなどの、慎重な判断を促す注意文を表示するといった対策をとっていくつもりだ」
Instagram Threadsが登場し、Actibity Pubにも連合予定なことでMastodonの使用率は落ちてきていた。昨年の10月に180万あった活動的なアカウントは、Threadsの公開と共に150万、Blueskyの公開で100万まで落ち込んでいる。フェディバース全体ではおよそ290万ほどの活動的なアカウントがあるが、今後ここにThreadsが参入することでスパム予防への期待がある一方、Metaに乗っ取られるのではという心配の声も多数ある。
畳む
元サイト： https://techcrunch.com/2024/02/20/spam-attack-on-twitter-x-rival-mastodon-highlights-fediverse-vulne...
かなり大雑把な翻訳ですが、長くなるので畳みます。
なお、個人的には、繊細な方には続きを読むことはオススメしません。語気強い方々の意見も出てましたので。
ついでに、元記事そのものが本当に正しいことを書いているのか、についても各々で精査をお願いしたいところ……（わーさんが読んだ範囲だけでも色々怪しい）
そんなわけで、
【めっちゃ雑な要約】スパム湧いたよ、みんなちゃんと戸締まりしようね！
Twitter/XのライバルであるMastodonにスパム攻撃がおこなれ、「フェディバース」の脆弱性が浮き彫りになる
スパムによる攻撃がMastodonやMisskeyなどのフェディバースを襲った。ここ数日では、攻撃者はMastodonの、主に小規模サーバーを対象として、登録が開放されているのを良いことに自動でスパムアカウントを作成し続けた。Mastodonの創設者、兼CEOであるEugen Rochko氏は、週末にこの攻撃について言及し、Mastodonサーバーの管理者たちに対し、登録を承認制にすることと使い捨てアドレスのプロバイダーをブロックすることが問題解決の助けになると述べた。
フェディバースがスパム攻撃に晒されるのは初めてではないとはいえ、Rochko氏が言うには、今まではMastodon.socialのような大規模サーバーのみが標的とされることがほとんどで、しかもMastodon.socialは開発陣によるサーバーであるため、自ら攻撃を凌ぐことができていた。しかし今回は小規模の、むしろ放置されているようなサーバーが狙われたため、急激なスパムアカウントの登録とスパム投稿が可能となった。
（訳註：元記事ではここに、該当投稿のスクリーンショット。上記の他、Rochko氏は、MastodonがhCaptchaも使えることを述べている）
このスクリプトにより全自動化されたスパム攻撃は、Discord上の紛争に端を発している。Mastodonのレポートによると、Discord上のとあるサーバーをBANさせようとしたようだ。（訳註：リンク先はMisskey系のサーバーの投稿で、内容も、Discordのbotに損害を与えられたのが発端らしいと書いている模様）攻撃の対象はMastodonにとどまらず、Misskeyにも及んだ。スパムの文章が最初は日本語であったことから、日本でも多くの攻撃が行われた。
スパムによる攻撃は、フェディバースの構造上の脆弱性の1つを浮き彫りにした。Mastodonはソースが公開されており、誰でも自分のサーバーを立て、連合できるようになっている。
小規模サーバーの多くは愛好家が趣味で立てるため、このようなスパム攻撃に対して対策が後手に回ることになった。普段からサーバーの状態に注意を払わず、登録も公開していた管理者のサーバーが、スパムの踏み台になったのである。
自身もサーバーの管理者である@Chris@mastodon.cosmicnation.coは、次のように言及した。
「今回のことで、自分がサーバーを持っていたと思い出した管理者もいる。更に、まだまだ多くの無防備な放置サーバーの存在があることがわかったんだ」
ここ数日で、サーバー管理者たちは協力しあって、サーバーをスパムから守るブロックリスト作成の助けとなればと、放置サーバーのリストを作成した。また、多くのサーバーが管理者の判断により攻撃が止まるまで連合を切る（訳註：鎖国する）こととなった。
Tapbotsによる有名なMastodonサードパーティアプリのIvoryは、緊急アップデートによりスパムらしきメンションを弾くフィルターを実装したが、それでもプッシュ通知はどうにもできなかったとのことである。
スパム攻撃は今朝方から収束に向かっているようにも見え、この4日間の中で初めてスパムアカウントの凍結数が40を下回ったと報告する管理者もいる。MastodonがTechCrunch（訳註：記事の発行元）に言うには、活動している管理者、もしくはモデレーションチームの有効なサーバーであれば、Mastodonには自動アカウント作成を防ぐようなツールが多くある。その中には承認制やCAPTCHA、ブロックのための豊富な設定が含まれるため、素早く対応できたのであろうと。また、今回の騒ぎの発端となった紛争が収まりつつあることも影響しているだろうとのことであった。
フェディバースの脆弱性が明らかになったことで、さらなる対応策ができると前向きに考える人もいる一方で、Rochko氏がスパム攻撃の始まった頃に反応しなかったことを腹立たしく思っている人もいる。サーバー管理者の中には、諦めたくなった人もいたようだ。
MastodonのCTOであるRenaud Chaput氏は、攻撃を受けることでソフトウェアは堅牢に洗練されていくのだという見解を示した。
「現状、この問題はアプリに何かを組み込むことでサクッと解決するようなものではないが（何せフェディバースの連合は複雑なので！）、ソフトウェアの改善は続けていく。また、デフォルトで登録を公開状態にしないようにする、登録を公開するときには管理人に対し、しっかりとモデレーションする必要があるなどの、慎重な判断を促す注意文を表示するといった対策をとっていくつもりだ」
Instagram Threadsが登場し、Actibity Pubにも連合予定なことでMastodonの使用率は落ちてきていた。昨年の10月に180万あった活動的なアカウントは、Threadsの公開と共に150万、Blueskyの公開で100万まで落ち込んでいる。フェディバース全体ではおよそ290万ほどの活動的なアカウントがあるが、今後ここにThreadsが参入することでスパム予防への期待がある一方、Metaに乗っ取られるのではという心配の声も多数ある。
畳む
