sho-kun.com

先日 iPad のパスコードを失念してしまい、PC に認識されない状態で初期化する必要があった。 iPad を初期化するには、PC に認識される必要があるが、今回はそれができない状態だった。 まずはリカバリーモードを試す iPad の電源を切る。 iPad を PC に接続する。 リンゴマークが表示されたら、ボリュームアップボタンを押す。 次にボリュームダウンボタンを押す。 その後、トップボタンを押し続ける。 リカバリーモードの画面が表示されたら、トップボタンを離す。 本来であれば PC が iPad を認識する。 何度かリカバリーモードを試すと認識される場合もある 何度か試すと認識された。 一度アップデートを試みた。 完了後起動したが背景真っ黒で 「iPad は使用できません。8 時間後にやり直してください」と表示された。 そこから何度リカバリーモードを試しても認識されなくなった。 次に DFU モードを試す iPad の電源を切る。 iPad を PC に接続する。 リンゴマークが表示されたら、ボリュームアップボタンを押す。 次にボリュームダウンボタンを押す。 その後、トップボタンを押しながら音量を下げるボタンを 5 秒押し続ける。 トップボタンを離してボリュームダウンボタンだけをさらに押し続ける。 画面が真っ黒のままになったら、PC が iPad を認識する。 これで MAC が認識して初期化できた。

はじめに 「知識をストックする場所が欲しい」と思い立ち、Docker と Hugo を使って静的ブログを構築してみました。 Hugo は Go 製の静的サイトジェネレータで、とにかくビルドが速く、Docker での運用も簡単です。 この記事では、環境構築から記事作成、更新までの流れをまとめます。 docker-compose.yml まずは docker-compose.yml を用意します。 Hugo でビルドして生成した静的ファイルを Nginx で配信する構成です。 services: hugo: image: klakegg/hugo:ext-alpine # Hugoビルド用イメージ container_name: hugo-builder volumes: - ./site:/src working_dir: /src command: ["hugo", "--minify"] knowledge-blog: image: nginx:alpine container_name: knowledge-blog restart: always ports: - "80:80" # ← 直接ホストの80番ポートを公開 volumes: - ./site/public:/usr/share/nginx/html:ro config.toml サイト設定は以下の通り。 テーマは hugo_theme_robust を使いました。 baseURL = "https://knowledge.sho-kun.com/" languageCode = "ja" title = "sho-kun.com" theme = "hugo_theme_robust" [services] [services.disqus] shortname = "" # コメントを入れる場合は設定 [services.

はじめに 複数の Web サービスを同じサーバーで動かすとき、ポートや証明書の管理が面倒になりがちです。 そこで便利なのが nginx-proxy と acme-companion の組み合わせです。 nginx-proxy : コンテナの環境変数 (VIRTUAL_HOST) を読み取り、自動的に Nginx のリバースプロキシ設定を生成 acme-companion : Let’s Encrypt の証明書を自動発行・自動更新 これにより、サービス側にほとんど設定を書かずに 自動で HTTPS 化された環境を構築できます。 前提条件 サーバー上に Docker / Docker Compose がインストール済みであること 公開するドメインがサーバーの グローバル IP に正しく向いていること すべてのサービスコンテナは 同じ Docker ネットワーク (shared-net など) に所属する必要があります docker-compose.yml（プロキシ側） 以下は nginx-proxy + acme-companion の基本構成です。 この 2 コンテナが 80/443 ポートを占有して、全サービスのフロントに立ちます。 services: nginx-proxy: image: nginxproxy/nginx-proxy:alpine container_name: nginx-proxy restart: always ports: - "80:80" - "443:443" volumes: - /etc/nginx/certs:/etc/nginx/certs - /etc/nginx/vhost.

install npm install -g forever 実行 forever start sample.js 再起動 forever restart sample.js 停止 forever stop sample.js 実行中一覧 forever list ログ確認 forever logs 設定確認 forever config オプション ファイルの変更を検知。再起動を自動で実行 -w forever start -w app.js ログファイルの出力を指定 -l forever start -l forever.log app.js

環境 CentOS Linux release 7.2.1511 (Core) 今回インストールしたもの mysqld Ver 5.7.30 for Linux on x86_64 (MySQL Community Server (GPL)) リポジトリの追加 yum localinstall http://dev.mysql.com/get/mysql57-community-release-el7-7.noarch.rpm yumでインストール yum install -y mysql-community-server MySQLのデーモンの起動と停止 インストールが完了しているか、バージョンを表示させて確認 mysqld --version 起動 systemctl start mysqld 起動できたか確認 systemctl status mysqld 自動起動設定 systemctl enable mysqld 初期設定 初期パスワードの確認 cat /var/log/mysqld.log | grep root 2020-06-12T08:46:05.397837Z 1 [Note] A temporary password is generated for root@localhost: JyGp4m7TKI!e 「JyGp4m7TKI!e」が初期パスワード 初期パスワードでログイン mysql -u root -p Enter password: JyGp4m7TKI!e パスワード変更

僕が今まで使っていたコマンドはこちら certbot certonly --webroot -w /var/www/html/test/ -d sho-kun.com でもこれだと既存の証明書が存在するときなどに名前の後ろに「-0001」がついてしまう それを回避する方法 オプションで以下をつける --cert-name [指定したい証明書の名前] 以下のようにする certbot certonly --webroot -w /var/www/html/test/ -d sho-kun.com --cert-name sho-kun.com このようにすることで回避できる

