X(旧:Twitter)の一番軽いシャドバン(Search Suggestion Ban)を解除する方法(2023.9.8版)

X(旧:Twitter)の一番軽いシャドバン(Search Suggestion Ban)を解除する方法(2023.9.8版)

自分はこれで解除されます

1.直近2週間の自分のツイートを全て削除
2.TwitterIDを変更する
3.問題ないツイートを低頻度で投稿する(センシティブやNGワードが含まれない無難なツイート)

これで1周間くらい大人しくしていると、Search Suggestion Banが解除されました
ちなみに、Search Suggestion BanがONするトリガーになるツイート内容も分かっていて、その内容のツイートを投稿してSearch Suggestion Banにわざとなってから、同様の手順で復旧しているので間違いないと思います
1,2を実施した後、問題ないツイートを投稿していたら1週間後にシャドバン解除されました


◼補足 シャドバンのチェック方法
これらの方法を複数試して、どれか1つでも引っかかればシャドバンになっていると思われます。
シャドバン自体は非公開の機能であるため正確な情報はわかりません。これらを全て実施して問題なかったとしてシャドバンされている可能性があります。

1.シャドバンチェックサイトを使う
以下のシャドバンチェックサイトがあります。シャドバンチェックサイトによって結果が異なるので、念を押すなら複数使って全部問題ないことを確認したほうがよさそうです。

Twitter Shadowban Test
ShadowBird - Twitter ShadowBan Check


2.他のツイッターアカウントからあなたのツイッターIDを検索する
あなたの普段使いのツイッターアカウントとは別のアカウントから検索するとシャドウバンされていることを判断できます。
このとき検索に使うアカウントはシャドウバンされていないこととセンシティブなツイートを非表示に設定されているアカウントで行います。
これはシャドウバンされているアカウント同士では検索結果に表示されてしまうのと、センシティブなツイートも同様に表示していると検索結果に表示されます。
検索結果にあなたのツイートが表示されなかった場合、あなたのアカウントはシャドバンされています。

VSCODEでgihub copilotの認証をしようとするとGDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files' で失敗しました。

debian + vscodegithub copilot認証をしようとしたら以下のエラーメッセージが表示される

GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.secrets was not provided by any .service files' で失敗しました

原因:gnome-keyringがないとだめみたい

sudo apt isntall gnome-keyring でgnome-keyringをインストールしてvscodeを再起動して解決

debian11にslackをインストールする

Linux版Slackはこちらからダウンロード可
Linux | ダウンロード | Slack

※本記事はSlack-desktop-4.26.1で検証しています。

■問題点
debian11にslack公式からダウロードしたdebファイルをインストールしようとすると、以下のエラーメッセージが表示されてインストールできない。

以下のパッケージには満たせない依存関係があります:
slack-desktop : 依存: libappindicator3-1 しかし、インストールすることができません
N: ディレクトリ '/etc/apt/sources.list.d/' の 'slack.list.backup' が無効なファイル名拡張子を持っているため、無視します
E: 問題を解決することができません。壊れた変更禁止パッケージがあります。

■解決方法
検索したところ、stack overflowにやり方が載っていました。
debian - Missing libappindicator3-1 installing Slack - Stack Overflow

この記事を見るとlibappindicator3-1を代替パッケージに置き換えたdebファイルを再生成すればよいみたいです
やり方は以下の通り

1.slack-desktop-4.26.1-amd64.debをunpackディレクトリを作成してそこに展開する
dpkg-deb -x slack-desktop-4.26.1-amd64.deb unpack
dpkg-deb --control slack-desktop-4.26.1-amd64.deb unpack/DEBIAN

2.controlファイルの編集
./unpack/DEBIAN/controlをエディタで開いてい libappindicator3-1 を libayatana-appindicator3-1に置換する

3.debファイルを作成する
dpkg -b unpack slack.deb

4.作ったdebファイルをインストールする
sudo apt install ./slack.deb

5.aptソースからslackソースを削除、apt updateしたときに毎回新バージョンのslackがあると表示されるため
/etc/apt/source.list.d/slack.listを削除する


以上

/以下のすべてのファイル所有者をrootに変更してシステム破壊して復旧した件

rootユーザで操作時にlsコマンドの色つけがないのが不便だったので、普段使いのユーザーアカウントfooから.configなどを/rootにコピーした。そのままだとファイル所有者がもとのユーザーのfooのままだったのでファイル所有者をrootに変更しようとした。
このときのコマンドが事件の発端だった。私は以下のコマンドを打ち込んでしまいました。

#cd /root
#chown -R root:root .*

↑これをやると「.*」は「..」も含まれるので「/root」の「..」は「/」となるので、つまり/以下のファイルすべてを再帰的に所有者rootにしてしまったのである。こうなるとデーモンやサービスのアカウントもログや設定ファイルにアクセスできなくなり大変なことになってしまいました。superuser以外システムを全く操作できなくなってしまいました。
もしやるとするなら


#cd /root
#chown -R root:root .[^\.]*

もしくは
#chown -R root:root /root



調べるとRedhatには、パッケージマネージャーの管理下にあるパッケージすべてをもとのファイルパーミッション、ファイル所有者に戻すコマンドがあるらしいです。私の使っているOSはdebianなので類似のコマンドがないか探したが見つかりませんでした。代わりに全パッケージを再インストールすれば同様の効果が得られることがわかりました。

以下のコマンドで全パッケージを再インストールしました。

dpkg --get-slections \* | awk '{print $1}' | xargs -l1 apt reinstall

これだけだと、一部ファイルのパーミッションがおかしいので以下も変更します。

■sudo
#chown root:root /usr/bin/sudo
#chmod 4755 /usr/bin/sudo
※4755の4000は「SUID」

■aptキャッシュ
sudo chown -R man:man /var/cache/man/
sudo chown -R man:man /var/cache/man/*

■sddmの設定ファイルパーミッション
sudo chown -R sddm:sddm /var/lib/sddm/.config


■これをしないとKDEスクリーンロックしたときに、正しいパスワードを入力してもロック解除できなくなる
sudo chmod 4755 /sbin/unix_chkpwd

これで一通り使えるようにはなったけど、今後もファイル所有者やパーミッション設定が間違っている箇所があれば追記していきます。

任意のユーザーがsudoコマンドを使えるようにする

sudoコマンドを使うには、sudoコマンドを使いたいユーザーがsudoグループに含まれている必要が有る
そのため、gpasswdコマンドを使って任意のユーザーをsudoグループに登録する。
やり方は以下のコマンドで

#gpasswd -a marin sudo

※marinがユーザー名でsudoがグループ名