SOL12606: Change in Behavior: The default file creation mask of the shell process is now 077
ふーん。
10.2.1 から変わったらしいですよ。
ということは、CLI で何かファイルを作るとパーミッションが 600 になるということですね。
で、それが原因の不具合が下のか。
SOL12600: A UCS archive created from the command line cannot be restored or downloaded from the Configuration utility
Configuration Utility ってのは BIG-IP の Web GUI のことです。
Web GUI では root とか他のユーザが CLI で作った UCS が読めないってことですね。
apache とか tomcat あたりのユーザで読みに行っても、600 のパーミッションじゃそりゃ読めないな。
まあそれはそれで直してくれればいいんですけど、こういう変更って他にも問題がありそうで怖い。
radvd.conf の話も例として書いてあるように、他にもなんかあるんじゃねーのとか心配になってしまう。
BIG-IP 上でファイルを新規に作ることってあんまりないだけに穴が何かありそう。

ちょっと 10.2.1 を入れて遊んでた（仕事中）んですけど、新しいバージョンを入れると AOM とか HSB のファームが書き換えられますよね。
その時にコンソールに表示される機械的なメッセージがすげえ好きなんです。
なんかコアな感じと、停電になったらどうなるんだろう……とか。
趣味の話です。

この前ちょっと小耳に挟んだんですけど、AskF5 の記事は google に公開されているんですね。
AskF5
いつぞやからぐぐると引っかかるようになったから不思議に思っていたんですが、ちゃんと意図してやってたらしいです。
ちなみに以前は登録して HTTPS で見てましたけど、今は HTTP で普通に見えるようになってます。
ここに書く URL も最近は http:// でリンクするようにしてますよ。
ちょっとした小ネタです。

BIG-IP Systems: Getting Started Guide

Important: Beginning with version 10.1.0, you must reformat the systems hard drive partitions even if you plan to maintain 9.x alongside 10.x. Partitions created using version 9.x or 10.0.x software do not accommodate the 10.1.x software. To maintain both versions, you use the image2disk utility to reformat the drive and install the 10.1.x software, and then complete a separate operation using a version 9.x installation method described in the version 9.x release notes. For more information, see To format the drive for volumes and install the software.

この文言忘れてたなあ。
これを出されると負けっぽいけど、違う方向でまだ攻められそうだから頑張ろう。

タイトルの数字忘れたから適当です。
VE も 10.2.1 になって ESX 4.1 に対応してますよ。
10.2.0 でも 4.1 で動くので、「ふ～ん」っていうレベルですけど。
イメージ叩き込めば使えることは分かってますけど、10.2.0 からの upgrade が可能なのかが気になるところですね。
まさか、別で作れとか言わないですよね。
試せばすぐ分かるので、もうちょっとしたら結果を書きます。
b software とかで upgrade できたら嬉しい。
ふと思ったんですけど、VE のイメージって ovf なので KVM とかでも動くのかなあ。
今度環境作ってやってみます。
動いたら色々便利そうですね。

 ないない、と思ってたら SOL ができた。
SOL12584: Change in Behavior: The bigdbd process was removed from the BIG-IP software
別に大した話ではないんですけど、「あれー」ってなるんですよね。
ちなみに daemon の様子は bigstart status で見えますよ。

これも微妙にややこしい話なんだよなあ。

SOL7964: Persistence may fail for subsequent requests on Keep-Alive connections

HTTP Keep-Alive が On だと、Cookie persistence とかがうまく動かない問題。

BIG-IP では TCP の（UDPとかも）コネクションテーブルってのを管理してて、それに沿ってトラフィックを流します。
コネクションが生きてるうちは、それが最優先されて宛先が決定されます。
iRule とかで意図的に「こっち行け！」って指定すればそっちに行きますけど、何もしなければ TCP コネクションがある方向に必ず行きます。
もちろん設定でコネクションを作らないようにすることは可能ですが、コネクションテーブルを参照させたほうが負荷的には軽いので通常は使います。

コネクションテーブルの紹介はこの SOL なのかなあ。
今度また詳しく書きます。（多分）

SOL7606: Overview of BIG-IP idle session timeouts

ここで問題なのがブラウザが同時に二本コネクションを張った場合（よくある）は Cookie persistence がまともに動かないです。

BIG-IP で Cookie persistence の設定をしていることが前提です。
Cookie を持たない別のコネクションがほぼ二本同時に出ると、それぞれが別の pool member に進んじゃって、それぞれコネクションテーブルができます。
その後クライアントは貰った Cookie をリクエストに入れてきますけど、すでにコネクションテーブルができてるのでそれに沿って宛先に到達します。
これはコネクションが切れるまで（Web サーバの Keep-Alive timeout か BIG-IP の idle timeout が切れるまで）Cookie の中身とは関係ないところに行ってしまい、意図した動きと違ってしまいます。
上の SOL は Cookie がある場合にコネクションをぶった切るという雑な回答なので、実際に使うには考慮の余地がありますね。

わかりづらいのでこの記事は改訂するかも……