Yandex.Root予選ゲームのすべてのタスクの分析

昨夜、 Yandex.Root予選ラウンドの最初のゲームが終了しました-Unixエンジニアとシステム管理者のためのオリンピック。 229チームから456人が参加し、そのうち194人が少なくとも1つのタスクを完了しました。 9つすべてで、38チームが管理されました。



Rootを4回実行しますが、初めてHabréでタスクの分析を公開することにしました。 オリンピックで行うタスクは、システム管理者が定期的に解決するタスクに匹敵します。 Yandexでは、ほぼ毎日何かが展開されます。何か問題が発生した場合は、すぐに認識して効果的に対応する必要があります。







一般に、システム管理者の競争はプログラマーの競争よりもはるかにまれなジャンルなので、何らかの形でここで先駆者にならなければなりません。 私たちは課題を面白くするために、そして実際の仕事で重要な資質を参加者に実際に示すものと同様に、非常に一生懸命努力しました。 どれだけ成功したかを判断するのはあなた次第です。



この件についてお聞かせいただき、改善方法についてご意見をお聞かせいただければ幸いです。 ちなみに、必要に応じて、実際のゲームで試してみることができます。 第1ラウンドの第2部は4日間-4月14日火曜日に開催されますが、引き続き登録できます。

ゲームシャノン

私たちは、私たちの仕事で使用されている現代の技術に貢献した人々を記念して、すべてのゲームに名前を付けることにしました。 これは、特に「ビット」という言葉を与えてくれたエンジニアで数学者のクロード・シャノンに捧げられています。 ところで、 root.yandex.ruサービス自体は 、Yandexコンピューティングプライベートクラウドノードで起動されます。



対象となるゲームの目標は、インストールされたOSの構成を変更することにより、仮想マシン上のいくつかの問題を解決することです。たとえば、サービスの開始やプログラムの調整です。 タスクは、関連する場合と独立する場合があります。 「監視をクリア」する必要があります。つまり、仮想マシン内の重大ステータス（赤でマーク）の問題を解決する必要があります。 彼女の画像は事前にダウンロードでき、画像は暗号化されています-復号化キーは公開され、ゲームの開始時にすべての参加者に電子メールで送信されます。



画像を復号化した後、ゲームVPNとの接続を確立する必要があります。 これを行うには、構成ファイルがすべての参加者に発行されます。キャプテンは、アプリケーションの承認時にメールで、キャプテンの招待を受け入れたチームメンバーにそれを受け取ります。 紛失した場合、「download」コマンドを使用してファイルを再度ダウンロードできます。 各プレイヤーは自分の仮想マシンからVPNに接続できるため、タスクをチーム内で分散し、並行して解決できます。

ベース

このゲームのオペレーティングシステムはArchLinuxを使用しているため 。 OSをロードした後、ユーザーには「shannon login：」というプロンプトが表示されます。 プレーヤーには、アクセスの詳細に関するヒントがありません。 原則として、このような場合、マシンへの「物理的」アクセスの存在を利用して、スーパーユーザーのパスワードをリセットする必要があります。

• リブートし、Grubブートローダーでカウントダウンタイマーを停止します。
• 「e」を押して、行linux ...を見つけ、init = / bin / bashを最後に追加します。
• Ctrl-Xを押して、ロードを待ちます。
• passwd
  
  
  
  コマンドを入力し、新しいパスワードを設定します。
• コマンドexec /sbin/init
  
  
  
  入力すると、ダウンロードが続行されます。

この手順を完了すると、新しいパスワードでログインできます。



問題を解決するには、いくつかのパッケージをインストールする必要があります。つまり、作業のためにパッケージマネージャーを準備する必要があります。

• 外部ミラーとの同期： pacman-key --populate



pacman-Sy
  
  
  
  、 pacman-key --populate
  
  
  
  ;
• パッケージマネージャーの更新： pacman -S pacman
  
  
  
  、 pacman-db-upgrade;
  
  
  
  
• いくつかの問題を解決するには、tcpdumpとstraceが必要です。
  
  pacman -S tcpdump strace.
  
  
  
  

ゲームイメージの内部にはゲームプログラムがあり、リモートサーバーでテストスクリプト（以下「チェック」と呼びます）を実行します。 検証が成功した場合、ゲームはタスクの完了をカウントします。



