カテゴリー別アーカイブ: OS依存

NFSはアンダースコアのあるexportsをマウントできない?

こんにちは、岡田洋一です。

最近は引き続いてファイルサーバの移行を行っています。
さてそのファイルサーバではNFSを提供しています。
ローカル環境の各ホストに対して同じホームディレクトリを提供してくれる非常に心強い存在です。
NFSも少し前にバージョンが3から4になり、パフォーマンスの向上やUID、GIDを揃えるidmapdとの連携など便利になったりしました。

さてそんなNFSなのですが、今回新サーバに移行するにあたってうまくマウントできない症状が起きました。

shell> sudo mount nfs.l2tp.org:/path_service /mnt/path_service
mount.nfs: Connection timed out

なにやらエラーが起きてますね。
NFSではexportsというファイルに設定を書いて色んなディレクトリを他のホストからマウントすることができるのですが、うまくいきません。
実はこれ、他のディレクトリではうまくいっていたんですね。でもこのディレクトリだけうまくいきません。

今回設定したのは下記の通りです。サーバクライアントともにUbuntu 14.04LTSです。

NFSサーバにて、fstabでbindマウントを行う
shell> grep service /etc/fstab
/pool/path_service       /exports/path_service  none    bind              0    0

次にexportsに記載
shell> /exports/path_service 192.168.1.0/24(async,nohide,no_subtree_check,no_root_sq
uash,rw)

最後に関連サービスの再起動などなど
shell> sudo mount -a
shell> sudo service nfs-kernel-server restart
shell> sudo exportfs -ra


クライアント側にてマウントさせる
shell> sudo mount nfs.l2tp.org:/path_service /mnt/path_service
mount.nfs: Connection timed out

うまくいかないです。

もう一度言いますが他のディレクトリはうまくマウントできているのです。このディレクトリがダメなのですね。
うまくいっている所と見比べてみると、ディレクトリ名にアンダーバー、アンダースコアがあることが考えられます。

この後実際にアンダーバーを省いたものでマウントさせてみると… ちゃんと動きました!

NFSはアンダーバーを含むファイル名をマウントする事ができないのでしょうか?

少しググってはみたのですがそれらしき記述は見当たらなくて、これまでも聞いたことが無くて…うーん。

もしどなたかご存じの方がいらっしゃった場合には教えてください!

追記:
ちなみにクライアント側でマウント先ディレクトリにアンダーバーがある場合には大丈夫でした。

shell> sudo mount nfs.l2tp.org:/pathservice /mnt/path_service

この場合には通るのでexportsでアンダーバーを許可していない、とかなのでしょうか。
またexportsにアンダースコア含みでディレクトリを記載してもマウント時にアンダースコア無しでマウントできてしまいました。
アンダーバーは無視されるのかな?

NFSでマウントしているホスト一覧を取得

こんにちは。

秋口もずいぶんと涼しくなってきて肌寒いぐらいになってきました。

さて現在、うちではファイルサーバの移行を行っています。
今までFreeNASを使ってきたのですがそろそろNFSv4とかも欲しいのでUbuntuへ移行することになりました。

NFSサーバの構築も終わり一通りファイルもコピーし終わりましたが、次の重要な作業が待っています。

各ホストではfstabを使って旧サーバをマウントしていますが、これを新サーバに書き換える必要があります。

ホストにログインしてfstabを書き換える…、この作業も重要ですが、何より既にマウントして使っているホスト一覧を調べ上げるということが重要です。
どのホストが利用しているかを把握できないと移行がうまくいっているかという確認すらできず、気がついたらサービスが停止していました,ということになりかねませんからね。

NFSでマウントさせているおおよその台数は20台ぐらいです。
なのでつい漏らしてしまうことがあるんですね。

こういうときにはNFSサーバ側でshowmount -aを使うとその一覧を取得することができます。

shell> showmount -a
All mount points on localhost:
192.168.1.36:/path/to/home
192.168.1.37:/path/to/home
192.168.1.45:/path/to/home

