【メモ】暗号化されたLVMボリュームにfsck

USBメモリに入れたUbuntu(LiveOS)で起動

暗号化されたボリュームを復号化する

$ sudo cryptsetup luksOpen /dev/nvme0n1p3 ubuntu
Enter passphrase for /dev/nvme0n1p3: password

$ ls /dev/mapper/ubuntu
/dev/mapper/ubuntu

LVMボリュームとして認識された

$ sudo lvscan
ACTIVE ‘/dev/ubuntu-vg/root’ [236.25 GiB] inherit
ACTIVE ‘/dev/ubuntu-vg/swap_1’ [976.00 MiB] inherit

fsckをかける

$ sudo fsck -f /dev/ubuntu-vg/root
fsck from util-linux 2.32
e2fsck 1.44.4 (18-Aug-2018)
Pass 1: Checking iノードs, blocks, and sizes
Pass 2: Checking ディレクトリ structure
Pass 3: Checking ディレクトリ connectivity
Pass 4: Checking reference counts
Pass 5: Checking グループ summary information
/dev/mapper/ubuntu–vg-root: 263415/15491072 files (1.2% non-contiguous), 5875518/61932544 blocks


Ubuntu 18.04 で ClamAV オンアクセススキャンを使ってみる

言わずとしれたオープンソースのアンチウィルスソフト
基本的にはリアルタイムに検知する機構はこねくり回さないと使えないみたいなのでメモを残しておきます。

まずはパッケージを入れる

$ sudo apt install clamav clamav-daemon

root ユーザで動くように clamd.conf を書き換える。

$ sudo sed -i -e 's/User clamav/User root/' -e 's/LocalSocketGroup clamav/LocalSocketGroup root/' -e 's/ScanOnAccess false/ScanOnAccess true/' /etc/clamav/clamd.conf

freshclam.conf で見ているデータベースが存在しないようなので動いているものに書き換える。

$ sudo sed -i 's/db.local.clamav.net/db.us.big.clamav.net/g' /etc/clamav/freshclam.conf

例のごとく apparmor に停められるのでユーティリティをいれて許可してあげる

$ sudo apt install apparmor-utils

$ sudo aa-complain clamd

自動起動を有効にしてサービスを起動する

$ sudo systemctl enable clamav-daemon

$ sudo systemctl start clamav-daemon

検知テスト用の eicar.com などを cat するなどすると /var/log/clamav/clamav.log に検知したログが残る。
デフォルトの挙動では検知しても隔離してくれないみたいなのでオプションを調べようとおもったけど
SOPHOS Anti-Virus の方が楽ちんな気がしてきました。

参考情報

mdraid(RAID1)のディスク交換をしてみたメモ

自宅サーバで使用しているHP MicroServerはオンボードのRAIDがFakeRAIDでLinux用のドライバもないし(多分)使う価値がないので、
mdraidを使っていたのですが今までディスク交換のオペレーションを行ったことがありませんでした。

そしてとある日 Seagate ST2000DX001(SSD Hybrid Drive)を購入したので酒を呑みながら自宅サーバのディスク交換をしていたら、
血中アルコールの影響で頭の中がこんがらがってしまって最終的にはレスキューディスクでシステムをぶっ壊してしまったので
戒め書としてこのPOSTを余生に残しておく。

以下の状態からブロックデバイスsdcを追加してsdbを切り離すオペレーションを実施しました。
効率の良い方法を知っている方ツッコミ歓迎です。教えてください。

ディスクの構成

/dev/sda (md0 raid1 active)
+- /dev/sda1 (Extended Volume)
+- /dev/sda2 (Linux RAID Volume)
+- /dev/sda5 (Linux SWAP Volume)

/dev/sdb (md0 raid1 active)
+- /dev/sdb1 (Extended Volume)
+- /dev/sdb2 (Linux RAID Volume)
+- /dev/sdb5 (Linux SWAP Volume)

/dev/sdc (md0 standby)
+- Blank

fdiskでsdcのパーテーションを切る

交換前のディスクと同じ感じにパーテーションを切る

# fdisk /dev/sdc

(snip)

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

コマンド (m でヘルプ): p

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes
ヘッド 255, セクタ 63, シリンダ 243201, 合計 3907029168 セクタ
Units = セクタ数 of 1 * 512 = 512 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
ディスク識別子: 0xcd6994eb

