作業履歴

 
 
 

2008年

 
  • 11/03
    ネットワーク
    • L2 VLAN スイッチ導入
      ネットワーク配線を集約する為、2つの LAN を Tag VLAN 接続に変更。

      対象ネットワーク:
      192.168.2.0/24 管理ネットワーク
      192.168.3.0/24 プライベートネットワーク

FW

  • Tag VLAN 対応
    管理ネットワーク用に割り当てていた em1 デバイスを Tag VLAN に対応させ、
    配下の L2 VLAN スイッチと接続。
    FW ⇔ スイッチ間は Tagged 接続となった。
    管理ネットワークとプライベートネットワーク双方と接続可能に設定変更し、
    プライベートネットワーク用に割り当てていた rl0 デバイスを off にした。

  • DHCP 設定変更
    ネットワークの VLAN 化に併せて、DHCP Liten インターフェースを
    物理から VLAN インターフェースへ変更した。
 
  • 09/18
    FW & WWW
    • ORZ 設定変更
      WWW の ORZ とは別に FW の port 20080 でもう一つ ORZ を立ち上げた。

      外部クラスタサーバから FW ORZ が保持している cache への取得要求の一部が
      port 20080 に行かず、port 80 に飛んでくる模様。
      port 80 は WWW へポートフォワードしている為、WWW ORZ(orz.tukizakura.org) に
      FW ORZ(orz2.tukizakura.org) への要求がきてしまう。
      ORZ のバグと思われるが、取り合えず運用で回避する手段として mod_rewrite
      を使って本来届くべきホストへとリダイレクトする。
      FW 側にも rewrite があるのは、FW ORZ が持つ cache へのリクエストが
      WWW ORZ からも発生してしまう為。
      ○FW への設定
      WWW ORZ から FW ORZ port80 への cache リクエストをリダイレクト 
      RewriteCond %{HTTP_HOST} orz2\.tukizakura\.org
      RewriteRule ^/cache/(.*)?$ http://%{HTTP_HOST}:20080/cache/$1 [R,L]
      
      
      ○WWW への設定
      外部クラスタ ORZ から誤って飛んでくる port80(本来は FW ORZ port 20080)
      への cache リクエストをリダイレクト
      
      RewriteCond %{HTTP_HOST} orz2\.tukizakura\.org
      RewriteRule ^/(.*)?$ http://%{HTTP_HOST}:20080/$1 [R,L]

      ※)mod_redirect によるリダイレクトは成功しているが
      リダイレクト後、dat-control 側でキャッシュ無しと判定されるのか、
      FW に再度のリクエストが飛んでこない模様。
 
  • 08/30
    WWW
    • QUOTA 制限有効化
      /home 領域の各ユーザスペースに xfs quota 制限をかけた

 
  • 08/16
    WWW
    • ORZ 設定変更
      orz.cgi を persistentperl として実行させる為の登録方法を変更
      変更前
      AddHandler persistentperl-script .cgi
      
      変更後
      <Files orz.cgi>
        SetHandler persistentperl-script
      </Files>

    • 一部ユーザの所属グループ変更
      「Courier-Imap 受信エラー」

      原因:
      次期メールシステム以降テストの際に、一部ユーザの所属グループをそのユーザの
      /etc/passwd エントリに登録してあるグループとは別グループに所属させていた。
      Courier-Imap では Maildir 以下のファイル所有者が上記エントリにあるのと同じでないとエラーになる。

      対処:
      一部ユーザの所属グループ変更
 
 
  • 08/11
    WWW
    • プロセス実行ユーザ変更
      bind 並びに swatch の実行ユーザを変更。
      あわせて関連するスクリプトやログの所有者も変更した。

      変更のあったファイル
      • bind
        /usr/local/etc/init.d/00named.sh
        /usr/local/etc/bind
        /var/log/named → /var/log/bind に変名

      • swatch
        /usr/local/etc/init.d/swatch.sh
        /usr/local/tukizakura/sbin/swatch_reload.sh
        /usr/local/etc/swatch
        /var/run/swatch → /usr/local/etc/swatch/PID へ移動
        /etc/cron.d/sysstat
        /etc/cron.weekly/sysklogd
        /etc/logrotate.d/*
 
  • 08/10
    WWW
    • Apache deflate 対応
      ORZ で推奨される .dat ファイルの圧縮送信に対応する為に、--enable-deflate 付きでリインストール
      PersistentPerl を導入している為か負荷が殆ど上がらずに outbound を約 2/3 にまで抑えられた。

    • ORZ PersistentPerl CGI化を失敗
      Apache module でなく CGI としてスクリプトが実行不可。
      コマンドラインからは実行出来るも原因不明。
 
  • 08/08
    WWW
    • su 経由の root ユーザを制限
      su を使って root へなれるユーザを制限する。
      $ sudo vim /etc/pam.d/su
      auth       required   pam_wheel.so
      
      $ sudo vim /etc/login.defs
      SU_WHEEL_ONLY
 
 
  • 08/07
    WWW
    • ORZ 設定変更
      cache ファイルの整理に使われるリストファイルを生成しないようにした。
      NoMakeList=1

      しばらく様子見していると、今まで頭を悩ましていた原因不明の連続した 低速 read による Disk I/O が発生しなくなり、システム負荷が激減した。
      PersistentPerl 導入よりも効果が高く、LA が1/4にまで減少。
      古い低速の HD (ノーマル ATA等)を使っている場合に特に効果が高い。

      【注意点】
      1.設定後はキャッシュの整理が行われなくなるので、古くなったキャッシュを手動で削除する必要がある。
      2.キャッシュ管理をしなくなるので、キャッシュ領域が自動的に無限となる。ディスク使用量に注意すること。

      # cache cleaning for ORZ in crontab
      0 5 * * *  root /usr/bin/find /home/data/httpd/orz/cache -type f -mtime \+2 -exec rm -f {} \+
      0 5 * * *  root /usr/bin/find /home/data/httpd/orz/cache -type d -empty -exec rmdir {} \+

 
  • 08/01
    FW
    • ORZ監視&障害発生時切り替えスクリプト設置
      ORZ の耐障害性を高める為に設置。
      WWW に障害が発生した場合、FW で apache を立ち上げ、ORZ への要求を本家へリダイレクトしクラスタから切り離す。
      1. cron を使い、分間隔で監視
      2. orz.cgi から  302 含む最終的な"200 OK" 以外のレスポンスの場合に障害発生と判断
      3. apache を起動。orz 要求は本家へ。他の要求は google へリダイレクト。
      4. PF ルールの切り替え。WWW へ向けている dst port80 のパケットを自身に向ける。
      5. メールで通知。
      不安定な状態でのサービス再開を避ける為に、復旧(切り替え)作業は全て手動で行う。


    • ORZ パラメータ変更
      virtualhost 内で keepalive を off。一部パラメータ変更。
      <IfModule persistentperl_module>
        KeepAlive             Off
      
        PersistentGroup       ORZ
        PersistentMaxBackends 24
        PersistentMaxRuns     512
        PersistentTimeout     300
        AddHandler persistentperl-script .cgi
      </IfModule>
 
 
  • 07/28
    WWW
    • member用アップローダー設置
      Sn Uploader + CANDY CGI のレイアウトをちょっといじったもの
      CANDY CGI の仕様で DL/UP 後に白紙ページに飛ばされてしまう。
      暇見て改造したい。
 
  • 07/21
    www
    • 次期メールシステム移行準備
      システムの母体になる DB 作成と現データを DB に登録
    • apachetop インストール
      deb パッケージでインストール。依存関係にて portmap, famd も入った。
 
  • 07/14
    WWW
    • ORZ の PersistentPerl
      ORZ 負荷対策に PersistentPerl(旧SpeedyCGI)テスト導入。
      様子見しつつ本導入予定。
      また併せて apache の設定を下記に変更。
      MaxKeepAliveRequests 50
      KeepAliveTimeout     4
      RLimitCPU            300
      RLimitMEM            10485760
      RLimitNPROC          16
      MaxClients           100
      ServerLimit          100
      
      # Virtual ORZ
      <VirtualHost *:80>
        <IfModule persistentperl_module>
          PersistentGroup       ORZ
          PersistentMaxBackends 24
          PersistentMaxRuns     256
          PersistentTimeout     300
          AddHandler persistentperl-script .cgi
        </IfModule>
      
        <Directory /home/data/httpd/orz>
           Options ExecCGI Includes
        </Directory>
      </VirtualHost>

    • apache 起動スクリプト編集
      PersistentPerl 導入に併せ、apache の起動/停止時に PersistentPerl デーモンを停止する記述を追加。
      また通常指定と graceful 指定とを分け、通常指定時のみ PersistentPerl を止めるようにした。

    • 暴走 httpd ストップスクリプト
      PersistentPerl 導入後、時折原因不明の httpd プロセス暴走が起こるようになった。
      詳細:PersistentPerl のページ
      臨時対応策として cron で暴走状態にある httpd プロセスを kill するようにした。
 
  • 06/19
    WWW
    • curl リコンパイル
      apache のエラーログに出ていた curl エラー
      curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
      error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
      More details here: http://curl.haxx.se/docs/sslcerts.html

      rep2 が 2ch ID ログイン時に吐いていたのが判明。
      curl が ssl 接続する時に参照する認証局リストの設定がなされていなかった。
      http://curl.haxx.se/docs/sslcerts.html より、PEM フォーマットの最新リストを取得し、
      「--with-ca-bundle」オプション付きでリコンパイル。
      ファイルの場所を分かり易くする為に、/usr/local/etc/curl-ca-bundle.crt とした。
 
  • 06/10
    FW.月桜
    • memory 増設
      320MB (128 + 64*3) → 720MB (128 + 64 + 256*2) へ増設
      当初 WWW への増設予定だったが、MB が 512MB までしかサポートしてなかった。(涙目


  • 06/07
    WWW.月桜
    • swatch の deamon モードでのゾンビ化回避&ETCパッチ作成
      swatch を cron から呼び出した場合にゾンビ化する問題の原因が判明。
      fork してファイル監視プロセス化した後に、
      標準出力周りのファイルハンドルをクローズしていなかったのが原因であった。
      この修正+中間ファイルを任意のファイルとして保存できるオプションを付け加えた patch を作成した。
      SWATCH の patch はこちら→ SWATCH


  • 06/05
    WWW.月桜
    • pdflush の設定変更
      ORZ のデータ取得に伴う I/O wait 負荷高への対応を模索中
      vm.dirty_background_ratio = 10 (5 から変更)
      vm.dirty_ratio = 20 (10 から変更)
      vm.dirty_writeback_centisecs = 500
      vm.dirty_expire_centisecs = 3000

      IBM - Kernel 2.6のVM tunables より抜粋
      http://www-06.ibm.com/jp/domino01/mkt/cnpages7.nsf/page/default-002CC43F
      dirty_background_ratio
      ----------------------
      全メモリーに対するダーティページ(*)の割合がこのパーセンテージに達すると、
      pdflush デーモンが目覚めてページ解放の処理を開始します。
      デフォルトは10(%)です。
      
      *: メモリー上で内容が更新されたがまだディスクに書き込まれていないページ。
      フラッシュ(=ディスクへ書き込み)されると「クリーンページ」となり、
      インアクティブでクリーンなページはすぐに他の用途に再利用することができます。
      
      dirty_ratio
      -----------------
      全メモリーに対するダーティページの割合がこのパーセンテージに達すると、
      目覚めたpdflushが実際にダーティページの書き出し処理を開始します。
      この値を通常より低く設定することで、ある一時点でメモリー上に存在する
      ダーティページの量を少なく抑える事ができます。デフォルトは40(%)です。


  • 05/30
    WWW.月桜
    • AWStats パーミッション変更
      パーミッションが変になっていたのを修正

    • AWStats library の更新
      試験的に User-Agent を解析する library 郡を Ver6.7 のを使用してみる。

    • swatch script-file パッチ作成
      swatch が使う中間ファイルを任意の名前と保存場所を指定出来るパッチを作成。
      パッチを当てた swatch でテスト運用開始。


  • 05/29
    WWW.月桜
    • apache suexec 権限変更
      ログローテート時の自動リロードで突然下記 warning が出力され始めた。
      Warning: SuexecUserGroup directive requires SUEXEC wrapper.

      suexec に setuid bit が立ってないのが原因らしいが、
      何故に突然 warning を吐き出したが不明。
      # chmod 4755 apache/bin/suexec 
      # ls -l apache/bin/suexec
       -rwsr-xr-x 1 root staff 16K May 20 17:19 suexec*


  • apache orz のログフォーマット変更
    負荷が高い orz 処理時間の調査
    %D -> マイクロ秒(1/100万)
    %T -> 秒
    LogFormat     "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %T" response_time
    CustomLog     /var/log/apache/ORZ/access.log response_time

  • AWStats orz のログ解析フォーマット変更
    LogFormat = "%host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot %other %other"

  • AWStats の User-Agent orz データ追加


  • 05/28
    WWW.月桜
    • TCP バッファ周りの変更
      実際に使われる値は、セットした値の半分になるらしい。
      sysctl (1) で設定後、/etc/sysctl.conf に起動時の設定を追加。

      default -> 87380(42KB) から 262144 (128KB)
      max -> net.core.mem_max の値が小さかったので 2072576(2MB) に統一。
      # sysctl -a
      net.ipv4.tcp_mem =  48576  129536   194304
      net.ipv4.tcp_wmem =  4096  262144  2072576
      net.ipv4.tcp_rmem =  4096  262144  2072576
      net.core.wmem_max = 2072576
      net.core.rmem_max = 2072576
      net.core.wmem_default = 108544
      net.core.rmem_default = 108544

      ◎ Socket Buffer Tuning より抜粋
      http://www.anarg.jp/~t-tugawa/note/linux/sockbuf.html
      
      net.ipv4.tcp_rmem
         TCPが受信バッファサイズを調整するために用いられます.
         このsysctl変数は,[min,default,max]の3つの値を持ちます.
         それぞれの値の意味は,下記の通りです.
      
           * min ..... 各TCPソケットが用いる受信バッファの最小値です.
                       この値は,SO_RCVBUFを用いてソケットの 最低受信バッファサイズを宣言する際には用いられません.
           * default ..... TCPソケットの受信バッファのデフォルト値です.
                           この値は,net.core.rmem_defaultよりも優先されます.
           * max ..... 各TCPソケットが用いる受信バッファの最大値です.
                       この値よりもnet.core.rmem_maxが優先されます.
                       この値は,SO_RCVBUFを用いてソケットの受信バッファサイズを制限する際には用いられません.
      
      net.core.rmem_default
         net.ipv4.tcp_rmemのdefaultと同様です.ただし,設定値は,net.ipv4.tcp_rmemのdefaultの方が優先されます. 
      
      net.core.wmem_default
         net.ipv4.tcp_wmemのdefaultと同様です.ただし,設定値は,net.ipv4.tcp_wmemのdefaultの方が優先されます. 
      
      net.core.rmem_max
         net.ipv4.tcp_rmemのmaxと同様です.ただし,設定値はこちらの方が優先されます. 
      
      net.core.wmem_max
         net.ipv4.tcp_wmemのmaxと同様です.ただし,設定値はこちらの方が優先されます.


  • 05/27
    WWW.月桜
    • swatch 起動スクリプトの修正

    • swatch の単体リロードスクリプト作成

    • logrotate と swatch リロードスクリプトの相性問題対応
      logrotate から呼び出される swatch のスクリプトが正常に処理されていないらしく、
      上記2つと cron プロセスがゾンビ化してしまう。
      原因調査中。

    • HD パラメータ変更 readahead 256 から 512 へ
      hdparm -t のテスト数値ではほぼ差は無いが、体感で読み込み速度(反応)が上昇している。
      # hdparm -a 512 /dev/hda
      /dev/hda:
       multcount    = 16 (on)
       IO_support   =  0 (default 16-bit)
       unmaskirq    =  0 (off)
       using_dma    =  1 (on)
       keepsettings =  0 (off)
       readonly     =  0 (off)
       readahead    = 512 (on)
       geometry     = 16383/255/63, sectors = 241254720, start = 0 


  • 05/24
    FW.月桜
    • procfs の使用
      FreeBSD で procfs はデフォルトでは使われないので手動で mount し、/etc/fstab に記述。
      # mount -t procfs /proc
      # cat /etc/fstab
      # Device                Mountpoint      FStype  Options         Dump    Pass#
      /dev/ad1s1b             none            swap    sw              0       0
      /dev/ad0s1a             /               ufs     rw              1       1
      /dev/ad0s1e             /home           ufs     rw              2       2
      /dev/ad0s1d             /usr            ufs     rw              2       2
      /dev/ad1s1d             /var            ufs     rw              2       2
      proc                    /proc           proc    rw              0       0

WWW.月桜

  • bind クエリーログの停止
    現状意味が薄く、disk の I/O wait を減らす為に停止。

  • SWATCH でログ監視監視
    監視対象: named, auth, mail, ftp, apache, orz, syslog

    SWATCH は reload や複数のログ監視、ログローテートに対応していないので、
    独自の startup/stop script を作成し、ログのローテートにも各々対応させた。
    ・起動スクリプト
    設定ファイルの数だけ SWATCH を起動。各設定ファイルに関連付けられたログファイルを監視。
    設定ファイルと監視対象ログとの関連付けは、設定ファイルと同名のログファイル本体へのシンボリックリンクで実現。

    ・ログのローテート対応 /etc/cron.daiary/sysklog と logrotate.d 以下の設定ファイルに、
    ローテート後に対象の SWATCH を再起動するスクリプトを記述。
    SWATCH が生成した PID ファイルから PID を取得し、/proc 以下から取得したプロセス情報を使用して再起動を行う。


  • 05/23
    WWW.月桜
    • iptables ルール設定スクリプト version up
      複数の port にまたがった正常アクセスが、port 毎に別々に判定ではなく、
      一塊のアクセスと見なされ drop されてしまう状態に対応。
      初めの意図通り、port 別に brute force attack を判定させるようにした。

    • hdparm の設定変更
      2ch サーバダウンに伴う orz.cgi の負荷上昇により /home 領域の file system に異常が発生。
      ここ数日 iowait 値が高かった事に加え、
      以前行った hdparm 周りの設定が今回の障害を引き起こした可能性もある。
      unmaskirq = on (ディスク割り込み処理中に他の割り込みのマスクを (ドライバーが)外すことを許可する)
      write_cache = on
      にしてた辺りが怪しいと推測。
      この為、hdparm の設定を以下のように単純なものにし、様子を見る。
      # hdparm /dev/hda
      
      /dev/hda:
       multcount    = 16 (on)
       IO_support   =  0 (default 16-bit)
       unmaskirq    =  0 (off)
       using_dma    =  1 (on)
       keepsettings =  0 (off)
       readonly     =  0 (off)
       readahead    = 256 (on)
       geometry     = 16383/255/63, sectors = 241254720, start = 0
      
      # cat /etc/hdparm
      /dev/hda {
        mult_sect_io = 16
        dma = on
        write_cache = off
      }

      May 22 23:34:30 ns kernel: Filesystem "hda7": XFS internal error xfs_trans_cancel
                                 at line 1163 of file fs/xfs/xfs_trans.c.  Caller 0xc01e6e02
      May 22 23:34:30 ns kernel: Pid: 20695, comm: orz.cgi Not tainted 2.6.25 #1
      May 22 23:34:30 ns kernel:  [<c01e12c9>] xfs_trans_cancel+0x4d/0xd2
      May 22 23:34:30 ns kernel:  [<c01e6e02>] xfs_create+0x382/0x3f5
      May 22 23:34:30 ns kernel:  [<c01e6e02>] xfs_create+0x382/0x3f5
      May 22 23:34:30 ns kernel:  [<c01ef903>] xfs_vn_mknod+0x140/0x22b
      May 22 23:34:30 ns kernel:  [<c0154dfd>] vfs_create+0x9b/0xdb
      May 22 23:34:30 ns kernel:  [<c0157017>] open_namei+0x15d/0x50a
      May 22 23:34:30 ns kernel:  [<c014da28>] do_filp_open+0x1c/0x31
      May 22 23:34:30 ns kernel:  [<c014da7d>] do_sys_open+0x40/0xb5
      May 22 23:34:30 ns kernel:  [<c014db36>] sys_open+0x1e/0x23
      May 22 23:34:30 ns kernel:  [<c0104516>] sysenter_past_esp+0x5f/0x85
      May 22 23:34:30 ns kernel:  [<c02f0000>] xfrm_state_alloc+0x3b/0x10f
      May 22 23:34:30 ns kernel:  =======================
      May 22 23:34:30 ns kernel: xfs_force_shutdown(hda7,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. 
                                 Return address = 0xc01e12df
      May 22 23:34:30 ns kernel: Filesystem "hda7": Corruption of in-memory data detected.
                                 Shutting down filesystem: hda7
      May 22 23:34:30 ns kernel: Please umount the filesystem, and rectify the problem(s)


  • 05/21
    FW.月桜
    • net-snmp アップデート
      下記バグに手動 patch を当て、アップデート
      patch の詳細はこちら->Net-SNMP#e1e1aa6d
      >BUG 1 (from snmpd.log)
      snmpd[38190]: netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
      
      >BUG 2 (from snmpd.log)
      snmpd[1239]: auto_nlist failed on cp_time at location 1
      snmpd[1239]: kvm_read(*, 1, 0xbfbfe88c, 20) = -1: kvm_read: Bad address


WWW.月桜

  • httpd, bind 起動スクリプトの bug fix
  • iptables ルール設定スクリプト version up
    「iptables の ipt_recent で ssh の brute force attack 対策」
    http://www2s.biglobe.ne.jp/~nuts/labo/inti/ipt_recent.html
    を参考に、Limit 機能を追加。
    現在の機能→ 特定の port への通信を日本国内のみに限定し、さらに brute force attack を防ぐ


  • 05/20
    • apche 設定変更
      mpm を worker から prefork に変更。
      fastcgi 系を念頭に。

    • tmpfs 容量変更
      使われている形跡が無い為 32mb から 16mb へ変更
      # cat /etc/default/tmpfs
      SHM_SIZE=16m
      RW_SIZE=16m

    • 外部監視サービス利用開始
  • 05/19
    WWW.月桜
    • ハードディスクの転送モード変更
      オリジナルカーネルにした際に IDE device draiver をモジュールにしてしまった為、
      DMA 転送モードになっていなかった。
      IDE device draiver を静的に組み込み、カーネルを再構築。
      下記コマンド実行後、/etc/hdparm.conf に起動時の設定を追加。
      # hdparm -A1 -W1 -c3 -d1 -m16 -u1 /dev/hda
      
      /dev/hda:
       multcount    = 16 (on)
       IO_support   =  3 (32-bit w/sync)
       unmaskirq    =  1 (on)
       using_dma    =  1 (on)
       keepsettings =  0 (off)
       readonly     =  0 (off)
      
      # cat /etc/hdparm.conf
      /dev/hda {
        lookahead = on
        write_cache = on
        mult_sect_io = 16
        write_cache = off
        io32_support = 3
        dma = on
        interrupt_unmask = on
      }
      
      /dev/hdb {
        lookahead = on
        write_cache = on
        mult_sect_io = 16
        write_cache = off
        io32_support = 3
        dma = on
        interrupt_unmask = on
        spindown_time = 60
      }

    • samba バックアップ用ハードディスクを通常 stanby 状態へ移行
      上記 HD が常に active 状態であったので、stanby とさせた。
      Linux では、現在まだ sleep 状態(HD 電源停止)から確実に復帰させる手段が無いらしい。
      hdparm -Y /dev/hdb として sleep > mount を繰り返していたら OS がフリーズしてしまった。
      非常に危険なので sleep 状態にさせないこと。
      # hdparm -C /dev/hda
       /dev/hda:
       drive state is:  active/idle
      
      # hdparm -S60 /dev/hdb
      # hdparm -C /dev/hdb
       /dev/hdb:
       drive state is:  standby



  • 05/01-08

    FW.月桜
    • FreeBSD7.0 stable へ update
    • PF rule をポリシーベースへ変更
    • HTTP AntiVirus? Gateway 開始 (Squid + Harv)

www.月桜

  • Debian Eath へ update
  • 各プログラムアップデート
  • ORZ 再開
  • アリスソフト フリーアーカイブ配信開始
    BitTorrent? (Azureus) 導入→www.月桜から外部宛ての packet は全てパスに変更
  • 以下のサービスを日本国内からのみに限定
    FTP, SSH, SMTP, POP3, POP3S, IMAP, IMAPS
  • Cacti へ squid の監視を追加

トップ   編集 凍結解除 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2009-05-28 (木) 22:43:39 (3739d)