簡単ですね!

RAIDで作成したmdをフォーマットしてマウントするまで

こんにちは。

先日ubuntuでraidを構築したんですが、まだマウントもしていなかったのでマウントしてみます。

まずいきなり問題が発生です。
前回raidを作成するときにmd0というデバイス名で作っていたんですが、その後の何度かの再起動で番号が変わってしまったようです。

shell> ls /dev/md*
/dev/md127

/dev/md:
bush:0

よくはわからないですがmd127というデバイスがあります。これがどうやら先日つくったraidのようです。念のためmdadmコマンドで確認しておきます。

sudo mdadm -D /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Fri Sep 26 09:19:13 2014
     Raid Level : raid5
     Array Size : 14650675200 (13971.97 GiB 15002.29 GB)
  Used Dev Size : 2930135040 (2794.39 GiB 3000.46 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Fri Oct  3 15:14:31 2014
          State : clean
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : bush:0  (local to host bush)
           UUID : c3db0680:1c5c7986:c90a298a:96a9efb0
         Events : 99

    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       8       16        1      active sync   /dev/sdb
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd
       4       8       64        4      active sync   /dev/sde
       6       8       80        5      active sync   /dev/sdf

ちなみに-Dは–detailと同じ意味らしいです。
ちゃんと/dev/sd{a,b,c,d,e,f}で構成されているraidのようですね。
なぜ番号が変わったかは…わかりません!なぜなのでしょうか。

と思ったら参考にしたサイトに「md*の番号は変わる」との記載がありました。なるほど!為になります。

さてこのmdをXFSでフォーマットしてマウントしていきます。
とはいってもmkfsでファイルテーブル(?)を書き込んでやるだけです。

shell> mkfs.xfs -f /dev/md127
meta-data=/dev/md127             isize=256    agcount=32, agsize=114458496 blks
         =                       sectsz=4096  attr=2, projid32bit=0
data     =                       bsize=4096   blocks=3662668800, imaxpct=5
         =                       sunit=128    swidth=640 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

これで完了です。
試しにマウントしてみます。

shell> sudo mkdir -p /mnt/hoge
shell> sudo mount -t xfs /dev/md127 /mnt/hoge

バッチリですね!

最後に自動マウントをさせてみたいと思います。どうやらmd*の番号の部分が変わってしまうらしくUUIDでマウントさせるといいらしいです。

UUIDの確認はtune2fsというコマンドでできるらしいのですが、このコマンドはファイルシステムがext2/3/4じゃないとだめらしいです。
今回のファイルシステムはxfsを使っていたので他の手段になります。

ググってみるとblkidというコマンドでできるようです。これで出力されるUUIDをマウントさせます。

shell> sudo umount /mnt/hoge
shell> blkid /dev/md127
/dev/md127: UUID="f8a0fa74-9e9d-48b2-a497-e593a6444572" TYPE="xfs"
shell> sudo vi /etc/fstab
...省略...
UUID=f8a0fa74-9e9d-48b2-a497-e593a6444572  /mnt/hoge      xfs     noatime 0           0
shell> sudo mount -a
shell> mount -v
...省略...
/dev/md127 on /mnt/hoge type xfs (rw,noatime)

バッチリですね!

今回参考にしたサイトです。
[Linux] 外付けUSBハードディスクをまるごとxfsでフォーマットする方法 – SumiTomohikoの日記

mdadmを使ったRAIDの構築 – 前人未踏の領域へ

raid – Ubuntu Server 12.04, MDADM device number suddenly changes? – Ask Ubuntu

[email protected] 14.04 LTS

少し流行は過ぎてしまったのですが、UbuntuのnginxでWordPressを動かしたのでメモ。

1. 構成
まずは構成について。
ウェブサーバの構成について、単にnginxを使うとしてもいろいろな構成があるんだけれど、今回はリバースプロキシを使った構成にしました。

リバースプロキシはユーザからのリクエストを受ける際、いったんプロキシサーバがリクエストを受け取って、それを本当のウェブサーバに問い合わせを行う、というそんな機能を提供してくれます。
プロキシ(代理)サーバなので、リクエストを途中から代理してくれる、そんなサーバです。
リバースと付いているのは、リバースじゃ無い普通のプロキシサーバもありまして、こちらはクライアント側で利用します。リバースプロキシはリバース、逆向きなので、サーバ側において代理させるんですね。
ちなみにリバースプロキシサーバ、プロキシサーバともにキャッシュ機能が付いている物がほとんどです。

で、今回の構成では、インターネット側からのリクエストをnginxのリバースプロキシで受けて、それを内部のnginxへリクエスト、そのnginxはWordPressに必要なPHPをPHP-FPMというものを使って動作する、ということに。
このリバースプロキシを使うことでキャッシングが容易にできるのでWordPressの高速化が進む、というものですね。

ちなみにPHP-FPMはプロセスで待ち受けさせていて、リクエストがあるとすぐにPHPを実行して結果を返すという、そういう仕組みをもったPHPのサーバ、デーモンです。

一台のサーバで”リバースプロキシ”、”ウェブサーバ”、”PHPサーバ(アプリケーションサーバ)”を動かす必要があるので、そのやりとりにはいくつかのルールが必要です。
サーバへリクエストを投げるときには必ず、どのサービスへ繋ぐか、という情報が必要なのですが、これを通常ポート番号によって振り分けるのです。
ちなみに一般的なウェブサービスだと80番を利用します。またプロキシサーバでは8080版を利用します。

今回はリバースプロキシですのでこいつが80番で待ち受けて、このリバースプロキシからウェブサーバへはウェブサーバの8080番ポートへ接続、PHPが動いているデーモンへはポート番号じゃなくてsockという仕組みで繋ぐことにしました。

2. 手順
まずはインストール。ubuntuなのでaptを利用します。今回必要になるのはnginx, php-fpmです。

shell> sudo apt-install nginx php-fpm
shell> cd /etc/nginx

インストールが終わったらnginxのデフォルトコンフィグが格納されている/etc/nginxで作業します。

まずは早速、WordPressに必要なnginxのconfigを二つ書きます。
これはWordPressの公式サイトで紹介されています。二つのconfを/etc/nginx/siteconf.d/というディレクトリを作って配置しています。

more /etc/nginx/siteconf.d/global_restrictions.conf       
# this file is from http://codex.wordpress.org/Nginx                            # Global restrictions configuration file.                                       
# Designed to be included in any server {} block.</p>                           
location = /favicon.ico {                                                       
         log_not_found off;                                                     
         access_log off;
}

location = /robots.txt {
         allow all;
         log_not_found off;
         access_log off;
}

# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Sto
re (Mac).
# Keep logging the requests to parse later (or to pass to firewall utilities suc
h as fail2ban)
location ~ /\. {
         deny all;
}