デバイス ブート 始点 終点 ブロック Id システム
/dev/sdc1 3899213824 3907028991 3907584 5 拡張領域
/dev/sdc2 2048 3899213823 1949605888 fd Linux raid 自動検出
/dev/sdc5 3899215872 3907028991 3906560 82 Linux スワップ / Solaris

パーティションテーブル項目がディスクの順序と一致しません

 

md0(RAID1)のアレイにデバイスを追加する

# mdadm –manage /dev/md0 –add /dev/sdc2
mdadm: added /dev/sdc2

スタンバイ中のデバイスにデータをSync(rebuild)

# mdadm –manage /dev/md0 –raid-devices=3

Syncが終わったか確認

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc2[2] sdb2[1] sda2[0]
1949474624 blocks super 1.2 [3/3] [UUU]

unused devices: <none>

新しいDiskにgrubをインストール

# grub-install /dev/sdc
Installation finished. No error reported.

sdb2をfailにする

# mdadm –manage /dev/md0 –fail /dev/sdb2
mdadm: set /dev/sdb2 faulty in /dev/md0

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc2[2] sdb2[1](F) sda2[0]
1949474624 blocks super 1.2 [3/2] [U_U]

unused devices: <none>

sdb2をアレイから外す

# mdadm –manage /dev/md0 –remove /dev/sdb2
mdadm: hot removed /dev/sdb2 from /dev/md0

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc2[2] sda2[0]
1949474624 blocks super 1.2 [3/2] [U_U]

unused devices: <none>

SWAP領域を作る(fdiskでパーテション切られているのを前提)

# mkswap /dev/sdc5
スワップ空間バージョン1を設定します、サイズ = 3906556 KiB
ラベルはありません, UUID=46784dd2-6ca5-44f5-b18f-157ee2197182

fstabを確認

必要に応じて書き換えを行う

 # vi /etc/fstab

# /etc/fstab: static file system information.
#
# Use ‘blkid’ to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/md0 during installation
UUID=d54325b4-7b02-45d5-93f7-a8a049a50830 / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=4a3e84f9-5f51-4856-8306-08391cdc23bf none swap sw 0 0
# swap was on /dev/sdb5 during installation
UUID=46784dd2-6ca5-44f5-b18f-157ee2197182 none swap sw 0 0 <===今回の場合はsdb5のUUIDをsdc5のものに書き換える

swapon する

# free -m ; swapon -a ; free -m
total used free shared buffers cached
Mem: 7860 5466 2393 0 572 3704
-/+ buffers/cache: 1189 6670
Swap: 7629 0 7629
total used free shared buffers cached
Mem: 7860 5473 2386 0 572 3704
-/+ buffers/cache: 1195 6664
Swap: 11444 0 11444

古いディスクを外す

Hotswapじゃないけど気合で外す。
(SATAのコネクタはホットスワップ前提で作られているから電気的には大丈夫なはず。)

 

以上でひと通りの作業が完了のはずです。

今回の教訓 酒を呑みながらのオペレーションはやめよう。

 

NSD4 beta4 vs BIND9.8.1 ~NSDの逆襲~

前回の POST で BIND からの NSD4 の移行について書いたのだが、
その際にテスト程度に走らせたベンチマークについて物議を呼んだので
(NSDがBINDなんかに負けるはずが無い!とか config煮詰めろとか)
NSD4 側の config をいじりながら再度ベンチマークを取ってみた。

そうしたところ、とても興味深い結果が得られたので記しておく。

 

0. 検証環境

CPU : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz stepping 07 × 2

Memory : DDR3 1333 NonReg ECC 16GB

HDD : 146GB 15000rpm SAS RAID 1

OS : Ubuntu 12.04.2

DNS : NSD4 beta4 / BIND9.8.1 -P1(Ubuntu Packege)

 

1. ベンチマーク方法

ベンチの方法は前回と同様に 32110行のクエリを dnsperf に食わせて行う。
クエリを飛ばす側のマシンも上記とほぼ同様のスペックで用意した。

コマンドは下記のとおり。

 # dnsperf -c 16 -s 10.200.4.230 -d querylist -l 300