リモートサーバーとの接続を確保するには、OpenVPNを構成する必要があります。 主催者はすでに必要なものをすべて準備しました-設定ファイル（Yandex.Rootからのレターに添付されています）を/etc/openvpn/openvpn.confにコピーし、コマンドsystemctl start openvpn@openvpn



ます。

1.SSL

このタスクは、最初に解決されました。 SudariLudariチームがそれを処理しました。 タスクでは、指定された証明機関の証明書によって署名された証明書を生成する必要があります。





タスクからのデータをファイルca.crtおよびca.keyにそれぞれ書き込みます。 次に、証明機関の証明書を見てみましょう。

 # openssl x509 -in ca.crt -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 12767824280512002782 (0xb1306c894a867ade) Signature Algorithm: sha1WithRSAEncryption Issuer: C=RU, ST=Moscow, L=Moscow, O=Yandex, OU=Root, CN=root.yandex.com Validity Not Before: Apr 6 16:43:09 2015 GMT Not After : Apr 5 16:43:09 2016 GMT Subject: C=RU, ST=Moscow, L=Moscow, O=Yandex, OU=Root, CN=root.yandex.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:a3:2b:01:a7:04:75:30:42:d4:f3:2d:be:6e:86: b8:7e:79:14:40:43:24:30:1b:30:a0:fa:7e:17:5b: 3b:7c:33:e8:97:fc:e1:b1:e1:00:86:e0:68:ca:86: 2f:4d:ab:38:66:e3:5f:80:8c:f0:79:72:77:54:dc: e7:b9:8f:52:eb:72:f5:af:c5:ed:a7:d7:91:46:ee: 13:d2:2c:6e:5d:1d:ef:7b:a7:3a:63:29:59:9a:f0: e9:1c:ad:47:3a:59:62:1c:71:9e:3c:16:55:76:d5: 90:9e:50:5b:a4:b6:1b:6a:10:30:c4:13:0d:42:c4: 49:f0:1e:02:32:76:7c:a7:97 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 06:FB:29:15:D7:71:15:5B:D5:F1:09:39:DC:2E:32:D5:61:55:FC:DD X509v3 Authority Key Identifier: keyid:06:FB:29:15:D7:71:15:5B:D5:F1:09:39:DC:2E:32:D5:61:55:FC:DD DirName:/C=RU/ST=Moscow/L=Moscow/O=Yandex/OU=Root/CN=root.yandex.com serial:B1:30:6C:89:4A:86:7A:DE X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 9a:f3:64:f2:20:1b:57:8f:98:32:af:fd:a3:19:0c:78:1e:91: c4:bb:3d:9b:a8:e1:63:20:0f:b8:02:3f:75:48:56:49:7f:83: f8:19:d1:71:bb:07:58:ae:2b:6b:d1:bf:ae:23:35:cd:ea:db: e4:10:f5:6a:93:33:dd:f6:8e:37:6c:9d:14:91:81:d2:d8:63: 96:0a:ff:29:77:e0:69:45:e3:a7:5e:50:b2:51:21:b3:28:59: 22:01:01:4d:a9:3e:d0:14:24:92:1e:7e:70:50:2f:26:11:82: 66:a6:a3:af:a9:b6:23:c0:e2:c7:79:85:dc:4c:bb:9d:2c:75: 18:35
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じ値を持つ新しい証明書を要求します。

 # openssl req -out cert.csr -new -nodes Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:Moscow Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]:Yandex Organizational Unit Name (eg, section) []:Root Common Name (eg server FQDN or YOUR name) []:10.0.0.15 Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

認証センターの作業のための構造を準備します。

 # mkdir /etc/ssl/newcerts # echo 01 > /etc/ssl/serial # touch /etc/ssl/index.txt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のコマンドは、テキストがそれほど明確ではないエラーを返します。

 # openssl ca -cert ca.crt -keyfile ca.key -in cert.csr -out cert.crt Using configuration from /etc/ssl/openssl.cnf Check that the request matches the signature Signature ok The stateOrProvinceName field needed to be the same in the CA certificate (Moscow) and the request (Moscow)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、問題は証明書の文字列が

