ヤフオク

落札価格がいくら安くても、

◇送料 (一律3500円)(北海道4500円)(沖縄5500円)

じゃ同じ価格かより高い?

 

配当金にかかる税金 2倍に?

源泉徴収税率平成25年12月31日まで
一律10.147%(所得税+復興特別所得税7.147%、住民税3%)
平成26年1月1日~平成49年12月31日
一律20.315%(所得税+復興特別所得税15.315%、住民税5%)
これって誰が決めたの? 消費税よりも上がってるし・・

 

windows DVD maker error について

~windwos dvd メーカーで 99.9%で 書き込みerror で失敗!

 

拡張子wmvでは、失敗するそうで、 拡張子mpegにすると成功する!

 

仕方ないので、変換ソフトで wmv → mpegに変換した

 

なぜ、wmvじゃダメなんだろう?

 

MSの質問、回答にこのことは書いてなかったよ

ベトナム反中デモ、報道と言論に「規制」か?

南シナ海における中国とベトナムの海上取り締まり船衝突事件によって、ベトナム国内では激しい反中デモが繰り広げられている。現地や香港などのメディアからは中華系住民が被害を受けたとの情報が多数流れているものの、大陸のメディアはほぼ「無反応」状態だ。情報を出そうとしない中国政府やメディアに対して、ネット上では不満をぶつける中国人ユーザーも出てきた。著作権はSBIサーチナ株式会社に属します。
© 2014 SBI Searchina Co., Ltd. All Rights Reserved.

rsyslogd-2177: imuxsock begins to drop messages from pid 1209 due to rate-limiting

rsyslogd-2177: imuxsock begins to drop messages from pid 1209 due to rate-limiting

rsyslogのバージョン5.7.1から、rate-limitingという機能が追加され、5秒間に/var/log/messagesへ200以上のメッセージ

(rsyslogのデフォルト設定)を送信したプロセスID(PID)があれば、rsyslogはメッセージを捨て始め、/var/log/messagesに以下のような

警告をだすらしい?

Feb 5 13:07:52 plugh rsyslogd-2177: imuxsock begins to drop messages from pid 12105 due to rate-limiting

そのため、/var/log/messages等にメッセージを出力するデーモンあるいはプロセスの場合、セキュリティ管理者/システム管理者にとって、

重要/重大なメッセージが紛失してしまっている、特にsnortのerror reportなど

以下の方法で 対策するのだ・・

rsyslog.early.confに (通常は、/etc以下にある)、下記設定を追加

$SystemLogRateLimitInterval 10

$SystemLogRateLimitBurst 500

上記は、rsyslog.confに追加する。

または

$SystemLogRateLimitInterval 0

この設定により、rate-limiting自体が無効になが、プロセスIDが使い道のないメッセージで/var/log/messagesがいっぱいになる可能性がある、

(そういう訳で、rate-limitingがrsyslogにおいてデフォルトで有効になっている

CENTOS5.~ 6に変更(メモ)

5と6は全然違うので、新規insatllする。細かい説明は省きます。

CentOS-6.5-x86/64-minimal.iso を download し CD またはDVD に 焼く。

PCを起動し、DVDで立ち上げる、その後は、通常のinstallと同じ。

メモリーも少ないので、GUIではなく、通常MODEで・・

installが完了すると、DVDが吐き出されるで、一応OKだとわかる。

再起動をかける、

デスプの下側に黒、青の線で起動しているのがわかる、

名前も付けてないので、

localhost login:

まぁ rootで 設定したパスでログInする、まずnet接続用のeth0 の設定 これは、画面を見ながら手動入力

]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=”eth0″
HWADDR=”xx:xx:xx:xx:xx:xx”
TYPE=Ethernet
NM_CONTROLLED=”yes”
ONBOOT=”yes” ← ネットワーク自動起動設定
BOOTPROTO=static ← IPアドレス固定設定
IPADDR=192.168.0.6 ← サーバーのIPアドレス(例:192.168.1.30)を入力
NETMASK=255.255.255.0 ← ネットマスク(例:255.255.255.0)を入力
GATEWAY=192.168.0.1 ← ルーターのIPアドレス(例:192.168.1.1)を入力
DNS=xxx.xxx.xxx.xxx ← ープロバイダーのDNSを入力

]# /etc/rc.d/init.d/network restart ← ネットワーク再起動
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: [ OK ]

