tarファイルでアーカイブする時に、特定にディレクトリを除外したいケースがある（ログディレクトリやバックアップディレクトリなど）
そのような時には–excludeオプションを指定する。ファイルでもディレクトリでもマッチしたものを除外する。ディレクトリの場合は階層指定しないとマッチしたもの全てが除外されるが、特定のフォルダのみにしたい場合は階層をしていすればOK
複数の除外条件を指定する場合は–excludeを複数記載するべし。
#.svnディレクトリを除外する。 tar cvzf ~/test.tar.gz svn_work/ --exclude .svn #.svnディレクトリとlogsを除外する。(logsファイルも除外されるので注意) tar cvzf ~/test.tar.gz svn_work/ --exclude .svn --exclude logs #logsの*.txtを除外する tar cvzf ~/test.tar.gz svn_work/ --exclude logs/*.txt
S3ではライフサイクルの設定をすることで作成から一定の日数を経過したファイルを削除することができる。
これ一見便利なのだが、どうも削除されていないようなときがあり、気になったので徹底的に調べてみた。
といっても一時間毎にaws s3 ls してファイル数をカウントしてログに出力するシェルをcronで回すだけだが。
そして驚いたことにS3のライフサイクルの実行（削除）は毎日日替わりであることが判明した。
とある日は9時反映、
とある日は13時
その次の日は19時,
翌日も19時,
その翌日はスキップされ
今日は14時に実行されていた。
5/20は１５時
5/21は１１時
5/22はスキップ
5/23は１２時
5/23は１０時
というわけでS3のライフサイクルの実行は気まぐれであったというお話であった！
タリーズでフリーWIFIを提供している店舗があるというので、使い勝手をレポートすべく体験してきた。
場所はタリーズコーヒー 横浜ポルタ店
その他のタリーズコーヒーでも都心部にあれば、提供されていることが多い。
タリーズWIFIといっても実質WI2のWIFIネットワークを利用しているので、そちらの回線品質に左右される。
まずPCでつなぐと追加のログオンが必要ですなどの画面が出てきて、利用規約同意の画面に誘導される・・・にはなんかいかブラウザを立ち上げ直して、適当なページにアクセスする必要がある。
利用開始前にこのような複雑な手順を踏まなければいけないのが、日本のフリーWIFIのだめなところ
スマートフォンも面倒な手続きが必要かと思いきや、スマートフォンだとそのままつなぐことができた。
利用前に同意をとるというのが日本のフリーWIFIの主流らしいが、外国人観光客の立場に立ってみると「漢字読めないのにいろいろ変なページに飛ばされてもワカンネーヨ。日本のフリーWIFIダメじゃん」との烙印を押されるのではないか？
性悪説に立っている日本のフリーWIFIと性善説（野放し？）に立っている外国のフリーWIFIとの大きな違いを感じた。
この場所だけの問題だと信じたいが、回線品質は悪い。
1分もしないうちに途切れてそのたびにつなぎ直し。
スピードも5Mbps程度
これならテザリングしたほうがいいよねってわけで、残念賞
すでにレガシー過ぎて普通は入れないJDK6を最新のMacOS El Capitanにインストール
JDK7からはOracleサイトで配布されるようになったが、それ以前のJDKはAppleから提供されている。
Java For OSX 2015-001で検索すると該当ファイルのダウンロードページに行ける。
あとはクリックしてインストールすると使えるようになる。
インストールされた場所が知りたい場合は以下のコマンドでどうぞ！
/usr/libexec/java_home -v
本日Windows7で作業中にいきなり再起動がかかった。
これまでにも何回か同じような現象に見舞われたことがあったので、徹底的に突然再起動の原因を調べてみた。
まずは管理ツールのイベントビューアでシステムログをみる。
結構たくさんあるけど、再起動がかかる時間以前までさかのぼってみると
再起動があった8時25分に以下のログがあり、どうやらシステムにより定期再起動が走った模様。
次の理由で、プロセス C:\Windows\system32\svchost.exe (PCNAME-PC) は、ユーザー NT AUTHORITY\SYSTEM の代わりに、コンピューター PCNAME-PC の 再起動 を始めました: オペレーティング システム: 回復 (計画済)
理由コード: 0x80020002
シャットダウンの種類: 再起動
コメント:
その15分前に以下のログを発見。WindowsUpdateでの再起動らしい。
再起動が必要: 次の更新プログラムのインストールを完了するために、15 分以内にコンピューターが再起動されます:
– Microsoft .NET Framework 4.6.1 用セキュリティ更新プログラム、Windows 7 向け (KB3127233)
– Microsoft .NET Framework 4.6.1 用セキュリティ更新プログラム、Windows 7 向け (KB3143693)
– Microsoft .NET Framework 4.6.1 用セキュリティ更新プログラム、Windows 7 向け (KB3122661)
– Microsoft .NET Framework 4.6.1 アップグレード言語パック (KB3102433)
– Microsoft .NET Framework 4.6.1 用セキュリティ更新プログラム、Windows 7 向け (KB3136000)
思い出してみると昨夜再起動を促すポップアップがでて、4時間後にしたものの夜寝る前だったので、そのままシャットダウンしてしまったが、このパッチの再起動が勝手にスケジュールされたのかもしれない。
普段ならシャットダウンの時間を尋ねるダイアログがでるが、今回はダイアログすらでないので凶悪仕様である。
（もしかしてダイアログが出た瞬間にタイミング良くEnterキーを押すとダイアログに気付かずにシャットダウンを設定してしまうのかもしれないが）
2015年04月以降に同様の問題が頻発するようになったらしく、最近クリーンインストールで入れたWindows7のWindowsUpdateが一向に終わらないので真剣に解決策を調べてみた。
まず普通にやった場合更新プログラムを確認していますが10時間以上たっても一切終わらない。
（最初は2時間ぐらいかと思ったけど、ぜんぜん終わらないので一晩放置。翌朝も一緒）
Windows7の32bitだとメモリ不足になるのが原因という記事もあったが、該当マシンは8GBを積んでおり利用メモリも1.4Gほど。
ここで2016/03月時点での解決策をネットで検索
どうもKB3138612のパッチをあてないとだめらしい。
このKB3138612のダウンロードするまでが一苦労で、該当のマシンではIE9のためパッチを手に入れるページにすら入れない。IE11にしてみたら今度は固まる（MSのサイトはクソですね）
しょうがないので別のマシンでKB3138612をインストールして再起動して、WindowsUpdateをしたところ今度は無事に進んだ。ただしパッチ159個の700Mダウンロードだが（これも一度では終わらずに失敗する可能性大）
SSH公開鍵認証ログインのみを許可してかつアクセス元IPを/etc/hosts.allowで絞っているため、ログインできないのだが、しつこく攻撃してくるやつらがいる。
こういったやつらの攻撃の場合ログに以下のように出力される
Apr 25 00:40:28 tk2-207-13289 sshd[24818]: refused connect from 181.114.222.233 (181.114.222.233) Apr 25 01:16:37 tk2-207-13289 sshd[25164]: refused connect from S010644d9e7079248.cn.shawcable.net (24.64.90.202)
このような不届きもののIPをgrepしてさらに出現回数を数えるスクリプトはこちら。
# grep refused /var/log/secure* | awk -F" " '{print $10}' | sort | uniq -c | sort -r -n
574 (159.226.170.42)
540 (14.63.221.39)
535 (120.33.121.155)
357 (158.69.203.183)
337 (159.226.125.73)
232 (196.47.178.191)
184 (115.110.139.134)
123 (112.33.7.18)
わずか一カ月の間に500回以上も不正アクセスしやがって！
まぁあの国なのでしょうがないか。
Windows10にして戻したらむちゃくちゃになってしまったCF-S10のWindows7
こんなこともあろうかとインストール後のクリーンなシステムイメージを取得していたのだが、
ついにそれが役に立つ時が来た！
Let’s noteだとD2Dがあるので、そちらをこれまで使うことが多かった。
実はWindows標準のシステムイメージから復元するのは初めてなのである。
(パッチ当てが大変なのでLet’s noteのD2Dはなるべく使いたくないと最近システムイメージを取るようにしている)
手順は
コントロールパネル→バックアップの作成→システム設定またはコンピューターの回復→高度な回復方法→以前に作成したシステムイメージを使用してコンピューターを回復する→再起動がかかる
復元には20分程度かかったが無事きれいなWindows7を回復できた。
二台あるCF-S10(常用と予備)の片方がWindows10のアップグレードがまだだったので権利だけでも獲得しておこうと約一か月前にアップグレードした。
しばらく使ってやろうかと思ったけども、Windows7では一切発生しなかったフリーズが一日2回発生した事件を契機にWindows7に戻すことにした。
しかし戻すのに30Gの空きスペースが必要だと言われたりして空き領域を増やしたり、
戻した後でタスクトレイにあるIEが起動しなくなったり、特定のサイトでFirefoxのJavaScriptが機能しなくなっていたり、Chromeがエラーで起動しなくなっていたり、むちゃくちゃの状態で復元されてしまった。
Windows10から戻したら起動エラーが出るようになった
特に見た目正常に動いているように見えるFirefoxでボタンが押せない状況になっているのは困る。
これでは信用できないのでWindows7のシステムイメージからの復元するはめになりそう。
（もともとアップグレードインストールは不安定の元だから信用してないし、Windows7に戻したのもリストア前提なので良いのだが）
Ansibleのretryファイルには失敗したホストの情報が記載されている。
これはこれでたくさんのホストに対して設定を行うときには便利なのだが、実験用途で使っていると知らないうちにHOMEディレクトリがretryファイルだらけになってしまう。
そんな時はansible.cfgファイルで生成しないように設定してしまおう。
[defauls]セクションの下に以下の記載を追加！
retry_files_enabled = False
これでAnsibleタスクが失敗しても、retryファイルが生成されなくなるので思い切って失敗できる！