Amazon S3 互換のMinioをちょっとだけ試す

Amazon S3 互換のMinioを少し試してみました.MinioはGo製でマルチプラットホーム(Linux/Windows/macOS/FreeBSD等)で動作します.

Minioダウンロード

いろいろな環境で動作します.Linux amd64だけでもDocker, Snap, 単一バイナリなどが選べます.
今回はお手軽にバイナリで試します.

minio.sha256sumのファイル名はminio.RELEASE.2018-02-09T22-40-05を見ているようなので目diffで…….(minio.ascminioを見てますね.)

$ wget https://dl.minio.io/server/minio/release/linux-amd64/minio
$ wget https://dl.minio.io/server/minio/release/linux-amd64/minio.sha256sum
$ cat minio.sha256sum
98cf1e082368e3f57f2be39dd49b1abffca4068e6d3e859f300ae93b4e5f6a5a minio.RELEASE.2018-02-09T22-40-05Z
$ sha256sum -c minio.sha256sum 
sha256sum: minio.RELEASE.2018-02-09T22-40-05Z: そのようなファイルやディレクトリはありません
minio.RELEASE.2018-02-09T22-40-05Z: FAILED open or read
sha256sum: 警告: 一覧にある 1 個のファイルが読み込めませんでした
$ sha256sum minio
98cf1e082368e3f57f2be39dd49b1abffca4068e6d3e859f300ae93b4e5f6a5a  minio
$ wget https://dl.minio.io/server/minio/release/linux-amd64/minio.asc
$ gpg --verify minio.asc
gpg: 署名されたデータが'minio'にあると想定します
gpg: 2018年02月10日 07時40分19秒 JSTに施された署名
gpg:                RSA鍵12C74390F9AAC728を使用
gpg: "Minio Trusted <trusted@minio.io>"からの正しい署名 [不明の]
gpg: *警告*: この鍵は信用できる署名で証明されていません!
gpg:       この署名が所有者のものかどうかの検証手段がありません。
 主鍵フィンガープリント: 4405 F3F0 DDBA 1B9E 68A3  1D25 12C7 4390 F9AA C728

実行権を付与します.

$ chmod +x minio

ダウンロードページや READMEにはamd64のしか載っていませんが,以下のあたりを見ると386, ARM, ARM64などもあります :)

minio USAGE

$ ./minio -h
NAME:
  minio - Cloud Storage Server.

DESCRIPTION:
  Minio is an Amazon S3 compatible object storage server. Use it to store photos, videos, VMs, containers, log files, or any blob of data as objects.

USAGE:
  minio [FLAGS] COMMAND [ARGS...]

COMMANDS:
  server   Start object storage server.
  gateway  Start object storage gateway.
  update   Check for a new software update.
  version  Print version.

FLAGS:
  --config-dir value, -C value  Path to configuration directory. (default: "/home/mk/.minio")
  --quiet                       Disable startup information.
  --json                        Output server logs and startup information in json format.
  --help, -h                    Show help.

VERSION:
  2018-02-09T22:40:05Z

Minioをサーバとして実行

ストレージに/media/mk/diskを指定して実行しています.

$ ./minio server /media/mk/disk
Created minio configuration file successfully at /home/mk/.minio

Drive Capacity: 4.5 GiB Free, 466 GiB Total

Endpoint:  http://192.168.2.200:9000  http://172.17.0.1:9000  http://127.0.0.1:9000
AccessKey: AUI0SRSWF5NOG1JLQNX6 
SecretKey: LJ3JI3+VR8aYQR/vCA9QjVkVF4xddkU76Bb1ZW84 

Browser Access:
   http://192.168.2.200:9000  http://172.17.0.1:9000  http://127.0.0.1:9000

Command-line Access: https://docs.minio.io/docs/minio-client-quickstart-guide
   $ mc config host add myminio http://192.168.2.200:9000 AUI0SRSWF5NOG1JLQNX6 LJ3JI3+VR8aYQR/vCA9QjVkVF4xddkU76Bb1ZW84

Object API (Amazon S3 compatible):
   Go:         https://docs.minio.io/docs/golang-client-quickstart-guide
   Java:       https://docs.minio.io/docs/java-client-quickstart-guide
   Python:     https://docs.minio.io/docs/python-client-quickstart-guide
   JavaScript: https://docs.minio.io/docs/javascript-client-quickstart-guide
   .NET:       https://docs.minio.io/docs/dotnet-client-quickstart-guide

