Bash
[Horizon][DaaS] Unified Access Gatewayの証明書差し替え
Let’s Encrypt証明書の差し替えを自動化したい つい先日、実験的にVMware Horizon 7を導入し、外部からのアクセスを可能とするためにUnified Access Gateway(以後、UAG)を構築しました。この時、証明書は自己証明書とするのもなんだか微妙なので、Let’s Encrypt(以後、LE)を使うことにしました。 ですが、ご存じのようにLEの有効期間は3か月です。 一応我が家の環境には、期限が1か月を切ったときに証明書を自動更新する仕組みと、それを統合リバースプロキシサーバへ配信する仕組みを過去に作って現在も運用を続けています。これを何とか活用して、UAGに対する証明書適用の処理を自動化できないかなーと思ってスクリプトを作りました。 参考にした情報 で、UAGには何かしらREST APIでも備わってるやろう・・・と思って情報を探すのですが、意外と見つかりませんで。そして技術ブログ等でもLet’s EncryptでUAGと連携する記事って意外となく、たいていの情報は海外にありました。 しかし、頼みの綱の海外サイトもどちらかというとCertbotの話の比率が大きく、あまりREST APIに対する情報は記載がなく、うろうろし続けたら、まさかのVMware社のDocsに情報がありましたOrz これを用いてスクリプトを作ることにしました。
[Tech] misskeyを導入したときの手順
misskeyってなんじゃろか？ SNSを構成できるソフトの一つ。国産とのこと。分散SNSに関してはMastodonなんかが有名だったりするのだけど、それに比べるとmisskeyはかなり機能が豊富で、動作も結構軽快。Githubへのリンクは以下の通りです。 https://github.com/syuilo/misskey 以前構築に挑んでみたけども玉砕した経験があって手を出してなかったのだけど、過日Mastodonインスタンスを消滅させてしまった腹いせに、ついカッとなって構築することにした。(当時はDBにmongoDB使ってたようなのですが、最新版でPostgreSQLに対応するようになったようです）
[Linux][Mastodon][Virtualization] KubernetesインフラにMastodonエンジンを突っ込む
前提事項 ここで記載する内容なんですが、以下が前提になっています。 読む人はDockerやdocker-composeについてよく理解されている 読む人はKubernetes(k8s)についてよく理解されている Kubernetes(k8s)クラスタ及びネットワークコンポーネント(当環境ではProject Calico)、DBコンテナ環境やらRedisコンテナ環境やらはすでに出来上がっている ちょっと期待はずれな内容かもしれませんので、先に記載しておきます。 今回やった事 ずばり、Mastodonエンジンのコンテナ化です。元々Mastodonはコンテナ構成のものも払い出されては居ますが、あくまでdocker-composeを前提としたものであり、Kubernetesのようなクラスタ構成を想定したものとはなっていません。 私自身、以前Dockerコンテナ型のインスタンスを立てて挫折した経験があるんですが、当時は全くコンテナ技術に対する知見がなく、理解しようとしても中々理解至るのに苦慮しましたが、今回自宅環境でKubernetesに手を出した、ということもあり、思い切ってやってみることにしました。
[Linux][Cloud][Storage] オブジェクトストレージをファイルシステムのごとく扱う
やった事 現在、HQから災対サイトに対してデータのバックアップを取得しています。これはCIFSもNFSも同様に行っていることなんですが、NFSに関しては毎日5:00-6:00にバックアップを行っています。コレに加え、さらに二次バックアップである災対サーバ側のデータをAWS S3へバックアップすることを考え、それを行いました。ざっくりした概要は以下のとおりです。 今回、災対サーバ(CentOS7)側で、AWS S3に作成したバケットをファイルシステムとして見せることを考えました。こういうことが出来るツールは結構OSSとして出回っているようですが、今回それにS3QLを選定しました。そのTipsを書いてみました。
[Linux][Security] vulsを試す
経緯 久方ぶりにSoftware Design (2017年10月号) を買ったんですが、その中に「脆弱性スキャナ：vuls入門」という特集があり、興味を持ちました。ロゴもあるようでして。 Webサイトはココみたいです。 Vulsとは 脆弱性データベースと、管理下にあるサーバのソフトウェア情報を比較し、そのサーバがどのような脆弱性を有するのかをチェックするツールのようです。あくまでチェック・報告までが有する機能で、更新は別途考える必要があるとのことです。 セキュリティに疎い私ですが、せっかく興味を持ったのだしということで、導入してみることにしました。運用管理サーバが持つジョブ連携機能とも組み合わせてみたいな～とか、ここ最近理解してきたからこそ着手できたのかもしれないなーと思います。 今回想定する構成 今回想定している構成はこんな感じです。 サマるとこんな感じです。 統合管理サーバからジョブ実行命令をスケジュールに従い発行する スキャンサーバに最新の脆弱性情報をダウンロードする スキャンサーバよりLinuxサーバ群全体に対して脆弱性スキャンを実行する スキャン完了後、脆弱性レポートをメール送信する
「20171024][Mastodon] IPv6しか繋がらない、そんなインスタンスを作ってみる
はじめに これまで、インスタンスづくりは外部のサイトを見様見真似で作ってきた経緯があり、今回も見様見真似で作ったものの、色々内容が整理できてきたこともあり、ブログに構築手順を書き起こしてみました。 ※一部、手順を修正しました。具体的にはnodejsのインストール周りです。 先に言っとくんですが、あくまで備忘録として頭の中のものをExportしたものになります。本来はMastodonのProduction Guideを参照することが望ましいです。ただ、当該ドキュメントはubuntuベースとなっていて、当方のCentOSには合わないところもあったりするため、そこを補正する際にいろんなサイトをチラ見してます。 なので、正確性についてはどうぞご容赦賜りたく・・・(結局言いたい所はそれかというツッコミは勘弁を) 方針 とりあえず、こんな方針で作ってみることにしました。 IPv6アドレスだけを受け付けるインスタンスを構築する サーバは自宅仮想基盤内にVMを構築し、それを使用する 2vCPU/2GB RAM/40GB VHD(SSDデータストア配置)のスペックで構築 DNSに登録するレコードはAAAAレコードだけにする。IPv4アドレスは名前解決しない。 あくまでIPv4はyumリポジトリやメール配送など、クライアント用途としてしか使用しない インスタンス名とサーバ名は異なるものとする。 当該インスタンスでは、サーバ名はsns-v6.bluecore.netと言う名称ですが、インスタンス名はまた別物(v6don.bluecore.net)です。 OSはCentOS7の最新を使う(yum -y updateでコンポーネントを最新化する) インスタンスはオールインワン構成にする(AP/Redis/DBを同一サーバ内で構成する) 証明書はLet’s Encryptを使うことにする 設置セグメントは本番/ステージングインスタンスと同じところにする Dockerは使用しない 非Dockerの方がログが見やすいというのがあります。サービス監視も楽です。 Dockerの構成も利点はあって、とっととイメージを組み込むことで、前提アプリケーション導入をバイパスできる点などが挙げられます。Linux不慣れな人はこちらが良いのかも。 フィルタリングはサーバ側で行わずに、ゲートウェイ側のACLで行う メールサーバは本番/ステージングと同様に、内部メールサーバを経由する。 メールは外向けに関しては【内部メールサーバ】⇒【メールゲートウェイ】⇒【インターネット】と言う経路で発送される。