忍者ブログ
Admin / Write / Res
ちゃんとカテゴリ分けされておりませんので、 記事をお探しならブログ内検索が便利です。 ご活用くださいませー+.(≧∀≦)゚+.゚
ブログ内検索
カレンダー
03 2024/04 05
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
カウンター
アクセスカウンター
最新コメント
[04/05 Fully Vaccinated Adorable Escort Service in bengaluru 8273600238]
[03/26 Tonaldcet]
[01/16 jilibet]
[10/20 Call Girl in Delhi]
[09/07 לפרטים נוספים]
最新トラックバック
プロフィール
+ハンドル+
y_ayamori(purple)
+職業+
IT系エンジニア
+すまい+
さいたま
バーコード
[1]  [2]  [3]  [4]  [5]  [6]  [7]  [8]  [9
ふと、いい感じのPCケースを見つけました。

http://www.aerocool.us/pgs/pgs-q/qx2000.htm

なんかカッコいいわ。。

3.5インチベイ2段+1
5インチベイも2段で申し分ない

ファンも最大で合計3つ装着できるみたいでエアフローもよさげ。
まぁ、このあたりは配線の取り回し次第もありそうだけど。

電源の取り回しも問題なさそうねー
ボーナス入ったら買いたい

でも、移植は大変なのよねー
しかもケースって一番大掛かりなのよねー

あんま暇もないし、またこんどかぁ
残念

でわでわ

拍手

PR

MySQLのテーブルに格納されたコマンドをシェルのコマンドラインで実行する方法

mysql --default-character-set=utf8 --host=localhost -u root -p`cat /etc/psa/.psa.shadow` --database='database' -e"select command from command_table ;"  -B -s | sh

--default-character-set=utf8
文字コード指定は必要に応じてどうぞ

--host=localhost
ホスト指定も必要に応じてどうぞ

-uroot
ユーザ指定は必須ですが、どのユーザを使うかはシステムにあわせてどうぞ

-p`cat /etc/psa/.psa.shadow`
パスワードはノーパスにしていることはないでしょうけど、ライン入力か
直接指定かは必要に応じてどうぞ
ちなみにプロセスを確認するとパスワードはマスクされます。
そのためパスワードファイルの場所をうまく隠せば案外使いようはあります。

--database='database'
データベースの指定は必須です。
--database= と記述するかどうかはご自由にどうぞ

-e"select command from command_table ;"
SQL文を-eオプションに引き渡します
この時出力される結果がコマンド文になるようにカラムに格納しておきます

-B
バッチモードで出力します
要は枠線がなくなります
出力結果から直接コマンド実行する場合は必須かもしれません

-s
サイレントモードで実行します
カラム名(見出し)が出力されなくなります
出力結果から直接コマンド実行する場合は必須かもしれません

 | /bin/sh
出力結果をシェルに渡します
shを使うかbash かcsh かzshなのかはお好みと要件にて

でわでわ

拍手

すぐに忘れるので備忘録

SET PASSWORD FOR ''@'localhost' = PASSWORD('newpwd');
http://dev.mysql.com/doc/refman/5.1/ja/default-privileges.html

アディオス!!


拍手

あんまり、殺意を私は覚えないんですが、、、
普通覚えないか

その中でもこんなニュースを拝見すると
おまえら消えろ
http://www.asahi.com/national/update/0806/NGY201008060010.html?ref=rss

なんか・・
なんかズレてる気がするのよね・・

なんで被害者単位じゃないのカナ。。。
なにが言いたいかって、被害者の苦しみとかって、「量」ぢゃないと思うのよね・・・
大量殺人だから事件性があるとか
幼児虐待死だからいいだとか・・・
関係ないと思う
人命軽視としか言葉がでないのですが
どうなんだろう?

ヤクザの争いとかだったらまぁ、特に何も言わないんですけどー
もともとそういう可能性がある中で人生背負って立っているわけですから。
あと、、介護疲れとかね。

一方的に強い立場を利用し、追い詰め社会貢献に影響がでるレベルになると
どうしても解せないわ。

あたしが思うに、そう、普段から人を平気で追い詰める事の出来る人間に
更生の余地はないと思うよ?
死刑支持派だからね。

未成年で許されるのは若さだけの勢いで過ちを犯した場合だけ。
悪意ある罪は相応な償いを追うべきと考える。

そのための死刑があると思うので私は死刑支持派なのです。

情緒不安定なのでちょっとしたことにもイラッとくるこの頃。
ちょっとは感動的な話もききたいけど世の中、
お涙頂戴の歪曲型ドキュメンタリーばかりなので。

どうの悲観的なこの頃ですわ
でわでわ


拍手

さすがに戦いがしんどくなってきました・・・
いろいろ悪戦苦闘したのですが、どうしても開発環境へ繋がらない。

もっと言うと、LAN内異セグメント間通信は可能であるのに、WANには出ない。
なじぇ?
LANもWANもIPアドレスこそ大きく値が違うものの、ネットワークセグメントが異なるのも一緒だし、
なぜ同じように通信できないのでしょうか?

そもそもの構成なのですが、
ルータ -  GWサーバ - サーバ群
の構成で今回ルータがなくなりその機能をGWサーバが兼任することにしました。

でこのGWサーバとサーバ群は似たような感じでもう1セットあって開発環境と呼んでいます。
開発GWSVはルータがなくなっても、グローバルIPはひとつしかもらえないので
スタティックルートをルータから本番GWSVに変更すればそれだけで理論上いきそうですが・・・

なぜかうまく行かない。
本番サーバ群と、開発サーバ群はそれぞれネットワークセグメントを2つずつもっていて、
各GWSVがルーティングとマスカレードを行う。
そして各本番と開発同士で通信は可能であるにもかかわらず、もう一つWANという
ネットワークセグメントには開発環境からは到達しない。

仕方ない、ルーティングの話となれば早くしないと、サーバ機能そのものが停止する。
遊びだけど悠長にやっている暇は今はないので、本番GWSVにもう2つNICを挿し、
開発GWと本番GWを統合する。

そもそもグローバルIPはひとつしかなくネットワークの冗長化は実施しない以上、
開発GWSVは本番GWSVのステージングには成り得無い。
だとすればそもそも開発GWSVの存在意義が無い。
ホストOSのリソースを開放するためにもこの際、なくしましょう。

ということで本番GWSVにNICの追加ー
げ?、いつの間に7つも刺さっていたわ・・・
セグメントもバラバラだし。。。
動くには動くんでしょうけど、、、
整理しますか・・・

と、いうことで
eth0 物理ネットワークセグメント
eth1 本番サーバ群ネットワークセグメント
eth2 本番サーバDMZセグメント
eth3 開発サーバ群ネットワークセグメント
eth4 開発サーバDMZセグメント
eth5 クライアントネットワークセグメント
eth6 DHCPクライアントセグメント
eth7 WAN(DHCP)

と、なった・・・
さぁ、たちあがれインターフェース達よ!
/etc/init.d/network restart

-bash: /etc/init.d/network: No such file or directory

ワァオ♥
debian系列のネットワークのリスタートってどうするのよ?
(._.;)どれどれ
networkingらしいわね(汗
/etc/init.d/networking restart

途中までー
順調にー
来たけどー
eth7にIPがふられなーい!!
どーゆーことよ?

いろいろ調べた結果、どうもeth5に最初IPを振っちゃったから、eth7に貸し出す
分はネーヨ!、って言われているみたいね。
なんかいろいろと、dhclient -r eth5とかしてみたけどダメみたい。
もしかしてリリース期限切れ待ち?
リース期間は6時間みたいだけど、またなきゃなの?

どーにもならなそーなので待ってみることに・・・
はたしてそれでeth7にくるのかどうかも、疑問なのですが、、、

まだ、格闘はつづきそうです。
でわでわ

拍手

なんか、人生最大の選択に迫られている気がする
人生の選択肢なんてそうそうあるものではないわ。

いろいろ考えていたらウツになってきたのでサーバをいじってみる。

squid 。
プロクシサーバですね。
これにpleskを組み合わせてみる。
つまり、web,mail,dns,db,proxy,anti virusといった外部向けサービスと
内部向けサービスを混同させるわけです。
なぜこんな構成になっているかというと、たんに分けるほどリソースがいろいろなかったのね。
あとは外部と接触あるサーバは極力、少なくしたかったと言うのもあります。

で、問題発生。
Plesk画面にアクセスするとたまにハングアップする。
!?
原因はわからないけど、かなりの時間を要してしまうのは確か。
たまにMysqlにアクセスできないエグゼプションがでる。

どういう事なのか、裏方に入って調査してみると?
そもそもSSHの反応が帰ってこない。

相当、リソースを食いつぶしているみたいね。
だば、正面きってコンソールから。
う~ん、重い。
が、入れなくも無い。

で、topをみる、、、
リソースの食い潰し犯はsquidのよう。。。
なじぇ?
Plesk関係ないやん!

もうちょっと調べるとPleskで作業する際、恐ろしくサーバに負荷がかかっているようです。
特にメモリを大量消費。
その容量なんと200MB程度。

もともと256MBしか積んでいないため限界の様子。
しかもswap領域をなぜか使おうとしない。

メモリリソースを奪われたsquidはパニクるのかCPUをひたすら使い出す。
しかもこちらも何故か、VM上のCPUリソースは100%なのにホストのCPUにさほど影響がない。
なじぇ?

兎にも角にも、こうして悪循環負荷サーバ構造が出来ていた。
恐るべしだな、まるでウィルスのようだ。
が、しかたない、対処せねば!
取りあえず、メモリを512MBへ。

今度は快適。
やっぱりメモリ不足のようね。
とんだお騒がせだわ。

拍手

zsh
 zsh 一点だけつかいにくいなー

まぁ、zsh自体初心者ですけどー

何が使いにくいかってー

コマンドラインに”#”を投入すると

# # test comment.      
zsh: command not found: #

う~ん (笑
bashはどう制御しているの?
別にシェルに記述する分には特に影響ないのにね。

# cat test.zsh                                                                                           [65,0]
#!/bin/zsh
# Print out run user.
whoami
exit 0
# zsh ./test.zsh                                                                                         [66,0]
root

ははっ^^
なんだろー

ってなところで
ちょっと使いにくいなー
って、
おもうことがあったのでした。

でわでわ
 

拍手

 run-parts発見。

そーかー
/etc/crontabの中だったかー
すぐ忘れるのよねー (^▽^;)

猫ると・・
# cat crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
 
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
 
# for logrotation only
00 0 * * * root run-parts /etc/cron.logrotate

なるほど、/etc/cron.logrotateを呼んでる!
この中には!!
logrotate

(・vv・) ハニャ???

logrotateコマンドで/etc/logrotate.confを引数にしていますね。
これはまさかの
/etc/cron.daily/loglotate
と一緒ってヤツ?
どーなっているの?

# ll /etc/cron.daily/loglotate
ls: /etc/cron.daily/loglotate: そのようなファイルやディレクトリはありません

ない!
なるほど、どういうわけか0時に実行したく、外出しにしてるのねー
でもこれだけぢゃ、実行タイミングの問題だけでなぜcronの機能そのもが動いていないことの説明にならないわー (ノ△・。)

しかたないわねー
もう少し調査しないとか

てか、
仕様書作りなさいよねー
設定した人ー (≧ヘ≦) ムゥ

でわでわ

拍手

 気づいてはいけないことに気づいてしまった気がするの。。。
# 気が3本も立ったわ。。。

あるシステムのウェブサーバのログローテーションが・・・
機能してない



ウカツだったわ。
設定は確認したけど、動作してないなんて。。。

cronのログローテートを追っていくのはなんかしんどい。。。
やれやれ。。。

とりあえず、現状、、、
# ls -lh /var/log/messages
-rw------- 1 root root 182M  6月  8 10:01 /var/log/messages

たいしたことないわねー
どーでも良くなってきたわぁ
 

で、記述は/etc/logrotate.d/syslogにされていますと。。。
んでこれはなにから呼ばれているかって・・・
/etc/cron.daily/loglotateの/etc/loglotate.confから呼ばれていますと。。

で、/etc/loglotate.confは何を記述しているかってと、、、
/etc/loglotate.d配下をIncludeしてますって話。

めんどくさッ

要はデイリーで動いているはず。
そしてデイリーで動くための記述はあった!!
なぜ動いとらん?

まさか??
# crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.874 installed on Tue Apr 20 10:44:24 2004)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
0 4 * * * /sbin/hwclock --systohc
0 6 * * * /export/home/tools/ [企業機密項目]
0 18 * * * /export/home/tools/ [企業機密項目]
0 5 * * 1 /export/home/tools/ [企業機密項目]
#0 5 * * 1 /export/home/tools/ [企業機密項目]
#0 0 * * * /export/home/logbackuppl/ [企業機密項目]
#5 19 * * * /export/home/tools/ [企業機密項目]
 
# 2010/3/24 [企業機密項目]
10 4 * * *  [企業機密項目]

ク、cronから呼ばれてねぇ~
run-partsはどこいったのさ~?

ん?でも別システムのウェブサーバのログローテートはたしか正常だったような・・・  ???r(・x・。)アレ???
どれどれー  ・・・(-_-)ジィー
うん、正常  (>▽<)b OK!!

で、cron...と
((= ̄□ ̄=;))ナ、ナント!!
一緒ぢゃん!!
なんで動いてんのさ(笑

だば、本腰入れて調査しますか。
ミソが欲しいであります!!

でわでわ
 




拍手


永遠のライバルというほど開発者は意識していないでしょうけど。
利用者は勝手ながら機能についてあやれこれやと注文をつけたがる。

しかもフリーウェアなのにね。

で、どちらがいいかというと結論が出ない。
もはやケースバイケースである。

■teratermの利点
1.安定している。
これは大きいと思う。
Podeはしょっちゅう表示がバグる。
バグではないでしょうけどバグる。
んあ~

2.Teratem Pro Assistantがある
これはほぼ同じような設定を複数のサーバで実施する場合に便利。
前に紹介したPoderosaのプラグインもかなり有効だけど、すべての(分割)ウィンドウにブロードキャストしてしまうのが難点。
「ほぼ」同じ設定をするんだけど所々異なる箇所が違う。
たとえばDB2台、PC系WEB2台、Mobile系WEB2台とかだったりすると、
・全サーバ同じ設定
・WEB系が同じ設定
・同系統で同じ設定
・個別設定
というシチュエーションはteraなら全部に耐えられるのに対し、Podeは全サーバと個別のみだ。
これは環境によりきりだけど非常に大きい。

3.マクロ
teraのマクロはTTLというオリジナル(?)の言語。
非常に単純で、わかりやすい。
定例的に同じ作業をするとき便利ね。

4.scp
ウィンドウに放り込むだけでファイル転送が完了する。
これ、思った以上に便利よ?

5.Read in Text
コマンドを列記した、テキストを実行してくれる機能がある。
開発系でログを取り、整形して本番環境に流すなんてことがOK。


■Podeの利点
1.画面分割
ひとつのウィンドウに収まっているため、非常に見やすく管理しやすい。
全サーバで同じ設定や個別設定、左右でtailfしながらバッチ処理などその恩恵は計り知れない。

2.接続ショートカット策性能容易さ
teraはマクロを組まなきゃならないけど、数ステップでできるのはありがたいよね。


結論
どちらがいいか結論が出ない。
teraに画面分割を搭載されたら、Podeは勝てない(私の中では)し、逆にPodeにTTPA相当の新規プラグインがあったら、Podeだと思う。
まぁ、無難はteraなのかなぁ、ってところ。


業務で使用していると悩ましいところがおおなぁって思ったのでした。
でわでわ

拍手

Copyright ©  アナログを愛するデジタル生活館 All Rights Reserved.
* material by Pearl Box   * Template by tsukika

忍者ブログ [PR]