認証センターとリクエストは異なるエンコーディングで書かれています。 この問題を回避するには、 / etc / ssl / openssl.cnfファイルを編集し、 [req]



セクションのstring_mask



パラメーターの値をstring_mask



変更します。



Webサーバーのファイルを準備するために残ります。

 # mv privkey.pem cert.key # cat ca.crt >> cert.crt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Webサーバー(pacman -S nginx)



をインストールし、 / etc / (pacman -S nginx)



/ nginx.conf％でSSLを有効にして 、対応するサーバー{}セクションのコメントを解除します 。



私たちはチェックします：

 # nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful # systemctl restart nginx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、 「SSLv3は弱い」という診断を使用したテストシステムによって決定されることはありません。 構成を推奨されるMozillaに変更します。

• NginxおよびModernオプションを確認し 、構成をnginx.confに挿入します。
• Diffie-Hellmanパラメーターを生成します： openssl dhparam -out dhparam.pem -outform PEM -2 2048
  
  
  
  ;
• nginxの再起動： systemctl restart nginx.
  
  
  
  

2.MariaDBの修復

このタスクでは、データベースを復元する必要があります。

/ var / lib / mysqlにMariaDBデータベースがあります。 ログイン「チェッカー」とパスワード「マスターキー」でアクセスできましたが、何かがおかしかったです。

 BTW, the `data` table structure was: +-------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+-------+ | name | text | YES | | NULL | | | hits | int(11) | YES | | NULL | | | size | int(11) | YES | | NULL | | +-------+---------+------+-----+---------+-------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前から、MySQLの有名なフォークであるMariaDBデータベースが使用されていることは明らかです。



DBMSをインストールします： pacman -S mariadb



そしてsystemctl start mysqld



を開始してください。 ログから、 mysqldが間違った場所でファイルを探していることがわかります。 構成ファイル/etc/mysql/my.cnf



から、システムがネットワークモードで動作していないことが/etc/mysql/my.cnf



ます。パラメータskip-networking 、 bind-addressが追加され、誤ったdatadir値が示されています。 時間を節約するために、構成ファイルの修復は試みません。 代わりに、既知のワーカーに置き換えます。

 [mysqld] key_buffer_size = 16M max_allowed_packet = 1M table_open_cache = 64 sort_buffer_size = 512K net_buffer_length = 8K read_buffer_size = 256K read_rnd_buffer_size = 512K myisam_sort_buffer_size = 8M tmpdir = '/var/tmp'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルの所有者chown -R mysql:mysql /var/lib/mysql



修正し、データベースの再起動を試みましょうsystemctl restart mysqld



。



やれやれ、 mysqldは動作しています。 接続してみましょう：

 # mysql ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パスワード保護がインストールされており、パスワードが不明であることがわかります/オペレーティングシステムの場合と同様に、パスワードをリセットする必要があります。

• mysqld: systemctl stop mysqld
  
  
  
  ますmysqld: systemctl stop mysqld
  
  
  
  ;
• リセット命令でファイルを準備しますecho "UPDATE mysql.user SET password = PASSWORD('root') where user = 'root';" > /tmp/reset.sql



echo "UPDATE mysql.user SET password = PASSWORD('root') where user = 'root';" > /tmp/reset.sql
  
  
  
  ;
• ファイルをロードしてmysqldを起動しますmysqld --user=mysql --init-file=/tmp/reset.sql
  
  
  
  ;
• ここで、通常の方法でmysqldを停止します。そのためには、 Ctrl-\
  
  
  
  を押す必要があります。
• ユニットを再度実行systemctl start mysqld
  
  
  
  

この手順を完了すると、すでにroot



パスワードでデータベースに接続できます。 試してみましょう： mysql -ppassword -uroot



。 show databases



コマンドの出力から、 db



データベースの存在がわかりますが、 data



テーブルはありません。 ただし、このテーブルはディスク(/var/lib/mysql/db/data.ibd)



ます。 テーブル定義（data.frm）がありません。



幸いなことに、タスクにはテーブルの外観に関するヒントが含まれており、システムテーブルを分析せずにfrmを再構築できます。 リクエストを実行します：

 create table data2 (name text, hits int(11), size int(11));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

