AMDからサーバー向けCPUであるOpteronシリーズの最新製品が発売（実際にはショップによる受注販売）が始まった。
受注開始となったのはFXシリーズと同じ”Piledriver”コアを採用した「Opteron6300シリーズ」。
AMDから発表されているラインアップは
モデル コア数 通常時クロック ターボ時クロック L2キャッシュ TDP
6386SE 16 2.8GHz 3.5GHz 16MB 140W
6380 16 2.5GHz 3.4GHz 16MB 115W
6378 16 2.4GHz 3.3GHz 16MB 115W
6376 16 2.3GHz 3.2GHz 16MB 115W
6348 12 2.8GHz 3.4GHz 12MB 115W
6344 12 2.6GHz 3.2GHz 12MB 115W
6328 8 3.2GHz 3.8GHz 8MB 115W
6320 8 2.8GHz 3.3GHz 8MB 115W
6308 4 3.5GHz N/A 4MB 115W
6366HE 16 1.8GHz 3.1GHz 16MB 85W
の10モデルで、L3キャッシュ容量は全て16MB、対応ソケットはG34。
今回受注が開始されたのは16コアでTDP85Wの6366HEを除く9モデル。
価格はサーバー用ということでFXシリーズよりもずっと高価で最も安価な8コアの6320でも33,800円、最上位の6386SEに至っては161,800円というプライスタグが付けられている。
サーバー用CPUなのでマザーもそれ用のモノにする必要があるが、SuperMicroのG34マザー「H8DG6-F」等は既にこれらの新CPUに対応しているとのことなので、それらのマザーで旧世代Opteronを使っている人はそのまま乗換えが可能かと。
またクロックよりもコア数を必要とする場合（多数の仮想マシンの構築等）もこれらのCPUに移行すれば性能が向上すると思われる。
More from: サーバ
←クリックしてくれると嬉しいです。
/dev/null が壊れた？
「サーバの一台でcronで実行している処理がおかしいので、調べてみると/dev/nullがおかしくなっている。」
との連絡が来た。
連絡をくれた当人は自分のアカウントでのログインですらエラーが出るとのこと。
調べてみると/dev/nullが通常のテキストファイルになってしまっていて、内容がエラーメッセージになっている（vimが無いとかなんとか）。
恐らくcronで実行している処理かなにかがエラー出力を/dev/nullに吐き出していて、その際に本来はキャラクタスペシャルファイルである/dev/nullをエラーメッセージで上書きしてしまったらしい。
とにかくこのままではいろんな処理が出来ないので、元に戻すことにした。
調べてみると戻し方は簡単で、
#rm /dev/null ; mknod -m 666 /dev/null c 1 3
で済んでしまった。
最初は
#mknod -m 666 /dev/null c 1 3
だけ実行したが案の定「既にファイルがある」と言われてしまったので、先にファイルを削除してから実行したところ新たにキャラクタスペシャルファイルが作成され、元通りになった。
後は上書きしてしまった処理を特定して修正せねば・・・・・
←クリックしてくれると嬉しいです。
1ページが60MB超って・・・・・・
職場のカラープリンタから印刷が出てこないとのSOSがあった。
問題のプリンタはネットワークに接続されていて、印刷用のサーバ経由で印刷するように設定してある。
このプリンタに時折データが送られなくなってしまって印刷が止まってしまう。
原因は大体がデータの容量が大き過ぎること。
プリンタが大きなデータを処理するのに時間がかかりすぎると印刷用サーバが次のデータを送らなくなってしまうようで、キューには溜っていてデーモンも動いているのだけど、実際にはプリンタ側にデータが送られていない状態になってしまう。
今回も1ページの印刷データが60MBを超えるものもあり、一番小さいデータでも30MB強。
こんなのを複数纏めて印刷要求されたらサーバも一個づつしかデータを送らなくなってしまうので、1つのデータが印刷完了するのを待ってサーバ側でデーモンの再起動を行うしか回復の手段が無い。
今回もプリンタの状態を監視しながらサーバ側の操作をしていたけど、なんとかならないものかなぁ？
つか、1ページ分の印刷データの容量が数十メガってどういうことだ？
←クリックしてくれると嬉しいです。
9時間のずれ
職場のサーバを仮想化した際に、一部のサーバのシステム時刻が9時間ほど進むようになってしまっていた。
9時間遅れるのであれば、ハードウェアクロックがUTCになっているにも関わらず設定上はlocaltimeになっていることが考えられるが、反対に9時間進んでいるのが不思議だ。
hwclock -r
でハードウェアクロックを確認してみると、システム時刻（正しく修正済み）に比べて9時間前の時刻を示していたので、ハードウェアクロックはUTCで設定されていた。
そこで
/etc/sysconfig/clock
というファイルの中を確認してみると、
UTC=false
となっていたので、これを
UTC=yes
にしておいた。
これで次回の起動時にどうなるかだな。
←クリックしてくれると嬉しいです。
うまくいった！ と思ったらorz
一昨日から悩んでいるRISOのプリンタ「ORPHIS X7250A」へのLinuxサーバ経由での印刷が上手くいった！
サーバ側のSAMBAの設定でsmb.confのprinterセクションにあるguest ok=noをyesにしたら一度は印刷データをPCからサーバに送ることが出来、そのデータが正しくプリンタまで送られて印刷できた。
と思って実際に使用する部署のPCでチャレンジしたところ全く症状が改善していなかった・・・・・・orz
しかもその後一度（ならず数度）は印刷できたPC（私が普段使っているPC）でも印刷が出来なくなってしまっていた・・・・・
症状は昨日までと同じで、サーバへのデータ送信が出来ない状態。
うーん、どうしたものか・・・・・・・・
←クリックしてくれると嬉しいです。
ちょっとメモ
明日試すことをちょっとメモ。
・net useでのプリンタポートの割り当てをやめて、ポートとして直接サーバ上のプリンタを指定してみる。
・エラーメッセージをもっと細かく調べてみる（「ローカルダウンレベルドキュメント」とか出ていたような・・・・）。
後は・・・・・・・思い出せない（爆）。
←クリックしてくれると嬉しいです。
ちょっとだけ前進か？
RISOのカラープリンタ（「ORPHIS X7250A」）へLinux機からの印刷が出来なくて悩んでいる。
最初はlpdを使ったサーバから印刷させようとして/etc/printcapをいろいろ弄っていたが、どうやってもプリンタ側へのデータの送信が出来なかった。
「もしかしてlprに対応していないのか？」とも思ったが、仕様上は対応していることになっている。
それでも上手くいかないので次にcupsで運用しているサーバでRAWポート（9100番ポート）にデータを送ってみたが、データは送られたように見えるが印刷が出ない（これはプリンタ側に無いユーザーで送ったためと思われる）。
数時間の格闘の末lpdで運用しているサーバからのデータ送信に成功した（と思われる）。
/etc/printcapにはリモートホスト名とリモートホスト上のプリンタ名を記述するが、そのプリンタ名が違っていることが判明。
「ORPHIS X7250A」上のプリンタ名は単なる「lp」らしく、/etc/printcapのrpにlpを指定したところ、それまでスプールに溜まっていたデータが無くなった（プリンタに送られたと思われる）。
それまで「lpt1」やら「pr1」やらのプリンタ名を試していたけど、まさかこんな単純な名前だっとわ（汗）。
気付いたきっかけはWindowsXP上の「Standard TCP/IPポート」の詳細設定で、プロトコルをRAWからLPRに変えてLPR設定のキュー名を「lp」にしたら印刷が出来たこと。
このことで「ORPHIS X7250A」が持つプリンタ名は「lp」だろうと見当がついた。
これでサーバからプリンタへのデータ送信に関しては解決したと思われるが、サーバ上に定義したプリンタに対してクライアントであるWindowsPCから印刷データを送ることが出来ない・・・・・・
現在の接続方法はLPTポート（LPT1とかLPT2）に対してnet useコマンドでLinuxサーバ上のプリンタを接続していて、プリンタの使用するポートとしてLPT1等を指定している。
同じサーバ上の他のプリンタに対してはこの方法で問題無く印刷データを送ることが出来ている（印刷できている）。
ところがサーバ上に定義したRISOのカラープリンタ（「ORPHIS X7250A」）を接続したポートにはデータを送ることが出来ない。
テストページの印刷を試すと印刷開始から即座に
「このドキュメントの印刷に失敗しました。」
のメッセージが出てスプールに残ったままになってしまう。
サーバ上のスプールディレクトリのアクセス権とかもチェックしたが他のプリンタとの違いは無い。
PCからサーバにデータを送ることが出来なければ印刷されるかどうかも解らないままだ。
この問題に間しては昨夕から一歩も進んでいないなぁ・・・・・・・
明日もまたこの問題で悩むことになりそうだけど、多少思いついたことがあるので、明日はそれらを試して見ることにしよう。
←クリックしてくれると嬉しいです。
ORPHIS X7250AにLinuxからの印刷が出来ない・・・・・・・
職場には大型のカラープリンタ「RISO ORPHIS X7250A」がある。
普段は高速のカラーコピー機として使われているが、本来はプリンタなので一部のPCからカラープリンタとして使いたいという希望があり、それらのPCにドライバをインストールした。
ネットワークはいくつかのサブネットに分割していて、その間ではファイルやプリンタの共有を許可していないので、同じサブネット内のPCからしか直接は接続できなくなっている。
なのでプリンタサーバとしているLinux機を経由して印刷しようとしているが、これがなかなか繋がらない。
最初はデータの転送に必要なポートが開いていないのかと思って設定を確認すると、サーバとプリンタの間は特に制限は無いことが判明したので、通信が出来ない訳では無さそう。
プリンタの仕様を見ると各種の印刷用プロトコル（lpr,http,IPP,RAW）に対応しているとなっているのでサーバ側の設定でlprとRAWを試してみた。
RAWに設定したときはサーバ側からはプリンタへのデータ送信が完了した（ように見える）が、プリンタ側のスプールにはデータは入っていなかった。
現在はここで手詰まり状態となっている。
引き続き調べて試せることは試してみよう・・・・・・・
←クリックしてくれると嬉しいです。
Ridocでデータが配信されない・・・・・・
現場のFAXサーバが原因不明の不調に陥り、FAXからのデータが配信されない状態だ。
最初はFAX機そのものの不調だということで、消耗品の交換やセンサーの点検等をして貰ったが、今日になってFAXサーバ上の配信ソフト（RICOH Ridoc Document Router）が配信動作をしていないことが判明。
配信管理ツールから再開させようとしても一向に処理が始まらないので、駄目元でサーバ自体の再起動をしてみても症状は改善される気配が無いorz
配信管理ツールからエラーログを見ると「スキャナドライバの起動に失敗しました」のログが大量に出ているので、必要なサービスがきちんと起動できていないようだ。
タスクマネージャで見ても配信処理を行うはずのDds.exeが動作していない。
インストールされたフォルダからDds.exeを直接起動しても配信処理はされないので、なんらかの不具合がどこかにあるようだ。
こうなったら過去のデータは諦めて貰って配信ソフトの再インストールかな？
←クリックしてくれると嬉しいです。
暑くなりそうだ
札幌は一昨日、昨日と気温が上がり、昨日は最高気温が28.9度と平年（23.1度）よりも6度近く高かった。
今日は昨日よりもさらに気温が上がるようで、予想最高気温は30度と真夏日になることが予想されている。
今日はそんな中を出かけなくてはならない・・・・・・・
しかも荷物を運び出すという作業なので、汗をかくのは必至だなぁ、こりゃ。
でも、あのサーバを持ってこないと業務が（爆）
←クリックしてくれると嬉しいです。