shell> cat /etc/nginx/siteconf.d/wordpress_base
# this file is from http://codex.wordpress.org/Nginx

# WordPress single blog rules.
# Designed to be included in any server {} block.

# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
         try_files $uri $uri/ /index.php?$args;
}

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
       access_log off; log_not_found off; expires max;
}

# Uncomment one of the lines below for the appropriate caching plugin (if used).
#include global/wordpress-wp-super-cache.conf;
#include global/wordpress-w3-total-cache.conf;

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ \.php$ {
         # Zero-day exploit defense.
         # http://forum.nginx.org/read.php?2,88845,page=3
         # Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
         # Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  And then cross your fingers that you won't get hacked.
         try_files $uri =404;

         fastcgi_split_path_info ^(.+\.php)(/.+)$;
         #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

         include fastcgi_params;
         fastcgi_index index.php;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         fastcgi_param REMOTE_ADDR  $http_x_real_ip;
#        fastcgi_intercept_errors on;
         fastcgi_pass unix:/var/run/php5-fpm.sock;
}

最初のglobal_restrictions.confでは不正なアクセスを防ぐための設定です。nginxでは.htaccessを初めとしたファイルを利用しませんので、それらのファイルが標準では直接表示されたりします。中にはパスワードを書いてあったりすることもあるので安全のためこれらのファイルを非表示にするconfです。

