Category Archives: FreeBSD

[メモ][FreeBSD] 複数Jailのpkg upgradeを一気に済ませたい

Pocket

メモ。

jailのpkg操作は、いちいちそのjailの中に入らなくてもpkg -j <jail名 or jail ID> …というように-jオプションを付与すればできる。

しかしjailの指定は、個々に行う必要がある。
たとえばpkg -j * upgradeというように、ワイルドカードを使うようなことは、もってのほかのようである。
jailなんてどんどん増えていくのに、いちいち-jで指定していくのもなあ。
仕方ないんで、やっつけでパイプを繋いで実現。

jls -N|tail -n +2|cut -f2 -d" "|xargs -I{} sudo pkg -j {} upgrade

以上

[メモ][FreeBSD] owncloud + nginx + php-fpm + MySQLのインストール

Pocket

owncloudは自家製dropboxのようなもの。
以下、メモ。

owncloudの構成

owncloudはphpで作られている。
そしてインタフェースはhttps。
したがって、動作にはowncloudのほかに、php, webサーバが必要。
さらにバックエンド用のデータベースソフトウェアも必要である。

packageのowncloud

owncloudはバックエンドのDBにMySQL, SQLiteなどが選べる。
個人用ならSQLiteでも大丈夫そうだが、packageに用意されているowncloudはMySQLが有効、SQLiteが無効になっている。
SQLite版owncloudが欲しければportsからコンパイルする必要がある。
これまた面倒なのでpackageのものを使った。
packageからowncloudをインストールすると、phpは勝手に入るが、webサーバ、MySQLは別にインストールする必要がある。
ここではwebサーバにnginxを選んだ。
ではMySQLは。

MySQLのバージョン選定

いや、MySQLはMySQLに決まっているんだが、実はpackageを探すと、5.1, 5.5, 5.6の三つがあるのだ。

$ pkg search "^mysql.*server"
mysql51-server-5.1.73_2
mysql55-server-5.5.43
mysql56-server-5.6.24

果たしてどれを選べばよいのであろうか。
http://www.liquidweb.com/kb/mysql-5-1-vs-5-5-vs-5-6-performance-comparison/
以上のURL他を見たところ、最新の5.6で良さそうなのでmysql56-server-5.6.24をインストールしておいた。

owncloudのインストール

packageで入れるだけ。
いっしょにnginx, mysql5.6も入れる。

# pkg install owncloud nginx mysql56-server

MySQLの設定

owncloudのデータベースを受け持つMySQLの設定
システム起動時にMySQLも自動的に起動するように設定。

# sysrc mysql_enable=YES
mysql_enable:  -> YES

すぐ起動

# service mysql-server start
Starting mysql.

mysql_secure_installationでセキュリティを高めておくと同時にスーパーユーザのパスワードも設定。

# mysql_secure_installation

データベースの作成
USERはユーザ名に、CHANGE_THIS_PASSWORDはパスワードに書き換えること。

# mysql -p -e "create user 'USER'@'localhost' identified by 'CHANGE_THIS_PASSWORD';"
# mysql -p -e "create database if not exists owncloud;"
# mysql -p -e "grant all on owncloud.* to 'USER'@'localhost' identified by 'CHANGE_THIS_PASSWORD';"
# mysql -p -e "flush privileges;"

phpの設定

owncloudはphpで書かれている。そのphpの設定。
とはいえ、特別、何かすることはない。

/usr/local/etcにあるphp.ini-production を、php.ini としてコピー

次に/usr/local/etc/php/extensions.ini に以下の記載があることを確認する(デフォルトで記載があるはず)

extension=pdo.so
extension=mysql.so

php-fpmの設定

そのままでは静的コンテンツしか扱わないnginxが、phpを実行できるようにするための設定。
php-fpmがデーモンとして動作し、nginxからの要求に応じてphpを実行して結果を返す。
したがってphp-fpmとnginxがどう通信するかを規定したり、システム起動時にphp-fpmが自動的に起動するような指定が必要。

まずはphp-fpmの設定。
/usr/local/etc/php-fpm.confに以下があればよい。
それ以外はむしろ冗長だし、見にくくなるので削ってしまってよい。