※10.200.4.230 は被験体

  • nsd.conf の server-count を変更しながらベンチマーク
  • 16クライアント(並列)で300秒クエリを飛ばす

server-count はリクエストを受け付ける nsd の子プロセスの数なので、
多ければ多いほどクエリを捌けるはず(素人考え)

config は下記のとおり Rate limit は Off にしておく。

server:
server-count: 4
username: nsd
zonesdir: “/etc/nsd4/zones”
zonelistfile: “/var/cache/nsd4/zone.list”
database: “/var/cache/nsd4/zone.db”
logfile: “/var/log/nsd4.log”
pidfile: “/var/run/nsd4/nsd4.pid”
xfrdfile: “/var/cache/nsd4/xfrd.state”
rrl-ratelimit: 0
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8952
server-key-file: “/etc/nsd4/nsd_server.key”
server-cert-file: “/etc/nsd4/nsd_server.pem”
control-key-file: “/etc/nsd4/nsd_control.key”
control-cert-file: “/etc/nsd4/nsd_control.pem”

 

2. ベンチマーク結果

 

表1 BIND と NSD4 の qps 比較

 Server (server-count) qps
BIND9.8.1 -P1 362923.554683
NSD4 b4 (1) 237789.686302
NSD4 b4 (2) 287640.556382
NSD4 b4 (4) 409956.827579
NSD4 b4 (6) 178863.252545
NSD4 b4 (8) 129717.122177
NSD4 b4 (16) 70822.115927

 

nsd4_svcount
図1 NSD4 beta4 server-count と qps

nsd_bind_comp

図2 ベンチマーク中のロードアベレージの推移 (NSD4 beta4/BIND9.8.1-P1)

3. 考察

今回の実験では NSD4の server-count を 4 にした場合は最もパフォーマンスがよく、
サーバへの負荷(ロードアベレージ)も低目の値を推移している。
これはゾーンをバイナリ化してメモリに保持している効果と思われる。

また、当初想定していた結果とは異なり、server-count の値と qps は比例しないという結果が出たのが興味深い。
ハードウェア(CPU) 依存の可能性もあるので、AMD製のCPUなどでも試してみようかと思う。

BIND に関しては qps  で言うと NSD4 に匹敵する値をたたき出しているが、ロードアベレージが高めを推移している。
コスト的にはあまりお得な感じはしないと言えるだろう。

ざっとベンチマークを取り直してみて NSD4 が速いことを証明できたので、
今回の目的は達成できたかな。

 

4. 参考文献

Unbound/NSD最新情報(OSC 2013 Tokyo/Spring) http://www.slideshare.net/ttkzw/unboundnsdosc-2013-tokyospring-16708977

NLnetLabs : DNS Response Rate Limiting as implemented in NSD. http://www.nlnetlabs.nl/blog/tag/nsd4/

Ubuntu 12.04 Desktop でEMOBILE GL04PをUSB接続してみた

昨今、S●ftbankやKD●Iなどの携帯電話キャリアがWifiのアクセスポイントをバラまいて、
有線回線へのオフロードを謀っておりますが、その影響でWifiのチャンネルが埋まってしまい、
いざというときにPocketWifiが使えないといったことが多くなってきた気がします。

※そもそもモバイルルータを持ち歩く人が多くなったせいもあるか。