続いてwordpress_base.confです。これがnginxとphp-fpmでwordpressを動かすための基本的なconfigになります。ほとんどは公式通りなのですが、注意点がいくつかあります。
conf本体の下部にある、 “fastcgi_param REMOTE_ADDR $http_x_real_ip;”については追記してあります。
これは今回リバースプロキシを使うに当たって、ウェブサーバで見えるクライアントIPアドレスが127.0.0.1のような自分自身のアドレスになってしまうことを防ぐ処置です。
自分自身をリバースプロキシにする場合に限らず何らかのリバースプロキシを挟むとREMOTE_ADDRが書き換わってしまいます。そうするとアクセス解析やコメントをつけた人のIPアドレスがすべて同じものになってしまい意味のないものになってしまいます。
それを防ぐための構文になります。ちなみにapacheであればmod_rpafというモジュールで対処したりします。
もう一点気をつける構文は”fastcgi_pass unix:/var/run/php5-fpm.sock;”です。今回はPHPとnginxを動かすサーバが同じサーバでしたのでsockを利用しました。他のホストで動かす場合やTCP/IPで動かす場合には変更が必要です。

これでwordppressの基本的なconfは揃いました。続いてはサイトのconfを書きます。

最近はnginxもapache同様、ドメインごとにconfigを書いてシンボリックリンクで有効化/無効化する流れになっています。今回は /etc/nginx/sites-available/example.com で作成しました。
このconfにはリバースプロキシ用の設定も含まれるので少し大変です。

shell> cat /etc/nginx/sites-available/exampel.com.conf
server {
        listen 80;
        server_name www.example.com;
        root        /home/yousan/public_html/www.example.com;
        index index.html index.htm index.php;
        include siteconf.d/global_restrictions.conf;

# ここから下がリバースプロキシ用の設定 最後にドメインの名前を設定すること
# またnginx.confのbackednともセットで設定すること
              location /wp-admin { proxy_pass http://backend; }
              location ~ .*\.php { proxy_pass http://backend; }
        location / {
              set $mobile "";
              if ($http_user_agent ~* '(DoCoMo|J-PHONE|Vodafone|MOT-|UP\.Browser|DDI
POCKET|ASTEL|PDXGW|Palmscape|Xiino|sharp pda browser|Windows CE|L-mode|WILLCOM|SoftB
ank|Semulator|Vemulator|J-EMULATOR|emobile|mixi-mobile-converter)') {
              set $mobile "@ktai";
              }
              if ($http_user_agent ~* '(iPhone|iPod|Opera Mini|Android.*Mobile|NetFr
ont|PSP|BlackBerry)') {
              set $mobile "@mobile";
              }
              if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-post
pass_" ) {
              set $do_not_cache 1;
              }
              proxy_no_cache     $do_not_cache;
              proxy_cache_bypass $do_not_cache;
              proxy_cache czone;
              proxy_cache_key "$scheme://$host$request_uri$is_args$args$mobile";
              proxy_cache_valid  200 301 302 60m;
              proxy_cache_valid  404 5m;
              proxy_cache_use_stale  error timeout invalid_header updating http_500
http_502 http_503 http_504;
              proxy_pass http://backend;
              proxy_redirect http://www.example.com:8080/ /;
       }
}

server {
    listen      8080;
    server_name www.example.com;
    index index.html index.htm index.php;
    include siteconf.d/global_restrictions.conf;
    include siteconf.d/wordpress_base.conf;
    root            /home/yousan/public_html/www.examplecom.com;
}

shell> sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled

このconfでは上のserverディレクティブで80番の待ち受け、リバースプロキシ側の待ち受けを設定します。この中で最後の方にあるproxy_redirectという構文で実際にPHP等が動いている8080で待ち受けをしているウェブサーバへ転送しています。
下の8080で待ち受けをしているところは先ほどwordpress用のconfを書きましたのでそれらをincludeして、あとは少し書いてやるだけでOKです。

ドメインごとのconfを書いたらlnでシンボリックリンクをsites-availableへ移してあげてください。こうすることで有効化されます。

最後にnginx本体のconfを書きます。
今回はリバースプロキシでレスポンスを早くしよう!というが目的ですのでリバースプロキシのキャッシュとgzip圧縮を有効化します。
ココでもリバースプロキシ用の設定を分けてあります。
機能別に分けられたconfはconf.dに入れると自動で読み込まれますのでそちらに入れておきます。自動に読まれますけれど*.confという名前じゃないとダメなので注意してください。

shell> cat /etc/nginx/conf.d/
proxy_cache_path  /var/cache/nginx levels=1:2 keys_zone=czone:4m max_size=50m inacti
ve=120m;
proxy_temp_path   /var/tmp/nginx;
proxy_cache_key   "$scheme://$host$request_uri";
proxy_set_header  Host               $host;
proxy_set_header  X-Real-IP          $remote_addr;
proxy_set_header  X-Forwarded-Host   $host;
proxy_set_header  X-Forwarded-Server $host;
proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;
proxy_set_header  Remote-Addr        $remote_addr;
#real_ip_header X-Forwarded-For;
#real_ip_recursive on;

upstream backend {
             ip_hash;
             server 127.0.0.1:8080;
}

こちらが本体側のconfです。ほとんど書き換えてないのでコメントを外すだけですね。

shell> cat /etc/nginx/nginx.conf
... 省略 ...
       ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 6;
        gzip_buffers 16 8k;
        gzip_http_version 1.1;
        gzip_types text/plain text/css application/json application/x-javascript tex
t/xml application/xml application/xml+rss text/javascript;

これでconfが整いました。
最後にnginxを再起動して動作確認です。

shell> sudo service nginx restart

さて、動いたでしょうか。

今回自分もすぐには動かず、いくつかはまった点がありましたので紹介しておきます。
1. 文末のセミコロン忘れ
2. www.example.comというドメインのまま、ドメイン名を書き換え忘れていた
nginxではほとんどの文末にセミコロンをつける習慣がありますので、これを忘れるとエラーになります。
ドメイン名の書き換えでは色んなサイトを参考にしながらconfを書いたのですが、confの途中にドメイン名がでていて、今回実際に運用するドメインに書き換えるのを忘れていて動きませんでした。

これらのエラーについてはerror.logを見る事でどのファイルのどこでエラーが起きている、ということが分かったりします。

shell> sudo tail /var/log/nginx/error.log

ただ中には直接的にエラーが表示されず、推測に推測を重ねてエラーを取り除く必要もありますがそちらについては…、経験が物をいいますね!

以上となります。

Ubuntu 14.04 LTS でRAID5を構成してみた

宅内のNASがそろそろ一杯になりそうなので半年前程から構想していたファイルサーバの新設に着手した。

構成としては3TB*6なHDDでUbuntu 14.04で動かす。
サービスとしてはNFSを中心にSamba、FTPなどのファイル関係のサービスを立てる予定。

ちなみにOSの選定はFreeNASと迷ったんだけれどFreeNAS(というかFreeBSD)がなかなかNFSv4を取り入れてくれないことと、湯バード先生からの「Ubuntuでやれば簡単だよそんなん」という強い後押しをもらって助けてもらいながら着手。

 

というわけでまずはベースとなるRAIDの構成。

一応ファイルサーバなので冗長化構成にしようとおもっていて、3TB*6をRAID5かRAID6かに。もともと2TBをFreeNAS 0.7系のRAIDZで運用している。で、今回の新設&リプレイスでも冗長化をしたいなぁ、と。ちなみに前回のファイルサーバでは幸いな事に障害は発生せぬまま終わりそう。