[global]
pid = run/php-fpm.pid
error_log = log/php-fpm.log

[owncloud]
listen=/var/run/php-fpm.socket
listen.owner=www
listen.group=www
listen.mode=0666
listen.backlog=-1
listen.allowed_clients=127.0.0.1
user=www
group=www
pm=dynamic
pm.max_children=4
pm.start_servers=1
pm.min_spare_servers = 1
pm.max_spare_servers = 2
pm.max_requests = 500
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

システム起動時のphp-fpm起動設定
/etc/rc.conf内ではphp-fpmではなくphp_fpmとなることに注意(ハイフンではなくアンダースコア)

sysrc php_fpm_enable=YES
php_fpm_enable: -> YES

nginxの設定…の前に、SSLの準備

SSLのためにはサーバの鍵が必要。
手前味噌だが、ここにあるスクリプトを使ってくれい。

秘密鍵、証明書、DHパラメータ、三つのファイルを作成して、/usr/local/etc/sslあたりに入れる。

nginxの設定

以下、二つのサイトを参考にしつつ作成。

https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.8.0&openssl=1.0.1l&hsts=yes&profile=intermediate
https://doc.owncloud.org/server/7.0/admin_manual/installation/nginx_configuration.html

出来たのが以下。

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    server {
        listen       80;
        server_name  localhost;

        return 301 https://$server_name$request_uri;
    }

    upstream php-handler {
        #server 127.0.0.1:9000;
        #server unix:/var/run/php5-fpm.sock;
        server unix:/var/run/php-fpm.socket;
    }

    server {
        listen       443 ssl;
        server_name  localhost;
        #
        # Generated with;
        # https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-
1.8.0&openssl=1.0.1l&hsts=yes&profile=intermediate
        #

        # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
        ssl_certificate /usr/local/etc/ssl/server.crt;
        ssl_certificate_key /usr/local/etc/ssl/server.key;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;

        # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
        ssl_dhparam /usr/local/etc/ssl/dhparam.pem;

        # intermediate configuration. tweak to your needs.
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RS
A-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES
128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-
AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECD
HE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-D
SS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-
DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256
:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!D
ES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
';
        ssl_prefer_server_ciphers on;

        # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
        add_header Strict-Transport-Security max-age=15768000;

        # OCSP Stapling ---
        # fetch OCSP records from URL in ssl_certificate and cache them
        ssl_stapling on;
        ssl_stapling_verify on;

        ## verify chain of trust of OCSP response using Root CA and Intermediate certs
        ssl_trusted_certificate /usr/local/etc/ssl/cert.pem;

        # end of generated


        #
        # copyed from https://doc.owncloud.org/server/7.0/admin_manual/installation/ngi
nx_configuration.html
        #

        # Path to the root of your installation
        root /usr/local/www/owncloud/;
        # set max upload size
        client_max_body_size 10G;
        fastcgi_buffers 64 4K;

        # Disable gzip to avoid the removal of the ETag header
        gzip off;

        # Uncomment if your server is build with the ngx_pagespeed module
        # This module is currently not supported.
        #pagespeed off;

        rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
        rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
        rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

        index index.php;
        error_page 403 /core/templates/403.php;
        error_page 404 /core/templates/404.php;

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

        location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README){
                deny all;
        }

        location / {
                # The following 2 rules are only needed with webfinger
                rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json
 last;

                rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
                rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;

                rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

                try_files $uri $uri/ /index.php;
        }

        location ~ \.php(?:$|/) {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                fastcgi_param HTTPS on;
                fastcgi_pass php-handler;
        }

        # Optional: set long EXPIRES header on static assets
        location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                expires 30d;
                # Optional: Don't log access to assets
                access_log off;
        }
    }

nginxの起動設定とサービススタート

# sysrc nginx_enable=YES
nginx_enable: -> YES

nginx, php-fpmを起動し、https://<サーバアドレス>にブラウザで繋げばOK

# service php-fpm start
# service nginx start

その他参考

https://doc.owncloud.org/server/7.0/admin_manual/configuration/database_configuration.html

No tags for this post.

[FreeBSD][メモ] portsでmake cleanを依存portsも含めて実行するには