WindowsもMacも使っていない私はUSBのドライバが用意されていないと思い込みで
数か月間EMOBILE GL04Pを使って来ましたが、勉強会・セミナーで不便を強いられることが
多くなってきたので、仕事をサボ(ry 快適環境を追い求めてみました。

手順は以下の通り。

1.ドライバのダウンロード

これが一番探すのに苦労した。

HUAWEIのサイトからLinux用ドライバを入手

http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=software&softid=NDcwMzU=

 

2.ドライバの展開

なぜかZIPを展開するとtar.gzが出てくるのでさらに展開

$ unzip HUAWEI\ Data\ Cards\ Linux\ Driver.zip

$ tar xf Linux\ Driver\ 4.19.19.00.tar.gz

 

3.ドライバのインストール

インストーラがついているので、実行するとmakeが始まる

$ cd driver/

$ sudo ./install

4.再起動

再起動してGL04Pを接続するとNetworkManagerで認識しているはずだ。

あまりに簡単すぎてあれだが、ドライバを探すのに時間を費やしたので記録に残しておく。

X86Android 4.0 RC2 on KVM

表題のとおり、X86Android 4.0 RC2をLinuxKVMで動かしてみました。
NICまわりで手こずったのでメモメモ。

下記のサイトを参考に、Ethernet patchのあたったイメージを使用する前提で話を進めます。

http://www.webupd8.org/2012/07/android-x86-404-ics-rc2-released-with.html

イメージは以下のものを使用しました。(なかなかダウンロードできない)

http://www.sendspace.com/file/t5a3aj

ISOを用意して、virtinstallで普通にインストールします。
ポイントはNICをmodel=e1000にするところですかね。これでインテルNICをエミュレートしてくれます。

$ sudo virt-install \
–connect=qemu:///system \
–name android4.0 \
–ram 512 \
–disk path=/var/lib/libvirt/images/android4.0.img,cache=writeback,sparse=true,size=5 \
–cdrom=’/home/yutaro/iso/desktop_generic.iso’ \
–vcpus=1 \
–os-type linux \
–os-variant generic26 \
–network bridge=br0,model=e1000 \
–vnc \
–accelerate \
–hvm

インストールが終わったら、デフォルトで入っている「端末エミュレータ」で /etc/init.sh を編集して
起動時にIPアドレスをStaticで振るようにする。(GUIの設定画面は使えませんでした)
各種アドレスは自分の環境に合わせて設定してください。

$ su –

# vi /etc/init.sh
(略)
ifconfig eth0 [IP ADDRESS] up ;Androidゲストのeth0にIPをつける
route add default gw [GATEWAY ADDRESS] dev eth0 ;デフォゲを指定する
setprop net.dns1 [RESOLVER ADDRESS] ;リゾルバ(DNSキャッシュサーバ)を指定する

これで再起動するとネットワークにつながっているはず。
pingとかで確認してみましょう。

仕事中に眠くなってきたので
といった感じで遊んでみました。

 

ユーザ権限で virt-manager がが

デスクトップOSとしてUbuntuを使うとサーバとの連携がいろいろと楽でいいのですが、
まれにその連携がうまくいかないことがあります。

今回はユーザ権限で起動したvirt-managerでlibvirtdに接続ができなかったので
対応した内容をメモ書きで残しておきます。

0. 環境

OS:Ubuntu 12.10 Desktop

1. エラー内容

libvirt に接続できませんでした。

Verify that:
– The ‘libvirt-bin’ package is installed
– The ‘libvirtd’ daemon has been started
– You are member of the ‘libvirtd’ group

Libvirt URI is: qemu:///system

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/connection.py”, line 1027, in _open_thread
self.vmm = self._try_open()
File “/usr/share/virt-manager/virtManager/connection.py”, line 1009, in _try_open
flags)
File “/usr/lib/python2.7/dist-packages/libvirt.py”, line 102, in openAuth
if ret is None:raise libvirtError(‘virConnectOpenAuth() failed’)
libvirtError: ソケットの ‘/var/run/libvirt/libvirt-sock’ への接続に失敗しました: 許可がありません

 

2. 対応内容

[email protected]enom:~# vi /etc/libvirt/libvirtd.conf

[email protected]:/etc/libvirt# diff libvirt.conf.def libvirtd.conf
88c88
< unix_sock_ro_perms = “0770”

> unix_sock_ro_perms = “0777”
98c98
< unix_sock_rw_perms = “0770”

> unix_sock_rw_perms = “0777”
101c101
< #unix_sock_dir = “/var/run/libvirt”

> unix_sock_dir = “/var/run/libvirt”

[email protected]:~# service libvirt-bin stop
libvirt-bin stop/waiting
[email protected]:~#
[email protected]:~# service libvirt-bin start
libvirt-bin start/running, process 4368
[email protected]:~#

 

デフォルトではソケットファイルが作られないので、
ソケットファイルを生成しつつotherに権限を与えてあげれば良いかと。

ただ、otherに権限与えるのがあまり好ましくない環境ではおすすめしません。
よくよく考えるとlibvirtdグループに実行ユーザ加えてあげればいいような・・・

Ubuntu 12.04 LTS で zfs その1