この状態で http://localhost:9000/ にアクセスすると以下のような画面にアクセスできてファイルの閲覧やダウンロードが出来ます.
※同じネットワークからも見えちゃうので注意.

4ed69fd748a6d8ed2a68bb70536f0bb4d76972822dea5a2f9c55aaed99d70541

Minio Client(mc)

Minio Client(mc)というコマンドラインクライアントもあるそうなので試してみます.
#mcというとファイラーと名前が当ってしまいますね. -> Midnight Commander

例によってこの辺を見ると各種環境のものがあります.

$ wget https://dl.minio.io/client/mc/release/linux-amd64/mc
$ wget https://dl.minio.io/client/mc/release/linux-amd64/mc.sha256sum
$ wget https://dl.minio.io/client/mc/release/linux-amd64/mc.asc
$ sha256sum -c mc.sha256sum
sha256sum: mc.RELEASE.2018-02-09T23-07-36Z: そのようなファイルやディレクトリはありません
mc.RELEASE.2018-02-09T23-07-36Z: FAILED open or read
sha256sum: 警告: 一覧にある 1 個のファイルが読み込めませんでした
$ cat mc.sha256sum
7367d2e7e14aea6ef1928c75d5965e7124f8027254007ccf7c51cbd83ed73386 mc.RELEASE.2018-02-09T23-07-36Z
$ sha256sum ./mc
7367d2e7e14aea6ef1928c75d5965e7124f8027254007ccf7c51cbd83ed73386  ./mc
$ gpg --verify ./mc.asc 
gpg: 署名されたデータが'./mc'にあると想定します
gpg: 2018年02月10日 08時07分39秒 JSTに施された署名
gpg:                RSA鍵12C74390F9AAC728を使用
gpg: "Minio Trusted <trusted@minio.io>"からの正しい署名 [不明の]
gpg: *警告*: この鍵は信用できる署名で証明されていません!
gpg:       この署名が所有者のものかどうかの検証手段がありません。
 主鍵フィンガープリント: 4405 F3F0 DDBA 1B9E 68A3  1D25 12C7 4390 F9AA C728
$ chmod +x ./mc

mc USAGE

$ ./mc --help
NAME:
  mc - Minio Client for cloud storage and filesystems.

USAGE:
  mc [FLAGS] COMMAND [COMMAND FLAGS | -h] [ARGUMENTS...]

COMMANDS:
  ls       List files and folders.
  mb       Make a bucket or a folder.
  cat      Display file and object contents.
  pipe     Redirect STDIN to an object or file or STDOUT.
  share    Generate URL for sharing.
  cp       Copy files and objects.
  mirror   Mirror buckets and folders.
  find     Search for files and objects.
  stat     Stat contents of objects and folders.
  diff     List differences in object name, size, and date between folders.
  rm       Remove files and objects.
  events   Manage object notifications.
  watch    Watch for file and object events.
  policy   Manage anonymous access to objects.
  admin    Manage Minio servers
  session  Manage saved sessions for cp command.
  config   Manage mc configuration file.
  update   Check for a new software update.
  version  Print version info.

GLOBAL FLAGS:
  --config-folder value, -C value  Path to configuration folder. (default: "/home/mk/.mc")
  --quiet, -q                      Disable progress bar display.
  --no-color                       Disable color theme.
  --json                           Enable JSON formatted output.
  --debug                          Enable debug output.
  --insecure                       Disable SSL certificate verification.
  --help, -h                       Show help.

VERSION:
  2018-02-09T23:07:36Z

minioのurl, アクセスキー, シークレットキーを設定します.

$ ./mc config host add myminio http://192.168.2.200:9000 AUI0SRSWF5NOG1JLQNX6 LJ3JI3+VR8aYQR/vCA9QjVkVF4xddkU76Bb1Z
W84
Added `myminio` successfully.

lsしてみます.サブディレクトリは./mc ls s3 myminio/SUBDIRな感じで.