で、いままであまり気にせずにRAIDとかやってたんだけれど、6台だと容量の効率とか耐障害性とか色々あるなぁということで、RAIDについて調べてみた。

下記のサイトが非常にわかりやすくまとめてくれていた。


HDD6台でRAID5構成
(0.03^6)+(0.03^5*0.97*6)+(0.03^4*0.97^2*15)+(0.03^3*0.97^3*20)+(0.03^2*0.97^4*15)=0.01245587
→障害確率1.25%(3台構成の時の5倍!)
※HDD有効利用率は83%

HDD6台でRAID6構成
 (0.03^6)+(0.03^5*0.97*6)+(0.03^4*0.97^2*15)+(0.03^3*0.97^3*20)=0.000504418
 →障害確率0.05%
 ※HDD有効利用率は67%

RAID構成のHDDの障害発生率一覧 | Asterisk Staff Blog

 

なるほど、RAID6(HDD二台を冗長化用)とすると障害発生率がかなりひくくなる、ということらしい。

でも3TB*6でも12TBしか容量を使うことができず、容量の実効効率が…、ということでRAID5を選択。

 

さてではRAIDの種類も決まったことで早速RAID5の構築へ。

下記のサイトを参考にしながら取り組みました。

Ubuntu mdadm その54 – RAID 6アレイを作成する基本的なコマンドの例・作成したアレイの確認と利用 – Ubuntu kledgeb

今回の構成ではUSBメモリにOSを入れてある。HDD等の構成は以下の通り

HDD1 /dev/sda
HDD2 /dev/sdb
HDD3 /dev/sdc
HDD4 /dev/sdd
HDD5 /dev/sde
HDD6 /dev/sdf

USBメモリ(ブートディスク) /dev/sda

この中でHDD1〜6をRAID5にする。


shell> sudo mdadm --create /dev/md0 --level=raid5 --raid-devices=6 --chunk=512 --verbose /dev/sd{a,b,c,d,e,f}

これでraidが構成される。確認は/proc/mdstatを見る


cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdf[6] sde[4] sdd[3] sdc[2] sdb[1] sda[0]
14650675200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/5] [UUUUU_]
[==========>..........] recovery = 54.5% (1598589964/2930135040) finish=219.0min speed=101293K/sec

unused devices: <none>

この状態でRAIDの同期中なのであとは同期完了まで待てばOK!

mkvをmp4に変換するバッチスクリプト

mkv2mp4_flac1

よく使う割には手順が多くて面倒なのでバッチを作った。

h.264 + FLACなmkvファイルをmp4に変換する。
中身のFLACファイルはmp4には入らないので、AACに変換。
可変フレームレート対応。

使い方など
mkv2mp4_flac1 -v 0 -a 1 file.mkv [file2.mkv] [file3.mkv] …
事前に、ファイルのトラック番号をffmpegなどで調べる。
-v < ビデオトラックID> -a < オーディオトラックID>
ファイルは指定しただけ処理される。

続きを読む mkvをmp4に変換するバッチスクリプト

zfsのプールを他のサーバに効率よく移設する

zfsのプールを他のサーバに効率よく移設してみた。

現在zfsで構築されているファイルサーバから、新規に作成されたzfsのファイルサーバへzpoolを転送してみた。

 

流れとしては元サーバでsnapshotを取り、その後にsshで転送して受け側で展開するというもの。


zfs snapshot tank/pool@`date +%Y%m%d`;

zfs send tank/pool@`date +%Y%m%d` | ssh -c arcfour256 [email protected]_to_transfer zfs recv tank/pool@`date +%Y%m%d`


気をつけるのはdateを使って転送しているのでスナップショット作成から転送開始までに日をまたぐと失敗する。(スナップショットの作成はだいたい早いので大丈夫なハズ…)

