ラベル OS X の投稿を表示しています。 すべての投稿を表示
ラベル OS X の投稿を表示しています。 すべての投稿を表示

2016年8月31日水曜日

Finder(10.9.5)をフリーズさせる"Google Drive"

たぶん2週間ぐらい前からの現象(だと思う...)

いつものようにiMac(10.9.5)に向かい作業を開始しようとして異変に気づいた。
Finderウィンドウを開くとフリーズしてウィンドウの操作ができなくなる。

とりあえず定石の初期設定ファイルの削除、アクセス権の修復などを行っても一向に改善しない。
Finder自体が損傷したのかと思いリカバリーモードからOS Xの再インストールも行ってみたのだがやはり症状は解決せず。

八方ふさがりかと思いきや、初心に帰って別のアカウントを作ってログインして見たら、全く問題がない事に気がついた(なぜに最初に試さない...)のでFinder絡みのアドオンプログラムを順に落としてみたところ"Google Drive"が原因であることが判明。(コンソールログにもエラーらしき羅列がひたすら続く...)
Finder[649]: -[OverlayCache isPathInGdrive:]: unrecognized selector sent to instance 0x7fad3cd495c0
現在Mac版の"Google Drive"は1.31が最新版だけれど、MacBook Airの10.11.6では問題は発生しないので10.9との互換性に問題があるのか、他のアドインとコンフリクトしているのかもう少し検証が必要です。

DropBox, Google Drive, OneDriveと用途別に使い分けてるのでちょっと不便。

2016年5月4日水曜日

"SleepWatcher"の導入にちょいと苦戦(その2)

前回"SleepWatcher"の設置とdaemon化まで完了したので、ここからは"SleepWatcher"に実行してもらうサーバーボリュームのマウント作業のお話。

いろんな先駆者さんのページを参照させてもらうと多分1番多いのは"Automator"で作った自動ワークフローをアプリ化して実行させるというもの。

自分も安易にAutomatorで作ってしまおうかと試みたのですが、うちのファイルサーバーにはボリュームが複数あって、サーバーに接続した時点でボリュームの選択画面(ダイアログ)が出て止まってしまいます。
"OK"ボタンを自動クリックするとか、キーボードの"リターン"を自動入力させるかなどいろいろ考えたのだけれど、いまいちスマートに処理されない。

そもそもシェルスクリプトを実行する環境まで整えておいて、わざわざ別にアプリを用意するってのもすごく遠回りな気がして"Automator"の利用はやめて普通にコマンドを使うことに切り替えました。

外付けHDDと違って "diskutil" コマンドではサーバーボリュームはマウントできないので、Macのボリュームをマウントするのに最適な "mount_afp" コマンドを使って実行。
manによると書式は以下のとおり。

mount_afp afp://[user[;AUTH=uamname][:password]@]host[:port]/volumename node.

わかりづらいけど、今回ウチの場合は
mount_afp afp://user_name:passwd@192.168.xxx.xxx/Data /Volumes/Data
って感じ。

"afp_url"の記述もmanによれば"IP Address"か"AppleTalk Name"どちらでも良い感じだったので、簡単だったIPで記述。
パスワードが平文ベタ書きだけど、お家ネットワークなのでこの際気にしない。

あと、マウントの前にマウントポイント(ディレクトリ)が存在しないとエラーになるので

mkdir /Volumes/Data

というコマンドも追加。
一つ悩んだのが、スリープ突入時に処理する ".sleep" のスクリプトを使うかどうか。

どうせスリープ復帰時にアンマウントされてしまうならわざわざ処理しなくても良いかとも思ったのだけれど、テストをしてみるとイマイチうまくいかない。

たぶん正常にアンマウントされていないと、復帰時にシステムがボリュームを探す動作と ".wakeup" のマウントスクリプトが実行されるタイミングが合わない様子。
ということで ".sleep" も利用してボリュームをきっちりアンマウントさせてからスリープに入るように

diskutil unmount /Volumes/Data

を記述して保存。
まとめると、

".sleep" の内容
#!/bin/sh
diskutil unmount /Volumes/Data

".wakeup" の内容
#!/bin/sh
mkdir /Volumes/Data
mount_afp afp://user_name:passwd@192.168.xxx.xxx/Data /Volumes/Data