~]# ping -c4 yahoo.co.jp   ← ネットワーク疎通確認(外部サイトへPINGを実行)

PING yahoo.co.jp (203.216.243.240) 56(84) bytes of data.

64 bytes from f11.top.vip.tnz.yahoo.co.jp (203.216.243.240): icmp_seq=1 ttl=51 time=10.6 ms

64 bytes from f11.top.vip.tnz.yahoo.co.jp (203.216.243.240): icmp_seq=2 ttl=51 time=10.2 ms

64 bytes from f11.top.vip.tnz.yahoo.co.jp (203.216.243.240): icmp_seq=3 ttl=51 time=9.78 ms

64 bytes from f11.top.vip.tnz.yahoo.co.jp (203.216.243.240): icmp_seq=4 ttl=51 time=8.84 ms

? yahoo.co.jp ping statistics ? 4 packets transmitted, 4 received, 0% packet loss, time 3013ms rtt min/avg/max/mdev = 8.848/9.864/10.610/0.663 ms

DNSSEC BIND97 CENTOS5.9

一応前の bind93は削除しておく、

yum -y install bind97 bind97-utils bind97-chroot bind97-lib

bind97-9.7.0-17.P2.el5_9.2.i386.rpm bind97-chroot-9.7.0-17.P2.el5_9.2.i386.rpm bind97-libs-9.7.0-17.P2.el5_9.2.i386.rpm

bind97-utils-9.7.0-17.P2.el5_9.2.i386.rpm

chroot環境で動かすので、var/named/chroot ディレクトリにファイルを移動します。

etc]# cp -ip /etc/named.* /var/named/chroot/etc

named]# cp -ip /var/named/named.* /var/named/chroot/var/named/

named]# mkdir /var/named/chroot/var/named/{dynamic,slaves,data}

named]# chown named.named /var/named/chroot/var/named/{dynamic,slaves,data}

chroot環境で起動するために、/etc/sysconfig/named の設定。

これでROOTDIRにchrootした状態でbindが起動します。

ROOTDIR=/var/named/chroot

# /etc/init.d/named start

Starting named: [ OK ]

起動はOKそうなので STOPして 設定fileを作りましょう、
?内部用DNS
?キャッシュサーバとしては動かない
?DNSSECを使う

以上を加味して

#]vi /var/named/chroot/etc/named.conf

options {

#listen-on port 53 { 127.0.0.1; };

#listen-on-v6 port 53 { ::1; };

version “unknown”;

directory ”/var/named”;

dump-file ”/var/named/data/cache_dump.db”;

statistics-file “/var/named/data/named_stats.txt”;

memstatistics-file “/var/named/data/named_mem_stats.txt”;

allow-query { localhost; localnets; };

recursion yes;

allow-recursion {localnets;};

dnssec-enable yes;

dnssec-validation yes;

dnssec-lookaside auto;

empty-zones-enable no;

/* Path to ISC DLV key */

bindkeys-file “/etc/named.iscdlv.key”;

forwarders{ xxx.xxxx.xxxx.xxxx;xxxxx.xxxx.xxxx.xxxx;}

; };

logging {

channel default_debug {

file “data/named.run”;

severity dynamic; };

category lame-servers { null; }; };

view “internal” { match-clients { localnets; }; match-destinations { localnets; };

zone “.” IN { type hint; file “named.ca”; };

include “/etc/named.rfc1912.zones”;

include “/etc/named.root.key”;

include “/etc/named.ex.com.zone”;

};

controls { inet 127.0.0.1 allow { localhost; } keys { rndc-key; }; };

include “/etc/rndc.key”;

};

rndckeyを使うので、keyを作成

chroot]# rndc-confgen -a -b 512 -c /var/named/chroot/etc/rndc.key -u named -r /dev/urandom

wrote key file “/var/named/chroot/etc/rndc.key”

rndckeyの動作確認

]# rndc -k /var/named/chroot/etc/rndc.key reload

server reload successful

動作は一応OKです

zone の設定、DBの設定はいつもと同じなので、ここには書きません。

・DNSSECの設定(BIND97は手動でないとだめみたい)

ルートゾーンのトラストアンカーの入手と確認方法

