「シングルユーザーで接続した」シングルユーザー......。聞いたことのない言葉だったので聞き間違いかもしれないと思い「ィンぐるユーザーですか......」とぼやかしながら聞き返した。気にはなったが後で調べればいいし、こんなバタバタさせてしまった状況でいちいち技術的な事を質問するのも失礼にあたると思いひとまず聞き流した。あとは書き込み属性を与えてはいけないということを軽く念押しだけされ、電話を切った。何にしろ、助かった......。シングルユーザーモードとはあとで調べてみたところ、Windowsのセーフモードのようなものということだった。物理サーバーがどこか触れるところにあったということだろうか。このようなトラブルを招かないためにとにかくSSH接続できるユーザーは複数用意しておくほうが良い。今回のような古き良きサーバーの場合、Webサーバー、データベースサーバー、アップロードファイルなど、あらゆるものがサーバー上に詰め込まている。いった場合、サーバーが何かしらの原因で接続できなくなった場合、あらゆる本番のデータを失ってしまう。今回の場合はリリース前ということで最悪全員が苦労して復旧すればなんとかなるのだが、リリース後に実際のユーザーが登録されてしまっている場合はそうともいかない。いえ、この構成だと故障してしまった時に結局どうしようもなくなり全てを紛失してしまう。最近ではAWSやGCPなどのクラウドサービスを使い、通常のWebサーバーとは別に、データベースは他のデータベースサービス、アップロードファイルはストレージサービスを用いてWebサーバーの外に保存する仕組みで運用することができる。するとWebサーバー内には失ってはまずいデータが存在しなくなるため、トラブルがあった際には単にサーバーを一度捨てて作り直すだけで解決する。あとは未リリースの本番ということで気が緩んでいた部分もあるのかもしれない。リリース前とはいえ本番としてしっかり扱う必要がある。チームがある場合はその頃には運用方法も稼働中の本番と同様に扱うべきだろう。帰ろうクライアントのおかげであらゆる問題が解決した。あとは止まってしまった残作業を再開し、完了したら無事に家に帰ることが出来る。遅くなってしまったが、最悪もう二度と家に帰ることができないかもとも思っていたため助かった。本番のデータを更新するため、SSH接続を行い、アプリケーションの存在するディレクトリへ移動する。よし、これで終わりだ。僕は他の誰かがtruncate文を埋め込んでいたことも知らないままSeederを実行した。.sshディレクトリ以下が書き込み可能になっていたか、もしくはsshdの設定でStrictModesが有効になっている場合はホームディレクトリに書き込み権限を付与するだけで認証できなくなる。Linux上で何かしらの役割のあるファイルやディレクトリの権限を変更してはいけない。.sshディレクトリ以下が書き込み可能になっていたか、もしくはsshdの設定でStrictModesが有効になっている場合はホームディレクトリに書き込み権限を付与するだけで認証できなくなる。Linux上で何かしらの役割のあるファイルやディレクトリの権限を変更してはいけない。