apacheが作成するファイルにFTP権限でアクセスしたい apacheが作成するファイルのユーザーグループをFTPユーザーにする apacheのモジュールで解決する ・mod_ruid2 目次 epelをインストールする mod_ruid2をインストールする mod_ruid2を有効化 実際にファイルを作成してみる epelをインストールする # yum install epel-release.noarch mod_ruid2をインストールする # yum install --enablerepo=epel mod_ruid2.x86_64 mod_ruid2を有効化 とりあえず80番ポートのみに適用 apacheの設定を変更する <VirtualHost xxx.xxx.xxx.xxx:80> ServerName example.com ServerAlias www.example.com DocumentRoot /home/poyopoyo/example/DocumentRoot/ </VirtualHost> ----------【ここからがmod_ruid2の設定】---------- <Directory "/home/poyopoyo/example/DocumentRoot/test_file"> ← mod_ruid2を設定したい階層 <IfModule mod_ruid2.c> RMode config RUidGid poyopoyo.example poyopoyo.example ← 作成されるファイルのユーザーグループを指定 </IfModule> </Directory> ----------【ここまでがmod_ruid2の設定】---------- apacheリロード 実際にファイルを作成してみる PHPでファイルを作成する ディレクトリはさっき設定した階層 /home/poyopoyo/example/DocumentRoot/test_file 以下のPHPでファイルを作成する test.php <?php touch('file.txt'); echo "OK"; ?> ブラウザで実行 [http://example.com/test_file/test.php](https://web.archive.org/web/20200925222816/http://check.kizuna- group.jp/20191223@test_file/test.php) file.txtというファイルが生成された ユーザーグループがさっき設定したものになっていれば成功 実行権限はapacheでapacheで生成されるファイルのユーザーグループが設定したものになる

証明書の一覧 # certbot certificates 例） # certbot certificates Saving debug log to /var/log/letsencrypt/letsencrypt.log Certificate Name: test.sho-kun.com Domains: test.sho-kun.com Expiry Date: 2019-12-19 09:48:35+00:00 (VALID: 86 days) Certificate Path: /etc/letsencrypt/live/test.sho-kun.com/fullchain.pem Private Key Path: /etc/letsencrypt/live/test.sho-kun.com/privkey.pem 証明書の削除 certbot delete --cert-name [証明書ファイル名] 例） sudo certbot delete --cert-name test.sho-kun.com # sudo certbot delete --cert-name test.sho-kun.com Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Deleted all files relating to certificate test.

社内で使っていたサーバー監視アラート用のラズパイが動かなくなりました。 ファイルサイズを確認すると # df -h Filesystem Size Used Avail Use% Mounted on /dev/root 13G 13G 0 100% / 100%。。。 どのファイルが重いのかチェック # du -S / | sort -n ～（略）～ 7436748/var/log 7.4Gもlogが、、、 ログデータがたまりすぎていたみたい、、、 ログデータけしました。 # find /var/log/ -type f -name \* -exec cp -f /dev/null {} \;

この記事は筆者が独自に調べたものであり、必ずしも正確性を保証するものではありません。また安全性なども保証しません。 当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますので、ご了承ください。 目次 1.脆弱性の詳細 2.悪意のあるコードを実行する条件 3.脆弱性の確認 4.まとめ 5.参考 目次 脆弱性の詳細 以下のバージョンで脆弱性があり 開発者のコメント プレスニュース（thehackernews） 悪意のあるコードを実行する条件 しかしwebmin1.890はデフォルトの設定で脆弱性がある テキストベースでwebminの設定を変更するには 脆弱性の確認 まとめ 脆弱性が確認されたバージョン 1.890ではデフォルトの設定で脆弱性がある 悪意のあるコードを実行させないためには 参考 脆弱性の詳細 以下のバージョンで脆弱性があり 1.882〜1.921 1年以上バックドアは見つからなかった為、様々なバージョンで脆弱性がある この欠陥は実際にはプログラマーが行ったコーディングミスの結果ではなく、悪意ある第三者が設置したもの 開発者のコメント Webminバージョン1.890は、それを知っている人ならだれでもrootとしてコマンドを実行できるバックドアとともにリリースされました。バージョン1.900〜1.920にも同様のコードを使用したバックドアが含まれていましたが、デフォルトのWebminインストールでは悪用されませんでした。管理者がWebmin-> Webmin Configuration-> Authenticationでこの機能を有効にして有効期限が切れたパスワードの変更を許可した場合のみ、攻撃者によって使用される可能性があります。 プレスニュース（thehackernews） セキュリティの欠陥はパスワードリセットページに存在POSTを介して古いパスワードフィールドに単純なパイプコマンド（ “|”）を追加するだけで、リモートの認証されていない攻撃者がサーバーでルート権限で任意のコマンドを実行できるようにします 悪意のあるコードを実行する条件 webminのwebページから Webmin Webmin- _> _ Webmin Configuration- > Authentication- > Password expiry policy set to Prompt users with a passwords to enter new password 上記を設定する 必要があります 。このオプションはデフォルトでは設定されていませんが、設定されている場合、リモートでコードを実行できます ほとんどのバージョンはデフォルトの構成で脆弱はなく、 この機能は手動でこの機能を有効にしたWebmin管理者にのみ影響します。 しかしwebmin1.890はデフォルトの設定で脆弱性がある Webmin 1.930 and Usermin 1.