Pocket

さきにメモ。

portsにおいて、依存も含めた全部のportsでmake cleanをするには以下のようにする。

find /usr/ports -name work -mindepth 2 -maxdepth 3 | xargs rm -Rf

ネタ元はfreebsd forumから。

 

久しぶりにportsを使うと、なんでこんな面倒なものに我慢できていたんだろう?と思う。
それは単なる愚痴として。

Vagrantやjailなどの仮想技術がとても便利になってきて、実現したい機能ごとに環境を分けるようになる。
すると、環境ごとにフレッシュな状態から機能を構築することが多くなり、自然とportsのコンパイル時間の長さが目につくようになったのだと思う。

たとえばredmineを使いたいとして、pkgでインストールしようとしても、コンパイルオプションが期待通りではないので、やむなくportsでインストールしようとする。
ところが、インストールされたものがない、フレッシュな状態でredmineをportsから入れようとすると、依存の端から端までportsで入れようとするので、とんでもない時間がかかるのである。
特定のもの以外は全部pkgで入れられるようにならないものか。

No tags for this post.

[FreeBSD] jailのetcを更新する(qjail)

Pocket

qjailだと、ここで示したようにqjail update -bでjailのバイナリアップグレードをしてくれる。

アップグレードといっても、ホストのバイナリをjailのsharedfsにまるまるコピーしているだけである。
ということは、通常のアップグレードで更新されるはずの/etc下ファイルには一切、手を付けないということ。

jailのetc更新にはmergemaster

実はmergemasterは更新するフォルダを-Dオプションで選ぶことができる。
つまり、ホストのsrcをベースにjailのetcを更新できる。

jailの/etcを更新するには

jail ex01を更新する場合は、以下の通り。-D以外のオプションはUPiF。

$ sudo mergemaster -UPiFD /usr/jails/ex01/

新しくjailを作る際のテンプレートも更新しておく。

$ sudo mergemaster -UPiFD /usr/jails/template/

以上

[FreeBSD] pkg quarterlyとlatestレポジトリの共存

Pocket

ここでも触れたが、10.2-RELEASEから、pkgレポジトリのデフォルト参照先がlatestからquarterlyになった。
具体的には/etc/pkg/FreeBSD.confの内容が変わった。

だからして、引き続きlatestを参照したい場合には、/etc/pkg/FreeBSD.confを書き換えればいいや、と思っていたものの、どうもこのファイルは「なるべく触るな」ということのようである。

つまり、もしもの時にlatestを参照する場合には、quarterly(すなわちデフォルト)の他に、latest向けのレポジトリ設定ファイルを作る必要がある。

それぞれを、いちいちenable/disableするのも面倒なので、latest、quarterlyの双方を参照するよう、Multi-repositoryの設定をした。

本記事ではMulti-repositoryの設定方法について示す。
と同時に、普段はquarterlyを使い、特定のときだけlatestを使うための方法を示す。

まずデフォルトの/etc/pkg/FreeBSD.confについて

/etc/pkg/FreeBSD.confは触るな

/etc/pkg/FreeBSD.confの中身を見てみると、以下のような記載がある。

# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

すなわち、この設定を無効化したい場合には、/etc/pkg/FreeBSD.confは触らずに、/usr/local/etc/pkg/repos/FreeBSD.confを作ったうえで、無効化の宣言をしろ、ということである。

/etc/pkg/FreeBSD.confはデフォルト設定として扱いたい雰囲気丸出しであるが、そうならrc.confのデフォルト設定が/etc/defaultsの下にあるように、/etc/pkg/defaults/FreeBSD.conf的なものを作ってくれても良いのではないかと思った。

しかしそもそも、レポジトリの設定ファイルはどのように読み込まれるのであろうか。

レポジトリ設定ファイルの読み込まれる順番

/usr/local/etc/pkg.confで指定する。
上記ファイルの中に、REPOS_DIRがある。
pkgは、ここに記載された順番通りにレポジトリ設定ファイルを読み込む。
特に変更していないのであれば、内容は下記の通り。

REPOS_DIR [
    "/etc/pkg/",
    "/usr/local/etc/pkg/repos/",
]