トラストアンカーは、KSK(Key Signing Key:鍵署名鍵)の公開鍵、またはそれを元に生成されたハッシュの形で提供される。公開鍵の場合はDNSKEYレコードの形で、ハッシュの場合はDSレコードの形で提供される。

まず、digコマンドを用いてルートゾーンのDNSKEYレコードを取得する。「.」(ルートゾーン)のDNSKEYレコードを問い合わせ、結果からKSKが含まれた行のみを抽出する。

$ dig . DNSKEY | grep -w DNSKEY | grep -w 257 > root-anchors.key $ cat root-anchors.key . 172800 IN DNSKEY 257 3 8 AwEAAag【中略】Uk1ihz0=
ルートゾーンののDNSKEYレコードの取得

次に、入手したトラストアンカー(root-anchors.key)を検証する。ここでは例として、PGPの実装の1つであるGnuPG(The GNU Privacy Guard)を用いた方法を示す。トラストアンカーの検証は、次のステップで行う。

1.IANAのPGP公開鍵の入手
2.IANAのPGP公開鍵の検証
3.トラストアンカー(DSレコード形式)と署名の入手
4.IANAのPGP公開鍵によるトラストアンカー(DSレコード形式)の検証
5.トラストアンカーのDNSKEYレコード形式からDSレコード形式への変換と比較

【1】IANAのPGP公開鍵の入手

https://data.iana.org/root-anchors/icann.pgpより、IANAのPGP公開鍵を入手する。そして、入手したicann.pgpを次のコマンドでインポートする。

$ gpg –import icann.pgp gpg: key 0F6C91D2: public key “DNSSEC Manager <dnssec@iana.org>” imported gpg: Total number processed: 1 gpg: imported: 1
PGP公開鍵のインポート </dnssec@iana.org>

【2】IANAのPGP公開鍵の検証

入手したIANAのPGP公開鍵について、鍵IDとフィンガープリントを確認する。

$ gpg –fingerprint dnssec@iana.org pub 1024D/0F6C91D2 2007-12-01 DNSSEC Manager <dnssec@iana.org><dnssec@iana.org>Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2 sub 2048g/1975679E 2007-12-01
PGP公開鍵の鍵IDとフィンガープリントの確認 </dnssec@iana.org></dnssec@iana.org>

「0F6C91D2」がPGP公開鍵の鍵ID、「Key fingerprint = 」に続く16進数が鍵のフィンガープリントである。

次に、鍵IDを基に複数のPGP公開鍵サーバで検索し、一致していることを確認する。ここでは、確認をより確実なものとするため、pgp.nic.ad.jpとpgp.mit.eduの2つの公開鍵サーバで公開されている鍵と照合している。

$ gpg –search-keys –interactive –keyserver pgp.nic.ad.jp 0x0F6C91D2 gpg: searching for “0x0F6C91D2” from HKP server pgp.nic.ad.jp Keys 1-1 of 1 for “0x0F6C91D2” (1) DNSSEC Manager <dnssec@iana.org><dnssec@iana.org><dnssec@iana.org>1024 bit DSA key 0F6C91D2, created 2007-11-30 Enter number(s), N)ext, or Q)uit > 1 pub 1024D/0F6C91D2 created: 2007-12-01 expires: never Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2 DNSSEC Manager <dnssec@iana.org>Do you want to import this key? (y/N) N gpg: Total number processed: 1
PGP公開鍵のフィンガープリントの照合(1) </dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org>

$ gpg –search-keys –interactive –keyserver pgp.mit.edu 0x0F6C91D2 gpg: searching for “0x0F6C91D2” from HKP server pgp.mit.edu Keys 1-1 of 1 for “0x0F6C91D2” (1) DNSSEC Manager <dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org>1024 bit DSA key 0F6C91D2, created 2007-11-30 Enter number(s), N)ext, or Q)uit > 1 pub 1024D/0F6C91D2 created: 2007-12-01 expires: never Key fingerprint = 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2 DNSSEC Manager <dnssec@iana.org>Do you want to import this key? (y/N) N gpg: Total number processed: 1
PGP公開鍵のフィンガープリントの照合(2) </dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org>

フィンガープリントが一致すれば、「PGP公開鍵が同一のものである」と検証できたことになる。

【4】IANAのPGP公開鍵によるトラストアンカー(DSレコード形式)の検証

次のコマンドを実行し、署名の検証を行う。