$ ./mc ls s3 myminio                                                                                               mc: <ERROR> Unable to list folder. The AWS Access Key Id you provided does not exist in our records.
[2015-10-14 19:34:12 JST]     0B ac100-simple-repart/
[2014-03-01 02:29:12 JST]     0B backup/
[2014-04-09 10:49:46 JST]     0B cubox-i/
[2016-03-10 13:04:52 JST]     0B flash-tmp/
[2015-10-14 19:34:48 JST]     0B image/
[2014-05-05 05:53:24 JST]     0B kobo/
[2015-10-14 19:34:26 JST]     0B nakasi-lmy47v/
[2014-02-28 00:14:16 JST]     0B opencocon.org/
[2017-12-09 02:28:42 JST]     0B pinebook/
[2017-03-01 19:49:58 JST]     0B raspifw/

多分しばらく前にサポートされたWinSCPやFileZilla Proでもアクセスできるのではないかと思います.

Let’s Encryptの更新に失敗する

最近はこんな感じでLet’s Encryptの証明書の更新を更新しているのですが今回失敗しました.
(DocumenteRootをFQDNにしている前提)

$ sudo /bin/sh -c "/usr/bin/find /etc/letsencrypt/renewal/*.conf -type f | /usr/bin/xargs /usr/bin/basename -s .conf | xargs -n1 -I{} /usr/bin/letsencrypt renew --webroot -w /var/www/{}/ -d {}"

こんなふうに怒られます.
(仕様が変わった?)

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Currently, the renew verb is capable of either renewing all installed certificates that are due to be renewed or renewing a single certificate specified by its name. If you would like to renew specific certificates by their domains, use the certonly command. The renew verb may provide other options for selecting certificates to renew in the future.

とりあえずはletsencrypt renewletsencrypt certonlyにしたら通りました.

$ sudo /bin/sh -c "/usr/bin/find /etc/letsencrypt/renewal/*.conf -type f | /usr/bin/xargs /usr/bin/basename -s .conf | xargs -n1 -I{} /usr/bin/letsencrypt certonly --webroot -w /var/www/{}/ -d {}"

これで更新できたと思ったら1つのドメインで失敗しています.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for files.matoken.org
Using the webroot path /var/www/files.matoken.org for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. files.matoken.org (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://files.matoken.org/.well-known/acme-challenge/Be7Aiai4UH9CDqacTaEZOMH4SxSQbtFqxFcPXcCtJEs: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>  
</head><body>
<h1>Not Found</h1>
<p"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: files.matoken.org  
   Type:   unauthorized
   Detail: Invalid response from
   http://files.matoken.org/.well-known/acme-challenge/Be7Aiai4UH9CDqacTaEZOMH4SxSQbtFqxFcPXcCtJEs:
   "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
   <html><head>
   <title>404 Not Found</title>
   </head><body>
   <h1>Not Found</h1>
   <p"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

ファイルをDoumentRootに置いてLet’s Encryptからアクセスされるのですがそこでそのファイルが見つからないと失敗しています.このドメインはhttpを設定していませんでした.
てことでapacheでRewriteの設定をしてあげると

RewriteEngine On
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

通りました.

$ sudo /usr/bin/letsencrypt certonly --webroot -w /var/www/files.matoken.org/ -d files.mato
ken.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for files.matoken.org
Using the webroot path /var/www/files.matoken.org for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0003_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0003_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/files.matoken.org/fullchain.pem. Your cert
   will expire on 2018-05-31. To obtain a new or tweaked version of
   this certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

certbotのversionがかなり古いですね…….

$ dpkg -l|grep -i certbot
ii  certbot                               0.10.2-1                          all          automatically configure HTTPS using Let's Encrypt
ii  python-certbot                        0.10.2-1                          all          main library for certbot

てことでbackportのものに入れ替え.

$ sudo apt remove certbot
$ sudo apt install python-certbot-apache -t stretch-backports
$ apt show certbot
Package: certbot
Version: 0.21.1-1~bpo9+1
Priority: optional
Section: web
Source: python-certbot
Maintainer: Debian Let's Encrypt <letsencrypt-devel@lists.alioth.debian.org>
Installed-Size: 53.2 kB
Provides: letsencrypt
Depends: python3-certbot (= 0.21.1-1~bpo9+1), python3:any
Suggests: python3-certbot-apache, python3-certbot-nginx, python-certbot-doc
Breaks: letsencrypt (<= 0.6.0)
Replaces: letsencrypt
Homepage: https://certbot.eff.org/
Download-Size: 20.4 kB
APT-Manual-Installed: no
APT-Sources: http://ftp.jp.debian.org/debian stretch-backports/main amd64 Packages
Description: automatically configure HTTPS using Let's Encrypt
 The objective of Certbot, Let's Encrypt, and the ACME (Automated
 Certificate Management Environment) protocol is to make it possible
 to set up an HTTPS server and have it automatically obtain a
 browser-trusted certificate, without any human intervention. This is
 accomplished by running a certificate management agent on the web
 server.
 .
 This agent is used to:
 .
   - Automatically prove to the Let's Encrypt CA that you control the website
   - Obtain a browser-trusted certificate and set it up on your web server
   - Keep track of when your certificate is going to expire, and renew it
   - Help you revoke the certificate if that ever becomes necessary.
 .
 This package contains the main application, including the standalone
 and the manual authenticators.