仮に複数のディレクトリに、同じレポジトリに対する設定ファイルがあったならば、後から読み込まれたもので上書きされる。
同じディレクトリに複数のファイルがあったならば、ファイルはアルファベット順に読み込まれる。

以下、マニュアルからの引用

Repositories are processed in the order they are found on the REPOS_DIR search path, with individual repository configuration files in the same directory processed in alphabetical order. Settings from files later in the search path will override those from earlier ones.

だから、/etc/pkg/FreeBSD.confのコメントに書いてある通り、/usr/local/etc/pkg/repos/FreeBSD.confでFreeBSDレポジトリを無効にする宣言をすると、設定が上書きされ、めでたくFreeBSDレポジトリは無効になる。

ところで、同じディレクトリ内の読み込み順序はアルファベット順、というのがキモで、実はレポジトリの名前と設定ファイルの名前は別々でも構わない。
だから、読み込ませたい順番に応じて、ファイル名の頭に数字を入れてもよい。

latestレポジトリ向けの設定はどこに?またどうやって?

さて。
仕組みはわかった。
どうも/etc/pkg/は触ってほしくないようだから、/usr/local/etc/pkg/reposにlatest向けの設定ファイルを置けばよいのだろう。
しかしちょっと待て。
latestとquarterlyを両立させるにはどのようにしたら良いのであろうか。

レポジトリの優先度について

複数のレポジトリを参照する場合、どちらをどの程度優先するか。
レポジトリ設定ファイルにpriorityという設定項目があるので、それを使えば優先度の設定ができる、ようだが。

以下はマニュアル。

PRIORITY: integer    Set the priority of the repository.  Higher
                     values are preferred.  Default: 0

レポジトリ設定ファイルにPRIORITYで優先度を指定すればよい。
数値が高ければ高いほど、優先度が高い。

ふむふむ。
では、動作は?

優先度設定されたときの動作

WORKING WITH MULTIPLE REPOSITORIES
  Where several different repositories are configured pkg will search
  amongst them all in the order specified by the PRIORITY settings in the
  repo.conf files, unless directed to use a single repository by the -r
  flag (略)

「複数のレポジトリが与えられた場合、pkgは、-rで参照先レポジトリを明示されない限り、PRIORITYの順番で検索を行う。」

ほほう。なるほど。
続けて読む。

  Where several different versions of the same package are available, pkg
  will select the one with the highest version (略)

「異なるバージョンのpackageが見つかった場合、最も高いバージョンが選ばれる。」

アレ!? 話が思わぬ方向に向かってきたよ!
優先度の高いレポジトリからインストールしてくれるんじゃないの!?

  even if a lower numbered version can be found in a
  repository earlier in the list

「低いバージョンが優先度の高いレポジトリにあったとしてもこの動作は変わらない。」

Oh…。

  This applies even if an explicit version is stated on
  the command line.  Thus if packages example-1.0.0 and
  example-1.0.1 are available in configured repositories(後略)

「さらにさらに、仮にバージョンを指定してインストールを実行しても、
動作は変わらない。
高いバージョンが見つかったら問答無用で新しい方をインストールする。」

ぐぬぬ。

基本、quarterlyを使い、特定のときだけlatestを使うためには

上記の動作を踏まえ、基本、quarterlyを使い、特定のときだけlatestを使うためには、以下の方法がある。

A. 都度、レポジトリ設定ファイルを使い分ける。
B. マルチレポジトリにしつつ、インストール時に考慮をする。

ここでA.を選ぶと芸がないので、B.の方法を示す。
B.の方法と言っても、以下の通りでOK。

最初にquarterlyレポジトリからインストールする。
-rオプションで参照先レポジトリを明示すること。

pkgは、そのpackageをどこからインストールしたかを覚えている。
後に示す設定を変えない限り、アップグレードの際には同じレポジトリを参照してくれる。
だから、最初のインストールでquarterlyを選んでおけば、次回アップグレードのときにも、原則としてquarterlyが選ばれるというわけ。

これをコンサバティブアップグレード(conservative upgrade)といい、pkg.confでデフォルト有効になっている。

  CONSERVATIVE_UPGRADE: boolean
    Ensure in multi repository mode that the priority is given
    as much as possible to the repository where a package was
    first installed from.  Default: YES.