またsshは-cで軽い暗号化方式を選ぶことで転送速度が上がるらしい。

ちなみに今回のテストでは標準のもの(aes128-cbc)だと8.1MB/sでしたが、arcfour256では でした。

 

一瞬でのバックアップを実現するSolaris ZFS (3/4)

http://www.atmarkit.co.jp/ait/articles/0804/08/news138_3.html

大容量ファイルのSCP転送を高速にする方法

http://d.hatena.ne.jp/rx7/20101025/p1

 

UNIX/Linux環境でFTPを再帰的に拾ってくる方法

こんにちは、岡田洋一です。

UNIX/Linux環境でFTPのディレクトリをまるごと取りたかったんです。が、ftpコマンドだとディレクトリを取ろうとしてもダメなんですね。

get somedirectoryってやるとNot a regular fileって怒られます。


shell> ftp ftp.example.com
Connected to ftp.example.com.
220 ::ffff:192.0.2.1 FTP server ready
Name (ftp.example.com:user): user
331 Password required for user
Password:
230 User user logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get tmp
local: tmp remote: tmp
550 tmp: Not a regular file

ディレクトリを再帰的に取りたい、っていう場合にはwgetを使うと良いようです。


shell> wget -r ftp://user:[email protected]//path_to_get/

多くの環境でインストールされているwgetで、ワンライナーで取得できるのはいいですね。

参考:  How do you recursively ftp a folder in linux

Debian/Ubuntuのコードネームを確認する方法

梅雨が明けたとか明けないのかよく分からない天気が続きますね。僕のダイエットもいつ明けるのか全く不明です。

岡田洋一ですこんにちは。

さて最近はDebian/Ubuntuをよく利用しています。以前はUnix/Linuxと言えばFreeBSD一択だったのですが、どうにも世の流れはLinuxということでお手軽なLinuxに移行しつつあります。日本ではCentOSが根強い人気を持っていますが海外の情報が少なく、また自信の周りの友人がDebian/Ubuntu派だったためDebian/Ubuntuを利用しています。

さてそんなDebian/Ubuntuですがこれらにはコードネームがついているんですね。5.0 -> 6.0といった具合にメジャーバージョンが変わったときには必ずこのコードネームが変わります。

このコードネームですが利用する上で知っておくことが必要になることがあります。パッケージ化されているソフトウェアはOSのバージョンによって違ってきますのでコードネーム名がついて配布されていたりします。またパッケージ管理ツールのaptもコードネームベースになっています。

そんなコードネームは /etc/os-release を見ることで確認できます。

shell> cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"

VERSION_ID="7"
VERSION="7 (wheezy)"
ID=debian
ANSI_COLOR="1;31"
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support/"
BUG_REPORT_URL="http://bugs.debian.org/"

ところでDebianのコードネームはトイストーリーのキャラの名前なんですね。知らなかったです。

Debianのコードネーム一覧
Debian GNU/Linuxのバージョンと名前(コードネーム)|星屋工作室 hoshiya.biz

またLinuxのディストリビューション名を確認するときには /etc/issues を参考にすると良いです。


shell> cat /etc/issue
Debian GNU/Linux 7 \n \l

unameで確認できない時にこちらの方法で確認できたりします。

NIS, LDAPを用いた複数の環境でログインシェルを変更する

NIS, LDAPを用いた複数の環境でログインシェルを変更したかった。

現在自分の環境ではLDAPを利用している。ログイン情報をLDAPサーバに集約できるので非常に便利。LDAPではログイン時にユーザ名、パスワード(ハッシュ)などの情報を各ホストに提供するのだけれど、その中にはログインシェルも含まれる。

ログインシェルといえばUNIX系でよく使われるcsh, tcsh、Linux系でよく使われるbash、また高機能シェルとして名高いksh, zshなどがある。自分はzshをメインのシェルとしているのだけれど、LDAPのログインシェルの情報をzshに変更するだけでは問題がある。