という2つのファイルを作成。
"SleepWatcher"の動作テストをする前にスクリプト単体で動かして ".sleep" でアンマウント、".wakeup" で再マウントの動作が正常に出来ることを確認。

で、いよいよ"SleepWatcher"のテストコマンド
$ /usr/local/sbin/sleepwatcher --verbose --sleep ~/.sleep --wakeup ~/.wakeup
で動作確認をしてみると何やらエラーを吐いてボリュームが再マウントされない。

Unmount successful for /Volumes/Data
sleepwatcher: sleep: /Users/hogehoge/.sleep: 0
mkdir: /Volumes/Data: File exists
mount_afp: AFPMountURL returned error -1069, errno is -1069
sleepwatcher: wakeup: /Users/hogehoge/.wakeup: 54016

".wakeup"による再マウント動作ではなぜか"mount_afp"のエラーで失敗してしまう。
  Balun Software (Info)さんのサイトでエラー番号"error - 1069"を調べてみると

AFPMountURL returned error -1069, errno is -1069
・error -1069 = aspNoServers (No servers at that address)
・サーバー名を間違えていた。
との事らしい。

いやいや、それはおかしい。
ターミナルから".wakeup"を単独実行すれば100%問題なくマウントできる。
"afp_url"の記述にミスが有るとは思えない。

しばらくのたうち回ったけれど"SleepWatcher"からの実行がどうにも成功しないので、半ば諦めかけた最後にダメ元で"afp_url"をIPアドレスからサーバー名にしてみることに...。