説明を読むと;

  To override this
  behaviour, on first installation of the package select the repository
  with the appropriate version:
     pkg install -r repo-a example-1.0.0
  and then to make updates to that package ``sticky'' to the same reposi-
  tory, set the value CONSERVATIVE_UPGRADE to true in pkg.conf.

「(常に高いバージョンを選ぶ)この動作を変更するには、最初のインストールで
-rオプションによりレポジトリを選ぶ。
その後のアップグレードで同じレポジトリを使うには、pkg.confの
CONSERVATIVE_UPGRADEでtrueを選べばよい。」

以上

[FreeBSD] 10.2-RELEASEから適用されるpkg quarterlyてなんだ。

Pocket

10.2-RELEASEから、pkgのデフォルト参照先レポジトリが”quartely”のものになる。

◎pkg.confの変更

-# $FreeBSD: releng/10.1/etc/pkg/FreeBSD.conf 263938 2014-03-30 15:29:54Z bdrewery $
+# $FreeBSD: releng/10.2/etc/pkg/FreeBSD.conf 285830 2015-07-23 23:31:40Z gjb $

 FreeBSD: {
-  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
+  url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
}

ご覧のとおり、いままでは”latest”。
これは言わばpkgのheadのようなもので、最新のpkgは手に入るものの、うっかりインストールすると地雷を踏むことがが多かった。

quarterlyは上記の問題を解決するために設けられる。
中の人によれば「意図的に更新速度を控えめにすることで、問題の発生を抑える一方、セキュリティ更新は受け取れるようにする」とのこと。
もちろん、望ならば今まで通りlatestを参照することもできる。

“In general, the quarterly package set is less prone to having build failures, since the changes in the branch are (by intent) less intrusive, while still receiving security updates. “

latestからquarterlyに変更してバージョンチェックしてみると、すでにインストール済みのpackageからバージョンの下がるケースも見られた。

python27-2.7.10                    >   succeeds remote (remote has 2.7.9_1)

詳細は待て10.2-RELEASEのアナウンス。

“(This will be noted in the final 10.2-RELEASE announcement, as well as
the release notes, and will also include instructions on how to switch
to the ‘latest’ branch if that is what is desired.)”

中の人の発言は以下から引用。
https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082905.html

[FreeBSD][メモ] ACL(Access Control Lists)を有効にする

Pocket

ACLとは、一般的なUNIXのパーミッション制御をさらに拡張したものである。
FreeBSDのハンドブックは以下の通りであるが、どうも実動作とハンドブックの内容に食い違いがあるようなのでメモ。

https://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/fs-acl.html
https://www.freebsd.org/doc/en/books/handbook/fs-acl.html

ACLはファイルシステムごとに有効/無効を設定できる。
設定変更は、そのファイルシステムをumountするか、リードオンリーの状態でしかできない。
したがって、ルートファイルシステムの設定変更は、通常起動した後ではできない。

 

ACLの有効/無効化

GENERICカーネルであればACLが使える。

ACLを有効にするには、/etc/fstabの当該ファイルシステムオプションにaclsを追加し、再起動すればよい。
もちろん、ルートファイルシステム以外なら、再起動しないまでも、いったんumount、mountすればよい。
mount -uによる再マウントでは有効にならないので注意
fstab設定例は後述

 

ACLの有効/無効化のしくみ

ファイルシステムヘッダのスーパーブロックにACLの有効/無効フラグがある。tunefsコマンドでフラグを変更できる。
fstabでaclsが指定されていると、マシン起動時に、tunefsでスーパーブロックを書き換えののち、マウントされる。

 

注意点(一度ACLを有効にしたら永続…?)

ハンドブックによれば、一度ACLを有効にしたらその設定が永続する、という。
「スーパブロックフラグを設定すると、fstab に記述されていなかったり、デバイスの順番が変わってしまっても、常に ACLs が有効な状態でマウントされます」
※英語版も同じ。

 

ハンドブックとの違い?