自宅で使っているHP Proliant MicroServerが一台余ったので、(二台ある)
zfs使ってNASにすることにしました。

構成はこんな感じ。

  • Server : HP Proliant MicroServer (N36L)
  • OS : Ubuntu 12.04 LTS
  • System Disk (ext4) : CFD CSSD-SM64NJ2
  • Storage Disk (zfs)  : WesternDigital WD30EZRX *2

今回はrootからzfsにするnativeな構成ではなく、
OSを余り物のSSDに入れてハードディスクはストレージ用の
パーテーションとして別途分ける感じの構成にしてみた。

手順は至って簡単。ゆとり世代の私でも問題ない。

1. python-software-propertiesをインストール

[email protected]:~# apt-get install python-software-properties

2. リポジトリを追加

[email protected]:~# add-apt-repository ppa:zfs-native/stable

3. aptリストの更新

[email protected]:~# apt-get update

4. zfsのモジュールをインストール

apt-get install ubuntu-zfs

これで準備は完了。
以下のコマンドで応答があればインストールは終わっているはずだ。

[email protected]:~# zfs
[email protected]:~# zpool status

ほらね?僕達ゆとり世代にもやさしい。

続いて zpool にディスクを追加してみよう。

(その2へつづく)

resolvconfd と dnsmasq と libvirt と unbound と私

※忘れそうなのでメモです。

私が会社で使っている作業用サーバはUbuntuのKVM上で動いているFreeBSDです。(ホストのUbuntuも使ってるけど)
気が向いたときにホストのapt-get update/upgradeをするのですが、たまにKernelのアップデートがくると
再起動をしなくてはいけないので、仕方なく再起動をしています。

この時点で resolv.conf を手書きで書き換えていたりすると、楽しいことが起こったりします。

Ubuntu12.04では resolv.conf  の管理を resolvconfd で行っていて、デフォルトではローカルで起動している
リゾルバ(dnsmasq) を参照するように、起動のたびに 127.0.0.1 を参照するように resolv.conf を書き換えてくれるという仕様になっています。

とても親切ですね。

私が仕事で使っている環境は同ホストで unbound を起動してキャッシュリゾルバとしても使用しているので、
dnsmasq が起動されると bind しているアドレス・ポートがかぶって unbound が起動しなかったりで
一筋縄には行かないのです。(dnsmasqの存在を意識していなかった)

ということで、「dnsmasq が邪魔なら dnsmasq を起動しなければ良い!」 という安直な考えに至り、dnsmasq を stop

[email protected]:/# /etc/init.d/dnsmasq stop
* Stopping DNS forwarder and DHCP server dnsmasq
…done.
[email protected]:/#

これで、安心だろ。
と、おもって KVM の FreeBSD (ゲスト)にログインするとネットワークがつながらない・・・
libvirt で仮想マシンを管理しているので、dnsmasq を切ってしまうとどうやら外に出られなくなるみたいだ(詳しくは調べてません)

「そうしたら  dnsmasq と unbound を共存させればいいんだろ?」という安直な考えに至り、 conf を編集

[email protected]:/# vi /etc/unbound/unbound.conf

server:
interface: 192.168.10.70

(略)

 

[email protected]:/# vi /etc/dnsmasq.conf

listen-address=127.0.0.1
bind-interfaces

これでデーモンを再起動すれば dnsmasq/unbound が共存できます。

ちなみに、前置きが長くなりましたが、ここからが本編です。
resolvconfd の挙動が良く分からなかったので今回はじっくり観察してみました。

Googleなんかで “ubuntu 12.04 resolv.conf” などと検索すると、
大抵のBlog記事は /etc/resolvconf/resolv.conf.d/ 以下のファイルを編集しろと書かれています。

[email protected]:/etc/resolvconf/resolv.conf.d# ls
base  head  original

ここで引っかかりました。
いくら編集して、resolvconfd/networking/server再起動しても  resolv.conf が思ったように書き換わらないので、
Ubuntuのマニュアルをよく読んでみた。

http://manpages.ubuntu.com/manpages/precise/man8/resolvconf.8.html

/etc/network/interfaces を編集すればよいことが判明。(ちゃんと書いてあるじゃん)
オフィシャルなマニュアルをちゃんと読まないと遠回りしてしまうんですね。

ということで  /etc/network/interfaces を以下のようにしてみた