$ gpg –verify root-anchors.asc root-anchors.xml gpg: Signature made Wed Jul 7 07:49:10 2010 JST using DSA key ID 0F6C91D2 gpg: Good signature from “DNSSEC Manager <dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org>” gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 2FBB 91BC AAEE 0ABE 1F80 31C7 D1AF BCE0 0F6C 91D2
root-anchors.xmlに対する署名の検証 </dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org>

上記の「gpg: Good signature from “DNSSEC Manager <dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org><dnssec@iana.org>”」というメッセージは、正しい署名であると確認できたことを表している。</dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org></dnssec@iana.org>

【5】トラストアンカーのDNSKEYレコード形式からDSレコード形式への変換と比較

root-anchors.xmlには、DSレコード形式のトラストアンカーが記載されている。しかし、BIND 9ではトラストアンカーをDNSKEYレコード形式で登録する必要がある。このため、入手したトラストアンカーをDNSKEYレコード形式からDSレコード形式に変換し、root-anchors.xmlに記載されているものと一致しているか確認する必要がある。

DNSKEYレコード形式からDSレコード形式への変換は、BIND 9に付属するdnssec-dsfromkeyコマンドを利用する。

$ dnssec-dsfromkey -a SHA-256 -f root-anchors.key . . IN DS 19036 8 2 49AAC11D【略】
トラストアンカー(DSレコード形式)への変換

4列目の鍵タグ(この例では、19036)と、7列目のDSレコード形式のトラストアンカー(この例では、49AAで始まる文字列)が、root-anchors.xmlに記載されている「KeyTag」「Digest」と一致することを確認する。なお、DSレコード形式の文字列に含まれる空白は、あらかじめ取り除いておく。

root-anchors.xmlの内容とコマンドの出力が一致すれば、入手したトラストアンカーは正しいものであると判断できる。

BIND 9.7系では、DNSSECの検証を行う設定はデフォルトで有効になっているが、手動でトラストアンカー(DNSKEYレコード形式)を設定する必要がある。トラストアンカーを設定するには、managed-keysステートメントを用いる。下記のとおり、「. initial-key」の後ろに、入手したroot-anchors.keyの「257 3 8」以降を続けて記述する。公開鍵の部分は「”」で囲み、行末に「;」を付け加える。

managed-keys { . initial-key 257 3 8 “AwEAAag【中略】Uk1ihz0=”; }
BIND 9.7系のトラストアンカーの設定

digコマンドを用いて確認を行う。

$ dig +dnssec jprs.jp @192.0.2.1【キャッシュDNSサーバのIPアドレス】
digコマンドによる確認

このコマンドは、キャッシュDNSサーバに対して、DNSSEC要求を有効にしてjprs.jpを問い合わせるものである。jprs.jpはDNSSECに対応しているため、実行結果として、名前解決の結果に加えて検証結果が表示される。

; <<>> DiG 9.7.3 <<>> +dnssec jprs.jp ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19744 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 11 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;jprs.jp. IN A ;; ANSWER SECTION: 【略】 DNSSECの検証が成功した場合の実行結果 上記で作成したものを named.conf に追加する 最後の行に trusted-keys { “.” 257 3 8 “AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF (中略)QxA+Uk1ihz0=”; }; と記入すればいい。 ]# dig @127.0.0.1 +dnssec jp ; <<>> DiG 9.7.0-P2-RedHat-9.7.0-17.P2.el5_9.2 <<>> @127.0.0.1 +dnssec jp ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42628 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;jp. IN A ;; AUTHORITY SECTION: jp. 900 IN SOA z.dns.jp. root.dns.jp. 1394265606 3600 900 1814400 900 jp. 900 IN RRSIG SOA 8 1 86400 20140331174501 20140301174501 4905 jp. (中略)NS SOA RRSIG DNSKEY NSEC3PARAM ;; Query time: 9 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Mar 8 17:03:50 2014 ;; MSG SIZE rcvd: 487 とadが確認される。以上です

プリンター?

NECのPICTY-4000使ってたけども、紙のローラが変形して給紙できなくなった

ローラがハート型に変形? 長年放置しておくとこういうことになる

ヤフオクで CANNON 500円で買ったのはいいけど、INKがない?

即ヤマダで 購入 って 3200円たかぁ~ !!

インクが本体の5倍とは?(;´д`)トホホ…