ところが手元のマシンの動作を見ると、tunefsによる設定に関わらず、fstabのオプションしか参照していないようだ。
つまり、fstabでaclsを削ると、ACL無効でマウントされるようだ。
(fstabにaclsが無い場合、tunefs -a disableが実行される?)

それはともかく、上記を踏まえた設定例を示す。

 

fstabの設定変更

fstabのOptionsのところ、カンマに続けて「acls」と記載。
ルートファイルシステムなら、再起動。
ルートファイルシステム以外なら、umount,mountでよい。
ACLの設定はハンドブック参照。

設定前

# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/ada0p2     /               ufs     rw      1       1

設定後

# Device        Mountpoint      FStype  Options Dump    Pass#
/dev/ada0p2     /               ufs     rw,acls  1       1

以上。tunefsは考えなくてよし。

以下は記録。

 

tunefsのうごき

tunefs -pでACLの状態を確認できる。

# tunefs -p /dev/ada0p2
tunefs: POSIX.1e ACLs: (-a)   disabled

tunefs -a enable/disableでACLの有効、無効を設定できる

# tunefs -a enable /dev/ada0p2
tunefs: POSIX.1e ACLs set

# tunefs -p /dev/ada0p2
tunefs: POSIX.1e ACLs: (-a)   enabled

/dev/ada0p2 は、ルートファイルシステムなのだが、そのまま起動すると、あるいは再起動するとtunefs -pの結果がdisabledに戻ってしまう。
さらに分からないのは、fstabにaclsの記載あるなしに関わらずdisabledになること。

 

実験(fstabしか見ていない…?)

fstabにaclsを記載し、あるファイルにsetfaclでACLを設定する。
ls -laで確認すると以下のように+が付く。

$ setfacl -m u:nobwak:r,o:: file.txt
$ ls -la ./file.txt
-rw-r-----+ 1 doe  doe  8  4月 23 13:45 ./file.txt
$ mount
/dev/ada0p2 on / (ufs, local, journaled soft-updates, acls)

その後、fstabからaclsを削除し、再起動したのち、ls -laで確認すると+がない。

$ ls -la ./file.txt
-rw-r-----  1 doe  doe  8  4月 23 13:45 ./file.txt
$ mount
/dev/ada0p2 on / (ufs, local, journaled soft-updates)

なお、上記の再起動前後を通してtunefs -pの結果はdisabled.

[FreeBSD] Samba 3.xからSamba 4.xへの移行

Pocket

Sambaの4.2.0リリースに伴い、3系列サポートが終了する、とのことなので、4.xに移行した。
顛末を記す。

Samba 3系列のサポート終了について

一応はソースを。
4.2.0のリリースノートに記載されている。

https://www.samba.org/samba/history/samba-4.2.0.html

With the final release of Samba 4.2, the last series of Samba 3 has been discontinued! People still running 3.6.x or earlier,should consider moving to a more recent and maintained version (4.0 – 4.2).

 

Samba 4について(Active DirectoryにしなくてもOK)

Samba 4はActive Directoryに対応しているが、従来のドメイン管理(NT4-style)もできる。
Active Directory対応の追加により、従来機能が差し替わることはないし、テストも続けられる。

なお、3から4へのアップデートで、自動的にActive Directoryへ変更されることはない。

 

移行先の選定(4.1にした)

どうせ移行するなら4.2がいいなと思ったんだけど、2015/4/28現在、4.2のports/packageはない。
しかたなく4.1にした。

 

移行にあたっての注意

4へのアップグレードにあたり注意すべきことは以下の三点である。
うっかりすると、マシン起動時にsambaが起動しなかったり、共有が消えたり、ユーザがアクセスできなくなったりする。あな恐ろし。

  1. rc.conf(マシン起動時のsamba起動設定)の書き換え
  2. samba設定ファイルの移行
  3. sambaユーザデータベースの移行

 

インストール(アップグレード)の流れ

全体の流れを示す。

  1. samba3を停める。
  2. samba3の削除
  3. samba4のインストール
  4. rc.confの書き換え
  5. 設定ファイルの移管
  6. ユーザーデータベースの移管
  7. 起動

 

Samba3の停止