auto br0
iface br0 inet static
address 192.168.10.70
network 192.168.0.0
netmask 255.255.0.0
broadcast 192.168.255.255
gateway 192.168.0.1
dns-nameservers 192.168.10.70 192.168.0.20 8.8.8.8
dns-domain hoge.com
dns-search fuga.net foo.com
bridge_ports eth0
bridge_stp off

iface eth0 inet manual

どうやら “dns-*” な行を読み取って resolv.conf を読みよってくれるようなので、
これでネットワークをリスタートして resolv.conf を見てみましょう。

[email protected]:/# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND — YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search choge.com fuga.net foo.com
[email protected]:/#

nameserver が 127.0.0.1 になっていますが、心配ありません。
dnsmasq がロードしている conf を参照すると以下のようになっています。

[email protected]:/# cat /var/run/dnsmasq/resolv.conf
nameserver 192.168.10.70
nameserver 192.168.0.20
nameserver 8.8.8.8

コレに気づかず30分ぐらい時間を無駄にしました。

ちなみに、 dnsmasq や unbound などのデーモンが起動していない(起動しない)環境では /etc/resolv.conf の
nameserver  は 127.0.0.1 ではなく、 /etc/networl/interfaces に書かれている dns-nameservers の値が明示的に入るようです。

親切というか、なんと言うか、今までの掟的なものが頭から離れないとハマること間違いなしですね。

IPv6 環境で ufw を使ってみた

我が家の回線は KDDI の au ひかりなんですが、
auひかりといえばネイティブな IPv6 環境を提供してくれるナウい回線なわけで、いろいろ遊べるんですね。
それで、今日は我が家で運用しているサーバに載っているWordpress に対してロシアからアタックを食らっていたので、
そろそろファイウォールの導入でもしようかと考え、思い立ったら吉日でさっそく ufw を使ってみました。

ufw についての詳細は割愛しますが、Ubuntu に採用されている簡易的なファイアウォールで、
ベースは iptables なのですが、簡単に使えるようにした wrapper 的なプログラムといったところです。

以下のオプションで簡単に設定ができてしまいます。
ゆとり世代の私には大変ありがたい。

wktk# ufw –help

Usage: ufw COMMAND

Commands:
enable                          enables the firewall
disable                         disables the firewall
default ARG                     set default policy
logging LEVEL                   set logging to LEVEL
allow ARGS                      add allow rule
deny ARGS                       add deny rule
reject ARGS                     add reject rule
limit ARGS                      add limit rule
delete RULE|NUM                 delete RULE
insert NUM RULE                 insert RULE at NUM
reset                           reset firewall
status                          show firewall status
status numbered                 show firewall status as numbered list of RULES
status verbose                  show verbose firewall status
show ARG                        show firewall report
version                         display version information

Application profile commands:
app list                        list application profiles
app info PROFILE                show information on PROFILE
app update PROFILE              update PROFILE
app default ARG                 set default application policy

たとえば、192.167.79.29というロシアのIPからの接続をすべて拒否したいときは

wktk# ufw deny from 192.167.79.29

といった感じでルールを追加できます。
ここについても詳しく述べられているサイトがほかにありますので割愛します。

wktk# ufw status
Status: active

To                         Action      From
—                         ——      —-
Anywhere                   ALLOW       Anywhere
Anywhere                   DENY        192.167.79.29

で、ここからが本題です。

この ufw ですが、ルールを入れた後に enable したら、自宅ネットワーク内からサーバへの疎通が一切取れなくなってしまいました。
なぜかグーグル先生に聞いてみたところ、どうやら答えは /etc/default/ufw というファイルにあるようでした。

wktk# vi /etc/default/ufw

# /etc/default/ufw
#

# Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback
# accepted). You will need to ‘disable’ and then ‘enable’ the firewall for
# the changes to take affect.
IPV6=no

ん?OS入れるとき v6 有効にしたままなのに、IPV6=no って・・・

IPV6=no を yes にしてあげたら無事に自宅内のLANからでも v6 でつなげるようになりましたとさ。

前置きが長かったですが、ご了承ください。

 

参考資料

Ubuntu Forums [ubuntu] ufw and ipv6  :http://ubuntuforums.org/showthread.php?t=1214543