Google Apps 登録時の電話番号って。
Standard Editionの場合、後からどうやって変更するんだろ。
ふと思って調べてみたのだが、この方法が見当たらない。
管理者のメールアドレスや名前は変更出来るのに、電話番号は設定画面に出て来ない。
というか電話番号って、個人名より変更の可能性は高いと思うのだが。
ちなみにこにネタ、検索で普通のWebやblogを探してもこのテの話が殆ど見当たらない。目立つのはgoogleのForumに出ていた正にズバリの質問、コレぐらい。
＞Google apps に登録した電話番号を変更したいのですが。
＞http://www.google.com/support/forum/p/apps/thread?tid=0e5e56eaf1b28424&hl=ja
個人情報の取り扱いという意味でも、変更どころか確認すら不可ってのは有り得ないと思うのだが。
ん～・・・日本語リソースは無さそうなんで、少し英語の方で探してみるかね・・・。
WindowsのSymbolic LinkはDropBoxではNGっぽい。
ん～残念。
WindowsではVista以降、ほぼUnix系と同等のSymbolic Linkが作れることは意外と知られていないらしい。
まあ普通mklinkなんて使わないだろうし、Unix系に触ってSymbolic Linkの便利さを体験しない限り、そもそも使おうとも思わないのかも知れないが。
一方、最近SugarSyncと共に流行り始めているDropBox。
シンプル故に上手く感覚にハマらないと却って使いにくいが、上手いことハマってくれればこれは結構使えるサービスではある。
ところが・・・実際試してみたら、Symbolic Linkは上手く検知してくれませんでしたとさ、残念ながら。
・・・これ出来たら色々と便利なんだけどな。
やっぱりSugarSyncの方が向いてるのかね？
RDの予約をGmailから拾うために。
恐らく一番スマートでない方法を取ってしまったというメモ。
一言でまとめ：常時稼働している環境にPOP-SSL proxyを仕込む。
・・・さすがにあんまりなのでもう少しだけ補足。
一番メジャーなPOP-SSL proxyはstunnelではないかと。Windows版もありまっせ。
◇
ここからは普通に文章。
個人的な気分の問題かも知れないが、そもそもこのテの「ネット対応」「メール対応」を謳っている家電に、自分の普段使いのメールアドレスを設定するのはどうにも気が引ける。
一応この「気分の問題」にも根拠はあって、
１・パスワードを設定をするのがイヤ
一番の問題がコレ。
手元のRDの他、「ネット対応」「メール対応」を謳っている家電で、over SSL等の暗号化に対応しているというブツはお目にかかったことがない。
ということは、一度パスワードを設定したが最後、コレをナマで数十分毎に垂れ流すという世にも恐ろしい状況に。何ですかこの盗聴大歓迎設定。
更に、内部にパスワードを保持するということは。
故障した時・廃棄の時・中古売却の時、不注意もしくは諸事情により消去し忘れると、第三者にパスワード含めてアカウント情報がだだ漏れに。
それが普段使いのメールアドレスだったらこれ、ホントに致命的でっせ。
２・アドレス設定とかがイヤ
上に書いたアカウント情報だだ漏れの危険性も高いが、何より日常的にもっと大きなコトが。
家電の場合、メールサーバへの接続設定がはっきり言って面倒なことが多いんですわ。そんな面倒なコト何度もやってられますかい。
３・機械用メールと人間用メールがが混ざるのがイヤ
人間用は人間のルールで整理したい一方で、機械用メールは大抵そんなことお構いなしで、ヘタに触るとそれが原因で動かなくなったりする。
何で人間が機械に合わせなあかんのよ。
・・・とまあ、この3段ぐらいで。
以上の問題を解決するには「機械用のメールアドレスを作ればいい」という結論に達します、はい。
とはいえ追加でカネを払うのも何だかな～という方、フリーメールを探してみましょ。
一昔前と違って、タダでも今ではPOPが使えるモノも結構ありまっせ。
具体的にはGmailとGmail OEM系（livedoor mail等）、Windows Live Mail等。
まあどれかのアカウントを使ったとして、話を進めますね。
問題はこの後。
GmailやWindows Live MailではPOP over SSLが必須。まあパスワード垂れ流し防止ということで正しい対応だと思うが、こうなるとRDからは繋がらない。
さてどうする。
ここで登場するのが、手元で常時稼働しているサーバ。
このサーバ上でPOP-SSL proxy、要するに、生POPをSSLで中継してくれるプログラムを動かして、RD→手元サーバ→メールサーバという経路を確立する、と。
当方の場合、手元にほぼ常時稼働中のWindows機があるので、コレにstunnelを放り込んで設定しましたよ、と。
設定さえミスらなければ後は放っておけるので、特に難しいこともない。
＃このWindows機のFirewallに穴を開けるのを当初忘れていて、RDからのPOP接続が全然来ない・・・と首傾げまくったり（ぉ。
◇
・・・結局、なんだかんだで手元に常時稼働サーバが必要というのが、全くスマートでないのだが。
一応これで「普段使いとは別のメールアドレスを予約用に使う」という当初の目的は達しました、とさ。
Tags: Google Apps
サイト用のtwitterアカウント作りました。
@skaz_hinemos
作りました。
取り敢えずメアド非公開のサイトなので、こっちは公開しておきます。
あと、主としてPC関連の小ネタを垂れ流していますが、時折毒っぽいモノが流れる可能性は否定出来ないので御注意を。
＃にしても、Windows用にマルチアカウントをスマートに切り替えて使えるクライアントってのが見当たらない。
Seemicはカスタマイズが全然効かないし・・・。
P3の複数起動とかしか無いのかね？
光vsADSL、RDP6.1 vs RDP5.1。
さて、ニッチとはいえ最低限の新製品は出続ける程度の市場はあるらしい、小規模拠点用のVPN。
具体的にはYamahaやOMRONといった会社の「ブロードバンドルータ」に装備されているPPTPなのだが。
最近、コレについて「リモートでのRemote Desktop Procotolが『使い物になるか』を光とADSLで実際に比べる」機会があったので、少しばかりメモ。
ちなみにリモート操作はいわゆる「ビジネス用途」を想定し、WXGAでExcel・Word・IEを使用して「一連の流れ」を試すというもの。
1) ADSL回線の場合。
規格値8Mbps、VPNサーバ→クライアント実効300Kbps、pingでは150msという、今となっては激遅回線をサーバ側に使った場合。
PPTPサーバはRT58i、クライアント側は光回線。
＞ RDP5.1の場合 ＝サーバ／クライアント共にXP Pro
・・・重い、というかトロい。非常時には使えなくも無いかな、程度。
マウスカーソルすらワンテンポ遅れてくるし、画面スクロールさせると描画を待たされる。その上キー入力だけは忠実に拾おうとするため、操作感覚が無茶苦茶になってしまう。これは基本的には使えない。
＞ RDP6.1の場合 ＝サーバ Vista Enterprise／クライアント 7 Enterprise
激重。非常時にもできれば使いたくない。
画面スクロール以前にマウスカーソルすらまともに付いてこない。これは論外。
2) 光回線対向の場合。
規格値100Mbps、VPNサーバ→クライアント実効50Mbps、pingでは7ms。
PPTPサーバはRTX1100、クライアント側は今回も光回線。
＞ RDP5.1の場合 ＝サーバ／クライアント共にXP Pro
スクロール時等、微妙に引っかかることが多いものの、殆ど普通に使える。
XP登場当時の「エントリーPC」程度のレスポンスは確保されているので、よほどせっかちな人でもなければまぁ普通に使えるのでは。
＞ RDP6.1の場合 ＝サーバ Vista Enterprise／クライアント 7 Enterprise
WXGA程度の解像度ならほぼローカル感覚で使える。明らかに5.1よりスムース。
実際数時間程度使ってみたが、動画にさえ触れなければリモートであることはほぼ気にならない。
◇
とまぁ、簡単にまとめるこういうことで。
どうやらRDP6.1は、ある程度以上の帯域さえあればRDP5.1より快適だが、帯域が不足すると5.1より更に悲惨になる模様。
それと、操作のスムースさについては帯域も当然だが、まずはレイテンシが相当効いてくるということが重要。
いくら光回線で数Mbps程度出ていても100msを超えるような海外相手では、操作感は引っかかりまくりのボロボロ、になってしまうので。
・・・にしても今回、RDP7をチェック出来なかったのがちと残念。