アンインストールの前に。
なお、serviceコマンドで使うSambaの識別子は、3の”samba”が4では”samba_server”に変わる(後述)。

$ sudo service samba stop
Stopping smbd.
Waiting for PIDS: 654.
Stopping nmbd.
Waiting for PIDS: 651.

 

Samba3の削除とSamba4のインストール

pkgならsamba4のインストール時にsamba3を削除してくれる。
samba4インストール後のメッセージは超重要。

$ sudo pkg install samba41
(略)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 6 packages will be affected (of 0 checked):

(nobwak注 samba3は自動的に削除される)
Installed packages to be REMOVED:
samba36-3.6.25

New packages to be INSTALLED:
cyrus-sasl: 2.1.26_9
libinotify: 20140622
gamin: 0.1.10_8
ldb: 1.1.19_1
samba4: 4.1.17 
(略)
Message for samba4-4.1.17 :
 ===============================================================================
How to start: http://wiki.samba.org/index.php/Samba4/HOWTO
* Your configuration is: /usr/local/etc/smb4.conf
* All the relevant databases are under: /var/db/samba4
* All the logs are under: /var/log/samba4
* Provisioning script is: /usr/local/bin/samba-tool
(略)
Bug reports should go to the: https://bugzilla.samba.org/
===============================================================================

 

rc.confの書き換え

本記事の手順上、rc.confの書き換えをここに記載しているが、本来は設定ファイルの正常性確認や検証を済ませてからのほうがよい。

sambaの3と4では、rc.confの書式が違う。
ここを忘れたままだと、serviceコマンドでのsambaサーバの操作ができないし、次回のマシン再起動時にsambaが自動起動しない。

samba3だと;
samba_enable=”YES”
samba4だと;
samba_server_enable=”YES”

したがって、rc.confは以下のようになる。
もちろん、samba3の方は、不要なら削除して構わない。

# samba_enable="YES"
samba_server_enable="YES"

 

設定ファイルの移管

sambaの3と4では、設定ファイルの場所は/usr/local/etc/の下で変更ないのだが、ファイル名が異なる。
気づかずにsamba4を起動すると共有フォルダが消える。

samba3だと;
smb.conf
samba4だと;
smb4.conf

samba3の書式はsamba4でも有効なので、コピーするかリンクを張る。
私はリンクにしておいた。

$ cd /usr/local/etc/
$ sudo ln -s ./smb.conf ./smb4.conf
$

ユーザーデータベースの移管

samba向けのユーザデータベースも移管が必要である。
これをしないとユーザごとの認証ができない。
これには、ほとほと困らされた。

ユーザデータベースの置き場所は以下の通り。

samba3だと;
/usr/local/etc/samba/
samba4だと;
/var/db/samba4/private/

したがって、/var/db/samba4/privateとディレクトリを作成し、/usr/local/etc/samba/の下にあるファイルをコピーすればよい。

なお、samba4のユーザデータベース置き場をどう調べたかというと、ビルドオプションを表示させてPRIVATE_DIRを見た。
(こんなのすぐ分かるかよ!)

$ smbd -b|less

Build environment:
   Built by:    root@101i386-default-job-07
   Built on:    Thu Apr 16 17:40:08 UTC 2015
   Built using: cc
   Build host:  FreeBSD 101i386-default-job-07 10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 i386
   SRCDIR:      /wrkdirs/usr/ports/net/samba41/work/samba-4.1.17/source3
   BUILDDIR:    /wrkdirs/usr/ports/net/samba41/work/samba-4.1.17/source3

Paths:
   SBINDIR: /usr/local/sbin
   BINDIR: /usr/local/bin
   CONFIGFILE: /usr/local/etc/smb4.conf
   LOGFILEBASE: /var/log/samba4
   LMHOSTSFILE: /usr/local/etc/lmhosts
   LIBDIR: /usr/local/lib
   MODULESDIR: /usr/local/lib/shared-modules
   SHLIBEXT: so
   LOCKDIR: /var/db/samba4
   STATEDIR: /var/db/samba4
   CACHEDIR: /var/db/samba4
   PIDDIR: /var/run/samba4
   SMB_PASSWD_FILE: /var/db/samba4/private/smbpasswd
   PRIVATE_DIR: /var/db/samba4/private
