AlmaLinuxでfluentdを利用する際には選択肢が３つある。

1. RubyをInstallしてGemからfluentdを利用する
2. fluent-packageを利用する(v4まではtd-agentと呼ばれていたが、v5からfluent-packageになった)
3. calyptia-fluentdを利用する

正直、plainなまま利用するなら、どれでもほとんど差がないが、管理や更新の手間の問題からfluent-packageを利用した。

以下に、いくつかメモを記載しておく。

→ 続き...

APNICが公開している情報(BGP in 2022 - the rouuting table) による、2023年1月時点での情報

• IPv4
  • Number of Prefixes : 940K
  • Number of Root Prefixes : 445K
  • Number of More Specs : 495K
• IPv6
  • Number of Prefixes : 172.4K
  • Number of Root Prefixes : 69.4K
  • Number of More Specs : 103K

この情報と、同ページに記載されている成長率から見ると、大雑把にFull Route 1本毎に

• IPv4で100万〜150万経路
• IPv6で18万〜20万経路

があると考えて BGP Routerを作成するべきと考えられる。

BirdにおけるRouting TableはIPv4の場合、100K IPv4 Routeに対して約13Mとなる。したがって、1M Routeならば大雑把に130MほどMemoryが必要になる計算になる(ただし、BGPにおける全ての経路のNexthopが同一である場合)。以上から、Full Routeを1本持つBGP Routerに必要なMemory量は、RIB+FIBで(130*1.5*2)=400M Bytes以上となる。 BGP Peerをいくつ持つか、相手先のASは同一か別かによって変わるが、通常Peer相手が増加してもBGP的枝刈後の経路数はそれほど増えないことを考慮に入れると、Peerをn本持つとするならば、(130*1.5*(n+1))=200(n+1)MBとなる

IPv6の場合、Prefixが4倍になることを考えると(おそらく、実際には上位64bit分だけあればいいのだが、ここでは128bit全部あるものと考える)100K Routeに対し52M(つまり、20万経路ならば104M)あれば良いと考えられる。したがって、同様に、peer数をnとすると、110(n+1)MBあれば良いと考えられる。

以上の元となった数値はBGP Table sizeより引用した。

以上をBirdでBGP Router及びRoute Reflectorを構築する場合の算定根拠にする。

今思いつくことを適当に書き殴っただけでこんなにあるのか… ちょっとサボりすぎたかな…

• DataのOwnershipとSystemのOwnershipを切り離す方法やそのためのData管理
• 自分の子供向けSecurityやNetwork Literacyの教育用資料
  • 利便性を最大限に受け取り、リスクを低減するための考え方や対応
• Subversionからの移行先
  • Gitea+Git or fossil or Redmine/svn
    • DSCM (Distributed Source Code Management)を利用する？利用するならどれ？どうせ自分しか使わないならsvn？あたりで迷っている
    • できれば「一つにまとめたい」気持ちもあるけど、「Gitはやだなぁ、難しすぎる」という気持ちもある。
• UnboundをKnot Resolverにするかどうか問題
• DNSの管理問題
  • Internal DNSとPublic DNSの整理と管理問題
• 逸般の誤家庭のNetwork再構成
  • BackboneのDualStack化、BGP+OSPF化、Leafの再構成
  • 拠点間のWireguard VPN接続と経路制御
  • Source Address RoutingとNAT、MultiFIB対応経路制御問題
• NGINX with ModSecurityをやめて、Caddy with Corazaシステムを組む問題
• Suricata on FreeBSD で IPS システムを組み、Log分析システムを作る問題
• 古いServerを一通りVersion Upする問題
• System Monitoring問題
  • FreeBSDに対する、System Configuration管理手法の確立とツールの再設計・再実装(CEoR)
  • CEoRを利用したシステム監視(OSの各種状態取得とData化)
  • 監視データを利用した状態分析および通知
  • CEoRを利用したシステム運用支援ツールの再検討
• 各種システムの冗長化と分散の再検討
  • Dataの同期、WAN環境におけるDB(PostgreSQL)の遠隔地Replication手法の確立
• E-MailにおけるSPFやDKIM、DMARC、ARC署名への対応
  • Postfix+RSPAMdで対応する？
• 認証系システムに関する検討と仮実装
  • LDAP/OAUTH/PAM/Kerberos、２要素認証、２段階認証、など認証関連に関する情報の再整理
• 2025年の祭動画配信に向けた準備

謹賀新年

ここ数年、SNSというかFacebookにばかり色々投稿してきたが、そのおかげで全然こっちに記事を書いていなかった。

確かにSNSは「その場で簡単に」投稿するにはよいのだが、その分、全く手元に記録が残らないので、サービス終了やサービスを利用するのをやめる場合にどうしても残念なことになってしまうことが多い。こっちに記事を書けば記事が残るという意味では良いのだが、SNSと連動させないと今までのような議論はできないわけで、痛し痒しな部分がある。

突き詰めれば、「SystemのOwner」と「DataのOwner」に関して、もう少し考えていく必要があるということになるのだが、まぁ、新年早々いきなり議論するものでもないだろうが、「サービスを提供する」ということを考えた場合に避けて通れないものでもあるので、今年はこの辺を少し考えてみようかな。

それはそれとして、今年は、もう少しこっちに投稿する記事を増やしていこうかとは考えている。考えてはいるが、例によって自分のことなので、やれるかどうかはちっともわからない。

ともあれ、本年もよろしくお願いいたします。

portでソフトウェアをインストールする時、関連するソフトウェアもCompileする。 その際に、「初めてInstall」するものは場合によってCompile Optionを設定する必要があるが、それらが全てdefaultでいい時には、

# BATCH=YES make

もしくは

# make BATCH=YES

とすれば、オプションの選択画面にならずにdefaultの設定のままCompileされる

→ 続き...