N: There is 1 additional record. Please use the '-a' switch to see it

てことでclientが古かったのであまり参考になら無さそうなメモでした.

Devuan ascii armhf(Raspberry Pi)で時計合わせ

Raspberry PiにはRTCが付いていません.なのでシステム停止すると時間情報が飛んでしまいます.fake-hwclockが設定されていたら前回停止時(に近い)時間がファイルに保存されていてその時間に設定されますが,停止時の時間はカウントされないので時間がずれます.ということでネットワークが有効な場合ntpを参照して時計合わせをしたいです.
最近のDebianやRaspbianはsystemdなのでtimesyncd.confでNTP serverを指定してtimedatectlコマンドで有効にする感じだと思うのですが(既定値でそうなっている),Devuanは脱systemdなディストリビューションなのでこの方法は使えません.

$ sudo vi /etc/systemd/timesyncd.conf
$ sudo timedatectl set-ntp true`

詳細はman timesyncd.conf, man timedatectl

ということでntpdateを入れてみました.

$ sudo apt install ntpdate
$ sudo ntpdate 192.168.1.102
$ grep -A1 -B2 ntp /etc/rc.local
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
  /usr/sbin/ntpdate 192.168.1.102
fi

長時間動かすならcrontabで定期的に設定したほうがいいかも?(若しくは何らかのntpd)

$ sudo -u root crontab -l|tail -2
@reboot /usr/sbin/ntpdate 192.168.1.102
3 3 * * *       /usr/sbin/ntpdate 192.168.1.102

追記)
このシステムはRaspbian stretchをDevuan asciiにdist-upgradeしたシステムなのでntpの設定がないだけかもしれません.Devuan asciiをクリーンインストールすれば必要ない設定かも(未確認)

自分用GNU socialのタイムラインの反映がとても遅くなって困る

自宅のPCでGNU social(nightly)を動かしているのですが,ふと気づくとタイムラインの最新が30分ほど前になっています.自分の投稿も他のMastodonインスタンスなどに反映されていません.
ログ(config.phpの$config['site']['logfile']で設定してあるもの)を見ると怪しそうなのはこの辺.

2018-02-18 22:46:31 LOG_ERR: [gnusocial.matoken.org:8923.6a16ed84 GET /api/statuses/public_and_external_timeline.json?since_id=312334&count=20] OpportunisticQueueManager: [mirror:Notice 221617] Exception (ServerException) thrown: '[SubMirror] DB_DataObject error []: DB Error: no such table'

DB Error: no such table?最近アップデートもプラグインの追加などもした覚えがないので関係あるかわかりません.連合からの投稿も次々届いているし,遅いながらもタイムラインは更新されているので捌ききれていない?とQueueDaemonを増やしてみました.

daemonを一旦停止して,

$ sudo -u www-data scripts/stopdaemons.sh 

config.phpに以下を追加,

$config['queue']['threads'] = 8;

再度daemonを実行

$ sudo -u www-data scripts/startdaemons.sh 

前(cpu coreから2threadsだった)から変わった感じがしません.vmstatを見ても特に負荷も上がっていないようです.

log levelを上げてみようとconfig.phpに以下を設定してみましたが上のエラーと同じものしか見当たりません.

$config['site']['logdebug'] = true;

mysqlcheck --auto-repairを試しにかけてみましたが変わらず.

そういえばpluginを追加したとき等にカスタムテーブルのチェックをしてくれるscript(checkschema.php)があったなと試してみました.

$ sudo -u www-data scripts/stopdaemons.sh 
$ sudo -u www-data php scripts/checkschema.php
Constraint checking Notice table...
* notice_reply_to_fkey (reply_to => notice.id)
        Found 2 notices with reply_to NOT IN notice.id, reseting...DONE.
* notice_repeat_of_fkey (repeat_of => notice.id)
* notice_profile_id_fkey (profile_id => profile.id)
PHP Warning:  fopen(/var/log/gnusocial.log): failed to open stream: ???????? in /export/data/www/gnusocial.matoken.org/lib/util.php on line 1853
PHP Warning:  fopen(/var/log/gnusocial.log): failed to open stream: ???????? in /export/data/www/gnusocial.matoken.org/lib/util.php on line 1853
  :
PHP Warning:  fopen(/var/log/gnusocial.log): failed to open stream: ???????? in /export/data/www/gnusocial.matoken.org/lib/util.php on line 1853
PHP Warning:  fopen(/var/log/gnusocial.log): failed to open stream: ???????? in /export/data/www/gnusocial.matoken.org/lib/util.php on line 1853
Ensuring no NULL values for foreign keys in QvitterNotification...DONE.
Ensuring no dead profile or notice IDs are stored in QvitterNotification...DONE.
$ sudo -u www-data scripts/startdaemons.sh 

これが当たりだったようでDB errorは消えてタイムラインの流速も戻りました.
原因は不明のままなのがちょっと気持ち悪いですが,バックアップから原因を探すのも面倒なので多分放置です…….

mysqlのdatadirを変更したらapparmorに怒られて起動しなくなった

ディスクの都合でmysqlのデータの置き場所を変更しました.
mysqldを停止して,データを移動して,シンボリックリンクも一応貼っておく.
/etc/mysql/mysql.conf.d/mysqld.cnfでdatadirを変更.

[mysqld]
datadir         = /export/data/var/lib/mysql

この状態でmysqlを起動するとこんな感じのエラーで起動しなくなってしまいました.

2018-02-17T16:12:54.184655Z 0 [ERROR] InnoDB: The innodb_system data file 'ibdata1' must be writable
2018-02-17T16:12:54.184718Z 0 [ERROR] InnoDB: The innodb_system data file 'ibdata1' must be writable
2018-02-17T16:12:54.184734Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2018-02-17T16:12:54.785643Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2018-02-17T16:12:54.786151Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2018-02-17T16:12:54.786272Z 0 [ERROR] Failed to initialize builtin plugins.
2018-02-17T16:12:54.786415Z 0 [ERROR] Aborting

該当ファイルは一見問題無さそうに見えます.

$ sudo ls -la /export/data/var/lib/mysql/ibdata1
-rw-rw---- 1 mysql mysql 102760448  2月 18 05:15 /export/data/var/lib/mysql/ibdata1
$ sudo -u mysql dd if=/export/data/var/lib/mysql/ibdata1 bs=10 count=1|od -xc
1+0 レコード入力
1+0 レコード出力
10 bytes copied, 9.8366e-05 s, 102 kB/s
0000000    2214    405b    0000    0000    0000
        024   "   [   @  \0  \0  \0  \0  \0  \0
0000012

何でだ?と思ったらkernel logにこんなログが.apparmorで引っかかっているようです.

Feb 18 00:35:26 micro kernel: [ 3569.631324] audit: type=1400 audit(1518881726.300:24): apparmor="DENIED" operation="open" prof
ile="/usr/sbin/mysqld" name="/proc/18795/status" pid=18795 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=114 ouid=114

/etc/apparmor.d/usr.sbin.mysqldでパスを変更します.

diff --git a/apparmor.d/usr.sbin.mysqld b/apparmor.d/usr.sbin.mysqld
index 2619e7d..adb8259 100644
--- a/apparmor.d/usr.sbin.mysqld   
+++ b/apparmor.d/usr.sbin.mysqld
@@ -46,16 +46,16 @@
   /usr/share/mysql/** r,  

 # Allow data dir access   
-  /var/lib/mysql/ r,
-  /var/lib/mysql/** rwk,  
+  /export/data/var/lib/mysql/ r,  
+  /export/data/var/lib/mysql/** rwk,

 # Allow data files dir access
-  /var/lib/mysql-files/ r,
-  /var/lib/mysql-files/** rwk,
+  /export/data/var/lib/mysql-files/ r,
+  /export/data/var/lib/mysql-files/** rwk,

 # Allow keyring dir access
-  /var/lib/mysql-keyring/ r,
-  /var/lib/mysql-keyring/** rwk, 
+  /export/data/var/lib/mysql-keyring/ r,
+  /export/data/var/lib/mysql-keyring/** rwk,

 # Allow log file access 
   /var/log/mysql.err rw,

この状態でapparmorを再起動して設定を反映してからmysqlを起動でOKでした.

$ sudo service apparmor restart
$ sudo service mysql start

この後iostat -xを眺めて大丈夫そうかなーって思ったのですがディスクアクセス音が大きくなったのでまた別の場所に移動するかも…….

環境

$ dpkg-query -W mysql-server
mysql-server    5.7.21-0ubuntu0.16.04.1
$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial
$ uname -m
x86_64

Debian sidのkernel.sysrqの値が変わった?

先日Debian sid amd64環境でprocpsの更新がありました.

$ apt show procps
Package: procps
Version: 2:3.3.12-4
Priority: important
Section: admin
Maintainer: Craig Small <csmall@debian.org>
Installed-Size: 712 kB
Provides: watch
Depends: libc6 (>= 2.15), libncurses5 (>= 6), libncursesw5 (>= 6), libprocps6, libtinfo5 (>= 6), lsb-base (>= 3.0-10), init-system-helpers (>= 1.29~)
Recommends: psmisc
Conflicts: pgrep (<< 3.3-5), w-bassman (<< 1.0-3)
Breaks: guymager (<= 0.5.9-1), open-vm-tools (<= 2011.12.20-562307-1)
Homepage: https://gitlab.com/procps-ng/procps
Tag: admin::monitoring, implemented-in::c, interface::commandline,
 interface::text-mode, role::program, scope::utility,
 uitoolkit::ncurses, use::checking, use::monitor,
 works-with::software:running
Download-Size: 251 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.jp.debian.org/debian sid/main amd64 Packages
Description: /proc ファイルシステムユーティリティ
 本パッケージは procfs を閲覧するためのコマンドラインおよび全画面のユーティ
 リティを提供します。procfs とは "擬似的な" ファイルシステムで、カーネルによ
 り動的に生成されます。カーネルのプロセステーブル内のエントリの状態に関する
 情報 (例えば、プロセスが稼働中、停止中、または "ゾンビ" である、など) が提
 供されます。
 .
 本パッケージには次のものが含まれます: free, kill, pkill, pgrep, pmap, ps,
 pwdx, skill, slabtop, snice, sysctl, tload, top, uptime, vmstat, w, watch。

更新に伴い/etc/sysctl.confの更新がありました.

設定ファイル '/etc/sysctl.conf'
 ==> これはインストールしてから (あなたかスクリプトによって) 変更されています。
 ==> パッケージ配布元が更新版を提供しています。
   どうしますか? 以下の選択肢があります:
    Y か I  : パッケージメンテナのバージョンをインストールする
    N か O  : 現在インストールされている自分のバージョンを残す
      D     : 両バージョンの差異を表示する
      Z     : 状況を調査するためにシェルを開始する
 デフォルトでは現在使っている自分のバージョンを残します。
*** sysctl.conf (Y/I/N/O/D/Z) [デフォルト=N] ? D

差分を見ると自分で編集した部分以外はコメントだけだったのですが,気になる項目が.

@@ -61,18 +61,13 @@

 ###################################################################
 # Magic system request Key
-# 0=disable, 1=enable all
-# Debian kernels have this set to 0 (disable the key)
-# See https://www.kernel.org/doc/Documentation/sysrq.txt
+# 0=disable, 1=enable all, >1 bitmask of sysrq functions
+# Debian kernels have this set to 438 which is the OR of:
+#  64 = enable signalling of processes
+#  128 = allow reboot/poweroff
+#  256 = allow nicing of all RT tasks
+#
+# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
 # for what other values do
-#kernel.sysrq=1
+#kernel.sysrq=438

Magic system request Keyの項目が以前は0 or 1で有効か無効化のみだったと思うのですが,細かく指定できるようになっているようです.

0 – disable sysrq completely
1 – enable all functions of sysrq
>1 – bitmask of allowed sysrq functions (see below for detailed function description):

てことでkernel.sysrq=438は16進数で0x1B6なので

$bc
obase=16
438
1B6

以下が有効ということのようです.

2 = 0x2 – enable control of console logging level
4 = 0x4 – enable control of keyboard (SAK, unraw)
16 = 0x10 – enable sync command
32 = 0x20 – enable remount read-only
128 = 0x80 – allow reboot/poweroff
256 = 0x100 – allow nicing of all RT tasks

無効になっているのは以下の項目.

8 = 0x8 – enable debugging dumps of processes etc.
64 = 0x40 – enable signalling of processes (term, kill, oom-kill)

kernel configを見るとこの項目になっています.少なくとも4.13.0-1〜4.14.13-1以降は同じみたい.

$ zgrep ONFIG_MAGIC_SYSRQ /boot/config-`uname -r`
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x01b6
CONFIG_MAGIC_SYSRQ_SERIAL=y

ということでコメントが実際のkernelの項目と同じになったということみたいなので動作は変わらないようです.

追記)

昔使い方を知りたくて調べたときに見つけた文章は@miurahrさん翻訳のものでした.その後 で本人に遭遇.

porgを一般ユーザで利用する

porgを一般ユーザで利用するメモ

一般ユーザで普通に使おうとするとログ保存場所の/var/lib/porgへの権限がないと怒られてしまう.

$ porg -D ~/.porg -lp program-0.10.61 make install
porg: /var/lib/porg: Permission denied

ログ保存ディレクトリを指定すると行ける.

$ porg -L ~/.porg -lp program-0.10.61 make install

manより

   -L, --logdir=DIR
          Base log  directory.  The  logs  for  the  installed  packages  are  saved  in  this  directory.  Default  is
          '/var/lib/porg', unless variable LOGDIR is set in the configuration file (type 'man porgrc' for more informa‐
          tion).

--PREFIX=${HOME}/usrみたいな時向けに

version等

$ porg -V
porg-0.10 (17 May 2016)
Written by David Ricart <http://porg.sourceforge.net>
$ dpkg-query -W porg
porg    2:0.10-1.1

講談社「コミックDAYS」Web版サービス開始

講談社のコミックDAYSのWeb版が今日からサービス開始!

ざっくりと

  • ヤングマガジン,モーニング,アフタヌーン,イブニング,Kiss,BE・LOVEの6誌が対象の定期購読サービス
  • 雑誌発売日の0時から読める(関東以外だとかなり嬉しい)
  • 購読期間は2ヶ月分2号分(最新号と前号が読める.週刊誌は2週分,月刊誌は2ヶ月分)
  • 月額720円
  • 月当たり200ポイントもらえてコミック(単話単位で購入可能)の購入に使える
  • 単話で購入した後差額でコミックが購入できる
  • アプリは3/1リリース予定
  • iOS/Android/Webどれでも購読可能

ということでとりあえず無料期間は試してみるつもり.

ちなみにモーニングにはDモーニングというサービスが以前からある.Dモーニングは月額500円(税込み)でモーニング(一部作者のものは読めなかったりDモーニング限定などがあって紙版と少し違う)が毎週発売日の0時から読めてこれも安いと思っていたのだけどさらに安い.ちなみにDモーニングだと契約期間中のバックナンバーは全ていつでも読めるし,(iOS/Android)デバイスにダウンロードしてオフラインで読むことも出来るのが便利.

類似サービスのマガジン☆WALKERはコミック誌以外にいろいろな雑誌(出版社複数)も読めて月額500円(税別).バックナンバーは2ヶ月分でそれ以前は読めない.(iOS/Android)デバイスにダウンロードしてオフラインで読むことも出来る.単純に雑誌の数はここが一番多いので読むものがあるなら一番オトク.

NextcloudのWeb Installer

最近13が出たNextcloudですが,先日自宅サーバのownCloudもNextcloudに移行しました.
その時気づいたのですが,インストールページにWeb Installerというものが増えていました.

20180214_22:02:05-30568

いつもはArchiveをダウンロードしてverifyして展開してセットアップという流れでしたが,これだとWeb Installer ScriptをダウンロードしてWebPublicに置いてアクセスすると以下のようなSetup Wizardがはじまり,Nextcloud本体をダウンロードして展開してくれます.

$ wget https://download.nextcloud.com/server/installer/setup-nextcloud.php
$ sudo -u www-data mv setup-nextcloud.php /var/www/

https://example.com/setup-nextcloud.php

20180131_08:01:38-11248

次の画面で導入ディレクトリを指定すると後はいつものセットアップウィザードが走ります.

20180131_08:01:54-11374

shellの使えないサーバなんかでは便利そうです.

ちなみにこのときownCloudから以下のような感じでデータ移行したのですが,数ユーザ,データ量50GB程度でしたが復号化暗号化ですごい時間かかりました.

  • ユーザの確認
    occ user:list
  • ownCloudで暗号化解除
    occ encryption:decrypt-all
  • rsync とかで owncloud/data/${USER}/files を nextcloud/data/${USER}/files にコピー
  • Nextcloudでファイルスキャン
    occ files:scan -p /${USER}/files ${USER}
  • Nextcloudで暗号化
    occ encryption:encrypt-all

この辺を見るとデータはそのまま移行できたようです…….

追記)

やっぱり簡単に移行できそう.

Btrfsでdfで空き容量があるように見えるのに容量が無いと言われてreadonlyにされてしまう

最近Btrfsで利用中にroにされてしまうという症状が起きます.
こんな感じで怒られてroになる.
dfは87%とかで未だ空きはあるように見える.
/に使ってるとこでremount,rwも効かず再起動しないと戻せず辛い.

[ 2196.878532] BTRFS: error (device dm-1) in btrfs_truncate_inode_items:4647: errno=-28 No space left
[ 2196.878537] BTRFS info (device dm-1): forced readonly
[ 2196.881248] BTRFS error (device dm-1): pending csums is 1241088

FAQだったようでここを参照しながら

別のsystemで確認してbtrfs fi balance start -dusage=5を叩いてみました.

$ sudo btrfs fi show
Label: none uuid: e54de82f-1fdb-4f9a-b529-0952b0ea3454
        Total devices 1 FS bytes used 465.89GiB
        devid 1 size 542.28GiB used 542.28GiB path /dev/mapper/x220--vg-root

$ sudo mount -o ro /dev/mapper/x220--vg-root /mnt
$ sudo btrfs fi df /mnt
Data, single: total=538.27GiB, used=462.41GiB
System, single: total=4.00MiB, used=80.00KiB
Metadata, single: total=4.01GiB, used=3.48GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
$ sudo btrfs fi balance start -dusage=5 /mnt
ERROR: error during balancing '/mnt': Read-only file system
There may be more info in syslog - try dmesg | tail
$ sudo mount -o remount,rw /mnt
$ sudo btrfs fi balance start -dusage=5 /mnt
Done, had to relocate 0 out of 546 chunks

しかしあまり変わらず暫く利用しているとまたエラーに.しかし今度はdisk fullと怒られるけどroにはならなかったです.以下のページによると,

This means the bigger the -dusage value, the more work balance will have to do (i.e. taking fuller and fuller blocks and trying to free them up by putting their data elsewhere). Also, if your FS is 55% full, using -dusage=55 is ok, but there isn’t a 1 to 1 correlation and you’ll likely be ok with a smaller dusage number, so start small and ramp up as needed.

ということで-dusage=90にしてみると結構空いた感じです.
上の方では別systemで起動して実行しましたが,オンラインでも大丈夫でした.但し処理中はかなり重くなります.そして処理に200分程かかりました.

$ sudo btrfs fi balance start -dusage=90 /
Done, had to relocate 186 out of 530 chunks
$ sudo btrfs fi show
Label: none  uuid: e54de82f-1fdb-4f9a-b529-0952b0ea3454
        Total devices 1 FS bytes used 446.08GiB
        devid    1 size 542.28GiB used 449.27GiB path /dev/mapper/x220--vg-root

この後数GBのデータを書いてみたり溜まっていたapt upgradeとかしてみましたが今のところ大丈夫そうです.
ちなみにこのfsがあるSSD(INTEL SSDSA2CW600G3)も長く使っているのでそっちも心配だったのですが,smartctl-t longしたり-aの以下のあたり見る感じでは未だ行けそう?

9 Power_On_Hours 0x0032 100 100 000 Old_age Always – 36565
228 Workload_Minutes 0x0032 100 100 000 Old_age Always – 2193912
232 Available_Reservd_Space 0x0033 100 100 010 Pre-fail Always – 0
233 Media_Wearout_Indicator 0x0032 095 095 000 Old_age Always – 0

#適当なとこでsecure eraseしておきたい…….