(以下略)

 

起動

起動前にtestparmでsmb4.confのチェックをするのはいい習慣であります。

$ testparm
Load smb config files from /usr/local/etc/smb4.conf
Processing section "[fileshare]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

[global]
(略)

では起動。
rc.confでsamba_server_enable=”YES”と記載しているなら、以下の通り。

$ sudo service samba_server start
Performing sanity check on Samba configuration: OK
Starting nmbd.
Starting smbd.
Starting winbindd.
$

していないなら、以下のように「onestart」にする。

$ sudo service samba_server onestart

以上。

[FreeBSD][メモ] pkgngで複数レポジトリ使ってる奴は1.4.3に上げておけ

Pocket

pkgngが1.4.3に上がった。
これより前のpkgngでは、複数レポジトリをうまく扱えない。
したがって、レポジトリ参照先にpourdriere等による自前レポジトリと公式レポジトリを設定している諸氏は1.4.3に上げるのが得策。

具体的には以下。
ports-mgmt/pkg: pkg install uses the wrong repository for some packages
要するに、追加したレポジトリからpkgをインストールしても、pkgngが公式レポジトリからpkgをダウンロードしようとする。

1.4.3では複数レポジトリを扱うための仕組みが追加された。
端的に言えば、複数レポジトリに優先度設定ができる。
まずpkg.confでCONSERVATIVE_UPGRADEを有効にし、各レポジトリの設定でPRIORITYを整数値で指定すれば、複数レポジトリの優先度を決められる。

詳細はman pkg.confせよ。
CONSERVATIVE_UPGRADEはこちら。

CONSERVATIVE_UPGRADE: boolean
 Ensure in multi repository mode that the priority is given
 as much as possible to the repository where a package was
 first installed from.  Default: NO.

PRIORITYはこちら。

PRIORITY: integer    Set the priority of the repository the
                     higher is the prefered repository.
                     Default: 0

[FreeBSD] システムアップグレード時にはzpool(ZFS)のアップグレードも忘れずにNE!

Pocket

10.1-RELEASEにアップグレードしたけどzpool(ZFS)のアップグレードを忘れてたのでメモ。
アップグレードでfeaturesがいくつか追加されるから、まあやっておくのがおすすめ。
9.x系列からのアップグレードの場合は、以下を参照のこと。
[メモ]zpoolのupgrade
[メモ]zpoolのVersionについて(Versionナンバはもう使われない)

10.1-RELEASEで追加されるfeaturesは以下の通り。
詳細はman zpool-featuresせよ(手抜き)。
この中ではbookmarksがすごいと思うよ。

  spacemap_histogram
  enabled_txg
  hole_birth
  extensible_dataset
  embedded_data
  bookmarks
  filesystem_limits

アップグレードが必要かどうかは、zpool statusで分かる。

$ zpool status

  pool: warehouse
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        warehouse   ONLINE       0     0     0
          ada2      ONLINE       0     0     0

errors: No known data errors

前も書いたと思うけど、ZFSは「何をすべきか」まで教えてくれるのがとても助かる。
ファイルシステムなんてそんな頻繁にいじらないし、久しぶりだとコマンド忘れてしまうからね。
この場合はzpool upgradeせよと。

まず一般権限でzpool upgrade。

$ zpool upgrade
This system supports ZFS pool feature flags.
All pools are formatted using feature flags.

Some supported features are not enabled on the following pools. Once a
feature is enabled the pool may become incompatible with software
that does not support the feature. See zpool-features(7) for details.

POOL  FEATURE
---------------
warehouse
      spacemap_histogram
      enabled_txg
      hole_birth
      extensible_dataset
      embedded_data
      bookmarks
      filesystem_limits

追加されるfeaturesを確認したらスーパーユーザでもう一度zpool upgrade。
すぐ終わる。
お約束だが、フルバックアップは取っておこうな!

$ sudo zpool upgrade warehouse
This system supports ZFS pool feature flags.

Enabled the following features on 'warehouse':
  spacemap_histogram
  enabled_txg
  hole_birth
  extensible_dataset
  embedded_data
  bookmarks
  filesystem_limits