まず一つ目はフルパス表記での問題だ。
ログインシェルは通常フルパスで表記される。これはシェルの初回立ち上げ時に~/.cshrc, ~/zshrcといった環境ファイルを読み込ませ、その段階でパスがセットされるからだ。つまりログインシェルの情報を取得して起動させる段階ではパスが通っていないことが想定される。そしてこのフルパス表記がOS毎に違ってくる可能性がある、ということが問題の核だ。
このシェルの実体、バイナリの実体が配置される場所は大まかに以下のようになる。Linux系ではrpm, yum, aptなどのパッケージ管理ツールでインストールした場合の/usr/bin/、デフォルトで配置される/bin/、ソースからインストールされた/usr/local/binである。
対してFreeBSDの場合、tcshやcsh, shなどの元々インストールされているバイナリは/bin/sh, /bin/tcshなどに配置されるが、後から手動でインストールされたバイナリは/usr/local/binに配置される。zshやbash(FreeBSDではbashがデフォルトで入ってこない)は/usr/local/binに置かれている訳だ。
この問題に関して言えば、インストール時にバイナリの配置場所を/usr/bin, /bin, /usr/local/binのいずれかに統一してしまう、若しくはシンボリックリンクを統一された場所に配置する、という解決方法が考えられる。でもこれらの作業をそれぞれのホストでいちいち実行するのは億劫だ。

二つ目の問題はデフォルトでインストールされるシェルが少ないことだ。自分の環境では主にFreeBSD、またDebian系(Ubuntu)、RHEL系(CentOS)、さらにはMac OS Xと数種類のOSを利用している。その中でデフォルトでインストールされるシェル、となると実は結構少ない。FreeBSDではcsh若しくはtcshをデフォルトシェルにする事が多い。対してLinuxではbashがデフォルトシェルとなることがおおい。そして残念な事にはFreeBSD/Linuxに於いては(t)csh/bashがお互いにデフォルトでインストールされていない。
ということはbashならbashをLDAPのデフォルトシェルにしてしまって、bashの環境ファイルである.bashrcなどでzshを呼び出す、という事ができない。

以上の点を踏まえながら試行錯誤していった結果、「UNIX/Linuxの両方に入っているシェルを使ってログイン時にzshにしてしまう」という方法にたどり着いた。ちなみにそのUNIX/Linuxの各種OSの最大公約数と言うべきシェルはsh。
shとはThompson shellを意味し、bashの前身となったシェルだ。過去にはバックスペースすら無かった気もするけれど、カーソルキーで入力位置を変更できない、コマンド履歴が使えないというシェルの基本的な機能のみしか持っていない素朴なシェルだ。
(とは言え、過去のbashも同様でデフォルトではコマンド履歴なども使えなかった気がしてbashとshのデフォルト状態での違いがあまり無いような状態だったんだけれど、最近のbashは使いやすいシェルっぽくなってる)
さてLDAPではこのshをデフォルトシェルにし、shが立ち上がった後にzshを呼び出すようにしてみる。

shでログインされた際に呼ばれる環境ファイルは “.profile”ファイルである。”.login”かと思ったんだけれどこれはshだと実行されないしcsh系だった気がする。つまりsh系ではダメということ。
この.profileファイルには直接shに実行して欲しいことを記述する。以下に例を示す。

[ -x /usr/local/bin/zsh ] && exec /usr/local/bin/zsh
[ -x /bin/zsh ] && exec /bin/zsh

shらしい記述で条件式を書き、それぞれのバイナリが存在し実行可能であればexecしてやる。execでシェルを呼び出せばログインシェルが切り替わった動作になるのでCtrl+Dなどでシェルを抜けたときにzshを支えているshも一緒にexitしてくれる。つまりログインシェルがzshになったようにみえてshを意識することが無い。

以上で思っていたようなzshなどのパスが違う環境でログインシェルを統一する、ということが可能になった。

めでたしめでたし。