システムテーブルにはまだ言及が含まれているため、dataというテーブルを作成することはできません。 次に、データファイルを新しいテーブルに接続します。 これを行うには、「空の」ibdファイルをテーブルから切断します。alter alter table data2 discard tablespace;



、それを塗りつぶされたmv data.ibd data2.ibd



、 alter table data2 import tablespace;



再接続しalter table data2 import tablespace;



。



db.dataはまだシステムテーブルにリストされているため、 drop table db.data



することはできません。 一時データベースを作成し、新しいテーブルを転送して、古いデータベースを削除してから、再作成する必要があります。

 rename table db.data2 to db2.data; drop database db; create database db character set utf8; rename table db2.data to db.data; alter table db.data engine = innodb;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザーにアクセスを許可するためだけに残ります： grant all privileges on db.* to 'checker'@'%' identified by 'masterkey';



。 残念ながら、接続エラーのためにチェックはまだ失敗します。 tcpdumpによるチェックは、mysqldが応答していないことを示しています。 iptables-save



を使用してファイアウォールをチェックし、悪役によって残された問題を見つけましょう。誤ったルールがnatテーブルに追加されました。 ただし、それらを一時的に削除するとネットワークが復元され、ルールが再表示されます。



原則として、定期的なアクションはcrontabの操作によって引き起こされます。 (crontab -l, cat /etc/cron.* /etc/crontab /etc/cron.d/*)



を確認し、現在のユーザーのすべてのタスクを削除します(crontab -r)



。

3.バイナリ

1.exeを実行する

このタスクでは、「異常な」プログラムを実行する必要があります。 タスクから、ファイル名「1.exe」がわかります。 ファイルシステムでファイルを検索し、その内容を確認します。

 # find / -iname 1.exe /root/1/1.exe # file /root/1/1.exe /root/1/1.exe: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GNU / Linuxで.NETアプリケーションを実行するためのモノ環境があります。 それをインストールし(pacman -S mono)



、プログラムを実行してみてください：

 # cd /root/1 # mono 1.exe
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、このタスクは見かけほど簡単ではありません。 応答として、 ゲームは以下を返します。

 Name: Binary Status: uncompleted Output: bad program
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プログラム1.exeの機能を理解してみましょう。 straceで monoを実行すると、プログラムがTCPソケットをリッスンし、チェックで渡されたコマンドを実行していることがわかります。 tcpdumpを使用したトラフィックの表面分析は、プログラムがファイルを読み取り、組み込みデータベースにアクセスし、計算を実行できることを示しています。 計算を実行した後、チェックは動作を終了します。つまり、問題はおそらく計算にあります。



多くの場合、実行可能ファイル内のテキスト文字列を検索することにより、追加情報を抽出できます。 この手法を使用してみましょう-binutilsソフトウェアbinutils



をインストールし、 文字列プログラムを1.exeファイルに適用します。 出力の一部は、プログラムで使用されるライブラリのリストに似ています。

 System.Core mscorlib System.Xml dnAnalytics
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

dnAnalyticsを除くこれらすべてのライブラリは、 monoの一部です。これは、パッケージマネージャー(pacman -Ql mono)



を使用して簡単に確認できます。



公式サイトからアーカイブをダウンロードして解凍し、不足しているライブラリをインストールします（bin / *。DLLは/ root / 1に配置する必要があります）。

再起動後、プログラムはテストに成功します。

4.モンゴ

このタスクでは、MongoDBシャードストレージを展開し、オーガナイザーによって提案されたデータを書き込む必要があります。

/var/lib/db.tar.gzにデータベースがあります。



2つの断片でroot.featuresコレクションを作成し、標準ポートで使用できるようにします。

まず、mongodb： pacman -S mongodb



インストールします。 オーガナイザーはアーカイブをデータベースとともに残し、それを解凍してアーカイブのコピーを作成します。

 cd /var/lib/mongodb tar jxf /var/lib/db.tar.bz2 mongod --dbpath db mongodump rm -rf db
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シャーディングには、 configdbと呼ばれる特別なサービスベースが必要です 。 作成する：

 mkdir -p /data/configdb mongod --configsvr &
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、mongos“ shredder”を実行します： mongos --configdb localhost &



。 タスクには2つのシャードを上げる必要があるため、2つのmongodインスタンスを準備します。

 mkdir /var/lib/mongodb/s1 /var/lib/mongodb/s2 mongod --dbpath /var/lib/mongodb/s1 --port 30001 --nojournal & mongod --dbpath /var/lib/mongodb/s1 --port 30002 --nojournal &
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてそれらをmongosに接続します：

 # mongo mongos> sh.addShard("localhost:30001") mongos> sh.addShard("localhost:30002") mongos> sh.enableSharding("root")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ダンプを再度ロードするために残ります： mognorestore --port 30001 dump/



。



ただし、これは問題を解決するのに十分ではありません-root.featuresコレクションは2つのシャード間で均等に共有されません。 ドキュメント識別子によってインデックスを作成し、バランサーをオンにすることで、この問題を解決します。

 # mongo root mongos> db.features.ensureIndex({"_id":"hashed"}) mongos> sh.shardCollection("root.features", {"_id":"hashed"}) mongos> sh.enableBalancing("root.features")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コレクションがシャード間で再配布されるのを待ってから、再度チェックを実行します。

5.奇妙なプロトコル

このタスクは最も困難でした。 実際、私たちが予測したように。

ポート13000でエコーサーバーをセットアップします。

今回は、ポート13000でエコーサーバーを起動する必要があります。



このタスクは単純に思えます-実際、エコーサーバーの最も単純な実装は、たとえばxinetdにすでに統合されています。 tcpdumpポート13000を実行すると、UDPを介して交換が行われていることが示されますが、 xinetdで echo-dgramをセットアップしても期待した結果が得られません。



トラフィックを詳しく見てみましょう-tcpdumpを再度実行しますが、-Xオプションを使用します。 最後のパッケージは興味深いようです：

  0x0010: 0a00 000f ebee 32c8 0012 ffd6 656e 6574 ......2.....enet 0x0020: 2065 7272 6f72 .error
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

enet



という単語を検索すると、enetプロトコルの実装を説明するサイトが表示され、パケット損失を心配することなくUDPを介してデータストリームを送信できます（TCPなど）。



さらに検索すると、Python言語のenetにバインドされたpyenet



ライブラリが得られます。これは私たちのタスクにぴったりです。 簡単なプログラムを書きましょう：

 import enet import sys host = enet.Host(enet.Address(b'0.0.0.0', 13000), 100, 0, 0) while True: evt = host.service(0) if evt.type == enet.EVENT_TYPE_RECEIVE: data = evt.packet.data evt.peer.send(0, enet.Packet(data))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのライブラリをインストールすることは残っています：

 pacman -S git git clone git://github.com/aresch/pyenet cd pyenet git clone git://github.com/lsalzman/enet pacman -S cython base-devel python setup.py build python setup.py install
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プログラムを開始すると、今回のチェックは成功です。

6.ファイル

オーガナイザーは/ root / file内のどこかにroot.txtを隠しました。

イメージ内に/ root /ファイルがあります。 適切なroot.txtファイルを見つけて、 image_ip / root.txtで利用できるようにします。

/ root / fileが何であるかを理解してみましょう：

 # file /root/file /root/file: LVM2 PV (Linux Logical Volume Manager), UUID: XT6zLL-YAUv-nmA9-BSrw-2pBV-CTi2-vqKe35, size: 31457280
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ディスクイメージのように見えます。 Linuxには、ファイルをブロックデバイスに変換できるループカーネルモジュールがあります。 私たちはそれを使用します：

 losetup /dev/loop0 /root/file
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LVMボリュームはディスクイメージ内にあるため、通常のツールを使用して接続します。

 # vgchange -ay 1 logical volume(s) in volume group "VolGroup00" now active
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

中身を見てみましょう：

 mount /dev/mapper/VolGroup00-lv0 /mnt ls /mnt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

root.txt.gz 、unpack： gunzip /mnt/root.txt.gz



ます。



すでにnginxをインストールしてSSLを設定しているため、これを使用してHTTP経由でファイルを配布します。

 umount /mnt mount /dev/mapper/VolGroup00-lv0 /usr/share/nginx/html/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、チェックは失敗します-間違ったroot.txtが見つかりました。 さらに調べます。 どんなファイルシステムがあるのか​​見てみましょう：

 # file -s /dev/dm-0 /dev/dm-0: BTRFS Filesystem sectorsize 4096, nodesize 4096, leafsize 4096)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

btrfsはsubvolumeを理解しているため、それらのリストを見てみましょう。

 # pacman -S btrfs-progs # btrfs subvolume list /usr/share/nginx/html/ ID 256 gen 14 top level 5 path root ID 257 gen 11 top level 5 path root_1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別のサブボリューム root_1があることがわかりました。 マウントします。

 umount /usr/share/nginx/html mount -t btrfs -o subvol=root_1 /dev/mapper/VolGroup00-lv0 /usr/share/nginx/html/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、別のroot.txt.gzファイルが見つかりました。 解凍し/usr/share/nginx/html/root.txt.gz



： gunzip /usr/share/nginx/html/root.txt.gz







これが問題の解決策になります。

7.MariaDBのチューニング

MariaDBの修復の問題を解決する間、データベースを修正しましたが、遅すぎます。 それを修正する時が来ました。

修復されたMariaDBは遅いです。 それを調整します。

ベースが減速する場所を見てみましょう。 スロークエリログをオンにします。1秒より長く実行されるすべてのクエリが取得されます。

 mysql -u root -ppassword db mysql> set global slow_query_log = ON; mysql> set global long_query_time = 1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チェックを開始し、ログを見る： tail /var/lib/mysql/shannon-slow.log







クエリSELECT COUNT(*) FROM db.data WHERE size < 10;



。



クエリプランを見てみましょう。

 mysql> explain SELECT COUNT(*) FROM db.data WHERE size < 10 \G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: data type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 25061163 Extra: Using where 1 row in set (0.00 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、このようなクエリの実行は遅すぎます-このフィールドにはインデックスがありません。 インデックスを追加しますmysql> create index data_size on data(size);



。



テストを再開すると、データ（ヒット）に対して同じ問題が表示され、同様の方法で解決します。

8.HG

/root/repo mercurial



リポジトリが/root/repo mercurial



リポジトリに対して、履歴を修正し、http経由でアクセスできるようにする必要があります。

/ root / repoにHGリポジトリがあります。



すべてのリビジョンのすべての.gzファイルをドロップし、 ipで使用可能にします：8000 /

まず、 mercurialをインストールします： pacman -S mercurial



。 デフォルトで無効になっている変換モジュールを使用して、履歴を変更できます。 オンにします：

 # cat <<EOF > ~/.hgrc [extensions] hgext.convert= EOF
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このモジュールは、ソースおよびターゲットリポジトリにファイル一致ルールを適用できます。 このようなルールはfilemap



と呼ばれfilemap



。 2.osm.gzファイルをスローするルールを作成して適用します。

 echo 'exclude "2.osm.gz"' > /root/fmap hg convert --filemap ~/fmap /root/repo /root/repo1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コマンドを実行すると、リポジトリ/ root / repo1が取得されます。これには、すべてのリビジョンに2.osm.gzファイルがありません 。 外部からアクセスできるようにするために残っています。 Mercurialには組み込みのWebサーバーがあり、これを使用します。

 cd /root/repo1 hg serve
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

9.奇妙なファイル

このタスクは、コマンドの最大数-151によって処理されました。ファイルシステムには、誰も変更できない奇妙なテスター/ファイルがあります。

〜tester / fileに奇妙なファイルがあります。 誰もそれを変更できません。 修正してください。

実際、ファイルを変更することはできません-ルートからでも：

 # echo test >> ~tester/file -bash: /home/tester/file: Permission denied
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、どんな種類のファイルシステムがあるのか​​見てみましょう：

 # mount | grep ' on / ' /dev/sda2 on / type ext4 (rw,relatime,data=ordered)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ext4 (man 5 ext4)



このファイルシステム上のファイルが

次の属性：

不変属性が設定されたファイルのシステムの動作を詳細に説明するchattr（1）ページを見てみましょう。

答えは明らかです-ファイルからこの属性を削除する必要があります： chattr -i ~tester/file



。 問題は解決しました。