出来ました。(^_^;
どんな理由でIPアドレスだとダメなのか全くわかりませんが、"afp_url"をマシン名にしたところあっさり成功するようになりました。 (逆のパターンはよくあるのですけどね...)

ちなみに"afp_url"の名前は一度接続したことのあるサーバーであれば、"Finder"の「移動」メニューから「サーバーへ接続...」を選択して出てくるウィンドウで確認できます。


ローカルネットワークで共有している"Time Capsule"の場合 afp://Time%20Capsule._afpovertcp._tcp.local
といったURLとなります。

最後の最後でかなり手間取りましたがなんとか希望の環境が実現できました。

【追伸】
"diskutil"による、アンマウントであれば、".wakeup"に記述した"mkdir"の行は必要ないかもしれませんね。 (Finderのイジェクト動作と違ってアンマウント時にマウントポイントを削除しないため)

2016年5月3日火曜日

"SleepWatcher"の導入にちょいと苦戦(その1)

2台目のMac Book Airの導入と一緒にTime Capusuleを導入してNAS化してます。

Time CapsuleのNAS化と同時に仕事用のデータを保存していた外付けHDDもTime Capsuleに接続してNAS化させてしばらく運用しているのだが、なぜか"Mac mini"だけスリープから復帰した時にNASのボリュームがアンマウントされてしまったまま復帰しない。

起動時には"システム環境設定"→"アカウント"の"ログイン項目"でサーバーボリュームを登録しているので問題なく自動マウントされる。
Mac miniは利用しているCADソフトウェアのバージョン推奨環境維持のために10.6(Snow Leopard)からアップグレードできていないので、その辺りに問題があるのかもしれない。

普段仕事をしていてデータの保存を実行した時に「ボリュームが見つからない」旨のエラーを吐くので、その段階でNASのマウント作業を行っていたのだが、流石に鬱陶しくなって来たのでまじめに問題解決を試みた次第です。

「スリープ復帰」「NAS」「自動マウント」などでググるとかなり大量に情報が出てきます。どの記事でも共通しているのは"Sleepwatcher"というdaemonプログラムを利用している事。

つまりはスリープのタイミングを監視してくれる常駐プログラムを利用してリモートドライブをマウント/アンマウントする命令を自動的に実行するってことだ。

とりあえず"SleepWatcher"で検索すると一番最初に出てくる作者(?)のサイト(http://www.bernhard-baehr.de/)から最新版らしい"SleepWatcher 2.2"をダウンロードして解凍。

ReadMeファイルに書かれたシンプルな説明にそってプログラムのセットアップ。
コマンドのインストールと常駐化させるところまでは説明通りに配置するだけなので特に複雑な作業はありません。

動かす分には置き場所はどこでも良いのだろうけど、Unix/Linux流儀に合わせてなのかMac OSには用意されていない "/usr/local" 以下に "sbin" と "share/man/man8"のフォルダを用意してそれぞれSleepWatcherの本体とmanualファイルを格納。

/usr/local/sbin/sleepwatcher
/usr/local/share/man/man8/sleepwatcher.8

次に自動実行させるためのコンフィグレーションファイルの配置。
ここは2択になっていて "/Library/LaunchAgents/" 以下に格納してシステム起動時に常駐化させるか、~/Library/LaunchAgents/" 以下に格納してローカルユーザーがログインした時に常駐化させるかでplistファイルがそれぞれに用意されています。

plistファイルの中身を覗いてみるとローカルユーザーで実行したほうが何かと便利そうだったので、予め用意してくれている "de.bernhard-baehr.sleepwatcher-20compatibility-localuser.plist" をそのまま自分のホームディレクトリにある "Library/LaunchAgents/" の中に格納。

~/Library/LaunchAgents/de.bernhard-baehr.sleepwatcher-20compatibility-localuser.plist

plistファイルをいじらずに利用するのであれば、自動実行スクリプトのファイル名は
スリープ突入時:~/.sleep
スリープ解除時:~/.wakeup
となっています。

めんどくさがり屋なので、私はそのままホームディレクトリ(/Users/<user name>)直下にターミナルから ".sleep" と ".wakeup" ファイルを "touch" コマンドで作成。(この段階でまだ中に何を記述するか決まってなかったので入れ物だけ作ってしまいました。)

正直 "."(ドット) から始まる隠しファイルはFinder上からは扱いにくいのだけれど、かと言ってファイル名を変更するとplistファイルの中身も編集しなきゃならないし、ホームディレクトリに目障りなファイルが鎮座するのも嫌なのでデフォルトのままの方が無難だと判断した次第。

実は本題はここから先で、用意した ".sleep" と ".wakeup" の中にどんな命令を入れるかが一番の肝で、実際に少し悪戦苦闘したのだけれど前置きだけでかなり長文になってしまったので続きは次回に...。
(^_^;

【補足】
"LaunchAgents" に登録した "plist" ファイルは一旦ログインし直すか "launchctl" コマンドを使って手動で常駐化させるまで機能しませんのであしからず。

$ launchctl  load ~/Library/LaunchAgents/de.bernhard-baehr.sleepwatcher-20compatibility-localuser.plist

2016年2月20日土曜日

2015年度の確定申告(e-tax)

毎年すんなり終わらない確定申告(e-tax)作業。
今年はしょっぱなから大コケしてます。

流石に老朽化しレスポンスが悪く使い勝手の悪かった"Mac Book(Late 2007)"を"Mac Book Air(Ealry 2015)置き換えたせいでノートで作業ができないはめに...。

e-taxは今のところ"El Capitan"に未対応(対応するカードリーダードライバーもない)らしくせっかく新調した"Mac Book Air"が使えない。

気を取り直して引退するはずだった"Mac Book"で接続してみると....
ご利用の環境ではe-Taxをご利用になれません。
e-Taxの推奨環境のOS/ブラウザにてご利用いただくか、前の画面に戻り、書面提出を選択してご利用ください。
とのメッセージ。
なんと今年からe-taxは10.8以降しかサポートしていないようです。


歴代のMac OSはすべて揃っているので早速"Mac Book"を"Mountain Lion(10.8)"へアップグレードしようと"Mac APP Store"へ接続してみると今度は
OSX Mountain Lion はこのコンピューターと互換性がありません。
のメッセージ。orz
Mountain Lionは"Mac Book"だと"Late 2008 Aluminum"以降しか対応していないようです。

さてどうしたものかいな。

【追記】
どうやら”Java 7"がサポート対象外になったことが10.7が動作環境から外されたようです。
"Java 8 JDK/JRE"が”Mountain Lion(10.8)以降でしか動かないみたいのでこれは止む終えないのかな?
"Java 8 SE"は動くみたいなんだけど...。

2015年3月17日火曜日

Skype for Macのバナーブロック

最近ちょくちょく「画像の添付がリンクになって送られてきて困る」って話をスタッフの子の相談に乗ってるうちにうっかり自分のSkypeのバージョンを上げてしまいました...。(T_T)


スタッフ間の業務連絡以外ではほとんど利用もしていないのでスキンの変更などそれほど気にならないのだけれど、バナーが表示されるようになったのはかなり痛い。
ネットで古いバージョン探して「再インストール」って手もあるんだろうけど、それもなんだか負けっぽいので、バナーだけブロックする方法を調べてみた。

Windows版だとみなさん「インターネットのプロパティ」でURLブロックしてるみたいなんだけど、Macだと簡単なURLブロックの機能が実装されていない。(「ファイアーウォール」あたりでURLが設定できれば良いのに、プログラムしか登録できないしね。)

というわけで、簡単に "/etc/hosts" ファイルでSkypeのホーム(http://apps.skype.com/)を間違った場所へ導いて表示させない方法を取りました。

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost
fe80::1%lo0     localhost

127.0.0.1       apps.skype.com

viエディターなどで "/etc/hosts" ファイルを編集。
"apps.skype.com" を実際のIPではない "127.0.0.1" に指定し、ローカルマシンに向かせる。w
「ホームへ繋がらない」ってエラーを吐くようになるけれど、バナーは表示されなくなりました。

どんなアプリからも一切"apps.skype.com"には繋がらなくなっちゃうけど、Skypeのホームなんかに縁はないのでとりあえず良しとしましょう。

2015年3月5日木曜日

持病の「どこでもMy Mac」接続障害

先週、月に1〜2度発生する自宅のiMac(10.8.5)からのリモート作業(画面共有)で、事務所の"Mac mini"(10.9.5)が応答しなくなっていることに気がついた。orz

利用頻度は少ないものの、いざという時にかなり不便なので"Mac mini"の「どこでもMy Mac」をメンテナンス。

とりあえず
  • 「ファイアーウォール」をOFFにしてみる。
  • 「iCloud」コンパネから「どこでもMy Mac」をON OFFしてみる。
  • "iCloud"からログオフ、再度ログオンしてみる。
を実行してみたものの、状況は変わらず...。


iCloudは「どこでもMy Mac」以外のサービスが利用できているのに「サーバに接続できません。」の一点張り。w
システムログを確認してみるとサービスをONにした直後から"mDNSResponder"(Bonjour)のエラーが大量に出ている。

mDNSResponder[40]: Adding registration domain 9*****4.members.btmm.icloud.com.
mDNSResponder[40]: ERROR: recvSetupResponse _telnet._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _ssh._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _uscan._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _printer._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _ptp._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _scanner._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _autotunnel6.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _ftp._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server
mDNSResponder[40]: ERROR: recvSetupResponse _ipp._tcp.9*****4.members.btmm.icloud.com. (PTR) code 6 from server

"btmm.icloud.com"ドメインからのサービスに接続できていないみたいなので、なんとなくこれが原因っぽい。(「どこでもMy Mac」の英語版は"Back to My Mac"なので、"btmm"は「どこでもMy Mac」のサーバーなんだろうね...)

ひと通りルーターやファイアーウォールを確認しても、これといって接続障害を招く要因が見当たらないため、困ったときの「アクセス権の修復」のおまじないをかけてみます。

幾つか修復されたアクセス権の中で気になるものが一つ。

“Library/Preferences/com.apple.alf.plist”上のグループが一致しません。80 であるはずですが、グループは 0 になっています。
“Library/Preferences/com.apple.alf.plist”を修復しました

ファイアーウォールの初期設定ファイルのグループ属性が修復されています。
本来"80"(admin)であるはずのグループ属性が"0"(wheel)になっていると...。

アクセス権の修復後、無事に「どこでもMy Mac」のサービスは起動するようになりました。(多分初期設定ファイルを削除して作りなおさせても良かったのかもしれません。)

ただ、後から"com.apple.alf.plist"ファイルのグループ属性を確認してみても"wheel"のままなのですが、いったい「アクセス権の修復」コマンドって何をやってるんでしょうね?

そもそも、なぜこんなに頻繁にファイルのアクセス権が変更されてしまうのかも疑問なのですが...。


P.S
ファイアーウォールの設定を確認していて、リモートシェル(ssh)のサービスも使えないようになっていることに気がついた。


「どこでもMy Mac」の接続障害を直すついでに"sshd-keygen-wrapper"への外部からの接続を許可しておきました。

2015年2月18日水曜日

e-TaxのためにLION(10.7)へアップグレード

未だに現役で頑張っている我が家のMacBook(Late2007)は「Carbonアプリ」も少し動いている関係で未だに10.6.8(Snow Leopard)の状態。

普段妻や子供がインターネットを閲覧するくらいなら全く問題ないスペックなのだが、今年も確定申告の季節がやってきたため、妻がデータ入力出来るように例年通り"e-Tax"の申告書作成ページにアクセスしてみると思わぬ注記が...。

Macintosh 環境の場合
OS Mac OS 10.7
 Mac OS 10.8
 Mac OS 10.9
ブラウザ Safari 6.1
 Safari 7.0
PDF
閲覧ソフト
 Adobe Reader X
 Adobe Reader XI

※MacOSのプレビューは
推奨環境外です。
※Windowsの推奨環境は割愛してます

なんと今年から"Snow Leopard"は推奨環境対象外にされてしまいました...。orz
(多分処理できないことはないんだろうけど、事前チェックがあるのでね)

MacBook(Late2007)のスペックを調べてみると、稼働するOSの最終バージョンは"Mac OS X 10.7.5"となっているので、バージョンアップすればどうにかまだ利用できそう。

"System6"時代からかれこれ25年も利用してきたので、歴代OSのインストールディスクはひと通り揃っているのだけれど、あいにくLION(10.7)からはOSがダウンロード配布に切り替わり、それまでのようなインストールディスクが存在しない。


そのうえMavericks以降のように"Mac App Store"での無料配布方式へ移る過渡期のものなので入手方法も一手間余分...。

まずWeb版の本家"Apple Online Store"で「ダウンロードコード」のみを購入し、このコードをデスクトップ版"Mac App Store"へ入力してダウンロードを完結するらしい。(なぜ最初から"Mac App Store"で売らないのだろう?)

この際仕事用のメイン機(iMac)も業務ソフトの互換性維持のためプリインストールの10.7のままだし、ついでに"Mountain Lion"のダウンロードコードも購入。(最近「10.7」では動かないアプリが多くなってきたんですよね...。)

さすがに仕事専用のマシンを"Yosemite"にはできないし"Mavericks"でもちょっと怖い。w
「OSのインストーラー」としてはこの2バージョンだけコレクションから欠落していたので「まぁこの際購入しておいても良いかな?」ってノリです。w

"Apple Online Store"の検索窓に"lion"って入れれば出てきます。逆に「"Macアクセサリ"→"ソフトウェア"」とカテゴリからたどっても見つかりませんでした。


どちらも税込みで2,000円ポッキリ。(以前は1,700円ほどだったので早く買っておけばよかった...。)
すでに最新のMac OSは無料配布なので2,000円の出費は微妙なところですが、"Windows8.1 Pro"がMS参考価格で25,800円(税別)もすることを考えれば良しとしましょう。

で、カートに入れてポチッと購入完了。すぐに「受注確認」メールが届きます。
それから3分後「注文確定」メールも到着。案内には「ソフトウェアのダウンロードはオンラインのご注文状況をご利用ください。」とある。

その時点で"Apple Online Store"のアカウントサービスを覗いてみると「処理中」のステータス。
コードの発行なんてリアルタイムでも出来そうな処理なのに割と複雑な作業をしているようです。

ちょうど正午ごろ発注し、その日のうちには「ダウンロードコード」が通知されるのかと思いきや夜になっても届かない。
まだ手続き中なんてことはないだろうと"Apple Online Store"で確認してみると注文ステータスは完了となっている。


この文面を見る限り、コードも発行完了して「すべての処理は完了しました」って雰囲気です。
あわてて受信メールの「迷惑メール」フォルダを確認してみたりしても「コードの通知メール」が確認できないため、不安になって本日サポートに電話で問い合わせてしまいました。

結果的には「まだメールは配信していない」そうです...。orz
まぁね、確かに商品説明には「出荷予定日:1〜3営業日にメールを送信」とありますし、けして「遅いぞ!(#゚Д゚)ゴルァ!!」などというつもりはありません。

でもせめて注文ステータスは「出荷準備中」くらいにしておいてくださいな。てっきりメールを見失ったと思いましたよ。
(;´Д`)ハァ

というわけで、確定申告は10.7のダウンロードコードが届くまではお預けです。w

2014年11月11日火曜日

Mac経由で感染するマルウェア「WireLurker」

"Palo Alto Networks"から「Mac OS X」経由でiOS端末にトロイの木馬を仕込む「WireLurker」が発見されたとの発表があった。

「App Store」経由でのアプリケーション配布のおかげで簡単に入り込めなかったiOSの環境に、"Mac OS"経由でワームを仕込むという手段に打ってできたようです。

JailBreak(脱獄)していないiOS端末に感染するワームがとうとう出現してしまったわけですが、OSのシェアが広がれば当然ターゲットになってくるだろうし、こういう事態になるのも必然なのかもしれません。

取りあえず「ウィルス」ではないので、今のところ勝手に感染が拡大することもないし、得体の知れないソフトウェアを簡単に入れてしまうような行為がなければそれ程心配することもないとは思います。

中国の「Maiyadi App Store」というアプリ配布サイトで467のプログラム内に仕込まれているのが判明しているそうです。

パソコン経由で仕込むのであればWindows経由でも出来そうなんですが、なぜか"OS X"経由なんですね。OS全体のシェアというよりはiOSの母艦としてのシェアを考えての攻撃なんでしょうか?

"Palo Alto Networks"が「WireLurker」の検出ツールを公開してくれているので、海外から色んなアプリを集めている人は念のためにチェックしてみるのも良いかもしれません。

GitHubで公開されているpythonスクリプトの"WireLurkerDetectorOSX.py"をダウンロードしてターミナルから実行するだけです。

1)まず「ターミナル」アプリを立ち上げ、以下のコマンドでスクリプトをダウンロード。
$ curl -O https://raw.githubusercontent.com/PaloAltoNetworks-BD/WireLurkerDetector/master/WireLurkerDetectorOSX.py

2)ダウンロードしたカレントディレクトリからスクリプトを実行
$ python WireLurkerDetectorOSX.py

以下のように進捗状況が表示されてチェックしてくれます。
$ python WireLurkerDetectorOSX.py
WireLurker Detector (version 1.2.0)
Copyright (c) 2014, Palo Alto Networks, Inc.

[+] Scanning for known malicious files ...
[-] Nothing is found.
[+] Scanning for known suspicious files ...
[-] Nothing is found.
[+] Scanning for infected applications ... (may take minutes)
[-] Nothing is found.
[+] Your OS X system isn't infected by the WireLurker. Thank you!

最近被害が多いのは「割れソフト」に仕込まれたマルウェアの感染。
アプリケーションは信用できる場所から正規のソフトウェアだけインストールしましょう。

2014年5月15日木曜日

OS X Server の証明書期限切れアラート

5月に入った頃久しぶりにOS X Server(10.8.5)に画面共有で接続してみたところ、Serverプログラムに大量の「警告バッジ」が付いていることに気が付いた。


どうやら「各種SSL証明書の有効期限が切れている」って事らしいのだが、ヘルプとか調べてみてもあまり詳しい解説が見当たらない。

アラートの中にもそのまま「証明書の置き換えボタン」が付いている物もあったので、そのまま深く考えもせずポチッと更新して置いたのですが、本日また接続してみるとまだアラートの止まっていない物がある。


"証明書APSP"から始まる数種類の物がずっと期限切れのエラーを吐きっぱなし。
"APSP"が何の略なのかよくわからないけど「APSP」「証明書」で検索すると、同じ事例が大量にひっかかるので、Apple製品特有の証明書であることは間違いなさそう。

で、検索で最初にリストされていた"Bloggerさん"のサイトを参考に"キーチェーンアクセス"から期限切れの証明書をサクッと消して作業完了。
OS X Serverって毎年こんなメンテナンスが必要なんでしょうか?
たいした作業ではないけれど鬱陶しいですね。

2014年4月15日火曜日

LIONのアイコンが低解像度化する不具合

3月入ってから消費税変更に伴うシステムの変更で予定が狂わされ、本業がバタバタしすぎてブログ記事が全部下書き状態な日々がまだまだ続いております。
また8%から10%に増税の時もまた同じようにバタつくのはちょっと勘弁して欲しいところです。

そんなことはさておき、4月7日にSafari(6.1.3)のアップデートを行ったあたりから、なんだかいくつかのアイコンのドットが荒くなってしまっている。



Dockに登録した"Safari"と"Chrome"、あと"Launchpad"上で見る"Evernote"。
Dockから一旦消して再登録してもダメだし、「"拡大"機能を入りにする」で見てみると、解像度が固定されてしまっているような状態。

ファインダー上で確認する限りはアイコンリソースが壊れている感じでも無さそうなんだけどね。

見た目が悪いだけでそれ以上の障害は起きていないので今のところ放置プレイ中。