gami のすべての投稿

mssql-server on ubuntu@systemd-nsspawn on debian

mssql-server on linux 入れてみようと思ったら、さりげなくubuntuのみでdebian対応していない。
無理やり入れてみようと思ったけどいくつか依存関係が解決できなくてあきらめていた。

ふと思いついたのが仮想マシン上でやればできるんじゃないかと。

ついでに最近覚えたsystemd-nspawnでやってみることにした。

mkdir /var/lib/machines/mssql
cd /var/lib/machines/mssql
debootstrap –variant=minbase –arch=amd64 xenial mssql http://ftp.jaist.ac.jp/Linux/ubuntu/
chroot mssql
passwd # rootのパスワード変更
exit
systemd-nspawn –boot –machine mssql

でとりあえず立ち上がる(はず。いろいろ試しているので足りないものあるかも)

ネットワークはとりあえずhostと同じものを。できればブリッジしたいけどそれやるとホスト側のifaceがeth0からbr0になって色々めんどい。

あと、これを試しているのがxen上の仮想マシン上で更にsystemd-nspawnとかイミフなことしているので。

sources.listに以下を追加。

deb [arch=amd64] https://packages.microsoft.com/ubuntu/16.04/prod xenial main
deb [arch=amd64] https://packages.microsoft.com/ubuntu/16.04/mssql-server-2017 xenial main

これだけじゃダメで、libc++1とかなかったので、ubuntuのsource.listも main だけから main restricted universe multiverse に変更した。
main universeだけでもいいのかもしれない。
apt-key とか apt-transport-httpsとか必要だけど割愛。

apt-get install mssql-server mssql-tools

でいいはずだったのだが、sqlserverの初期化に失敗する。mssql-toolsのsqlcmdが起動できない。

terminate called after throwing an instance of ‘std::runtime_error’
what(): locale::facet::_S_create_c_locale name not valid

ここでずっと止まっていたのだが、straceとか頑張ってhackしたら、locale に en_US.UTF-8 がない為だったらしい。

追加したら動いた。MSSMSとかからも接続できた。

Windows10 Insider Preview 17063

Insider PreviewでWindows10が更新された

そしたらMicrosoft Edgeが起動しなくなった。
窓は出るがアクセスしてもしばらくするとタイトルバーに接続できませんでしたと出てタブが消えていく。
最終的にEdgeごと落ちる。

何ともならないのでEdgeの再インストールを試みる。
%USERPROFILE%\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe を消してどうのこうのというやつだ

そしたら同期ができなくなったので一度ローカルアカウントに戻して再度MicrosoftAccountに戻す手順をやってみる。

すると、ローカルアカウントにはなったのだが、再度MicrosoftAccountにしようとすると、認証画面がEdgeを使っているっぽく、入力できないまま落ちる。
これはEdge死んだな、Previewのバグだとか思っていたら、別のアカウントではしっかり動く罠。

どうせそろそろプロファイルが肥大化してきたので作り直すかということでまたしっかりはまった。

Excelマクロとかの都合上、C:\User\gami\OneDriveにAccessファイル置かないとダメな仕様なので、ホームディレクトリは何としてでもC:\Users\gamiにしないといけない。

今までみたいにC:\USers\gami をリネームして再ログオンすれば行けるだろうと思ったがなぜかうまくいかない。C:\Users\TEMPの一時プロファイルになる。

結論としてはすごく変なタイミングでC:\Users\gami\AppData\ 以下に何か作られてたせいで、こけていたらしい。
それに気が付く前にnet user /del gamiとかやっちゃったので必要なかったかどうかは闇の彼方。

gamiを完全にログアウトして再起動、AdministratorでログオンしてC:\Users\gamiを削除/リネーム、ここで再起動するとRapportとかがプロファイルになんぞ書き込むっぽい。ので、このままgamiでログオンすると正しくC:\Users\gami にプロファイルが作られた。

ここでEdgeを起動してみると、ブックマークとかもちゃんと同期で戻ってきた。
MicrosoftAccountも設定できた。
しかしパスワードを一旦変更してみたら、一旦どころか前回使ったのは使っちゃダメとか言われてあちこち設定しなおしに回る羽目になった。

これ、過去何回までダメなんだろう・・・

DoCoMo imap

DoCoMoのメールをimapで読む方法

前準備

まず、dアカウントでドコモメールを利用 できるようにしないといけない。
これやってなかったせいでかなり時間を無駄にした orz

どう設定するのが正解なのかよく分からんのだが、スマホからWiFi切ってモバイルデータ通信でMyDoCoMo行けば確実っぽい。
PCからMyDoCoMoログインしても設定が見つからなかった。

MyDoCoMoからメール・パスワードなどの設定 -> メール設定 -> dアカウント利用設定の確認/変更 から

dアカウントでドコモメールを利用 -> 利用する をチェック

WiFiで見に行くと最後でWiFi切って最初からやり直せ言われる orz 実に分かりにくいが一度設定すればいいだけで滅多にやらない設定だからこんなもんか

DoCoMoの説明によるとSSL(over SSL3.0)とあるがSSL3.0大丈夫なのか?

wanderlust on emacs

普通にwanderlust 起動してからgで
%INBOX:"user@docomo.ne.jp"/login@imap.spmode.ne.jp:993!

で受信ボックスが見れるか確認

見れたら ~/.folders に
%:"user@docomo.ne.jp"/login@imap.spmode.ne.jp:993!/

と書いておけば階層全部見れるようになる。

送信側はたぶんPCから送信しないので割愛

その他

Becky! とか Windows10 標準メーラーでは、そのまんま設定すれば動いたようだ。
最初に延々と失敗したのは最初のdアカウント設定してなかったかららしい。

これでちょっとはフォルダの整理とかできるかなと思ったが、DoCoMoメールはimapの階層化には対応していないっぽい。残念。

やっちまった

 色々systemをいじっていたら、起動時のプロセスがおかしくなっていたらしく、起動できなくなっていた。

 そのせいで家人の仕事に影響出しまくり

 申し訳ない

 多分、systemd-networkd.serviceが起動しなかった。
 1分30秒でタイムアウトするのだが、また再起動しようとして失敗する、の繰り返し。

 結局時間までに動かなくて、仕事に大きな迷惑をかけてしまった m(_ _)m

 多分、socket関係の依存にnetworkが紛れ込んでいたためだと思う。
 /etc/systemd/system/ の下の *network* ファイルの依存をとりあえず消して起動したら動いた。

 ちなみにこのサーバーはxenの仮想マシンなので、dom0にログインすればリモートからでもいじれる。
 これ自体は役に立ったパターンなのだが、こういう複雑なことをしているからコケやすい、のかもしれない。
 前から、kernel 4.4.xじゃないとうまく動かなくて、最近なぜか4.13.xで動いたのでそれでやっていたのだが、それでも変なタイミングで止まってしまう。
 どうもディスクに負荷をかけると死ぬっぽい。
 単に準仮想化したいだけなのでxenじゃなくてもいいので、dockerとかsystemd-nsspawnに置き換えたいのだが、いざ変えようとするとゲスト側もそれなりにいじらなくちゃいけなくて、そこがめんどい。
 特にネットワーク関係がめんどくて、ブリッジ自体はxenでもやっているのだが、nspawnだとeth0がhost0とかになるっぽくて、簡単に置き換えれそうにないので現状放置。

 ていうか今こんなことやっている暇がない日程なんだけどなぁ・・・
 忙しい時に限って忙しくなるマーフィーの法則を実感しつつとりあえず寝る。

journald-remote

 結局よくわからないままであるが何となく転送されたっぽいのでメモ

 今、rsyslogでsyslogを転送しているのだが、もういい加減にsystemd-journalに移行したい。
 でも転送方法がわからなくて色々やっていた。
 systemd-jounarl-remote.serviceとsystemd-jounal-upload.serviceとか使えばよいのはわかっていたのだが、なんかうまくいってなかった。

 受け取り側のサーバーにDNS名降っておく。syslog.daionet.gr.jpにしておく

 両方のマシンにsystemd-journal-remoteをインストール

sudo apt install systemd-journal-remote

 受け取り側で、
パッケージをローカル用にコピーして編集する。
 systemctl edit systemd-journal-remote.service とかでもできそうな気がしたんだけど、overrideであって書き換えには向かないっぽい。
 同じエントリが2つあると怒られてしまうので全部コピーして一部編集する。
# 直接/lib/systemd/system/を書き換えると、アップデートで全部消えるのでローカル用は/etc/systemdにコピーする仕様らしい

cp /lib/systemd/system/systemd-journal-remote.service /etc/systemd/system/
cp /lib/systemd/system/systemd-journal-remote.socket /etc/systemd/system/

/etc/systemd/system/systemd-journal-remote.service の [Service] 内の
ExecStart=/lib/systemd/systemd-journal-remote –listen-http=-3 –output=/var/log/journal/remote/
# –listen-https=-3 を –listen-http=-3にする
 httpsにしたかったけどローカルだし証明書面倒だしとhttpにしてしまうことにした。

/etc/systemd/system/systemd-journal-remote.socket の [Socket] 内の
ListenStream=[2001:0db8::1]:19532
BindIPv6Only=yes
# ユニークローカルアドレスにするとかFWで守るとかして適当に保護。
# ListenStream=syslog.daionet.gr.jp:19532 とかやったらエラーになった。IPアドレスじゃないとダメっぽい

 systemctl start systemd-journal-remote.socket
・ここは.serviceじゃなくて.socketを起動する。起動時有効にするのも.socket

送信側で、
/etc/systemd/journal-upload.conf

[Upload]
URL=http ://syslog.daionet.gr.jp:19532

systemctl start systemd-journal-upload.service

 これで受信側の/var/log/journal/remote にコピーされた。
 全部のログをコピーしようとして異常に時間がかかったりしたので、あれこれやってなんとか切り抜けた(ぉ

 と。2つのマシンからjournalをコピーできたのはいいのだが。
 見る方法がわからないというオチが(滝汗

 とりあえずjournalctl –merge _HOSTNAME=hoge で見れるっぽいのだが、なんだかなぁ。

 blog書きながら調べてたらどうもjournalはコピーして使うというよりも、systemd-journal-gatewaydを使ってリモートに読む、が正解っぽい。
 でも死んだときに手元にログ欲しかったりしないでもないんだけどなぁ。あとブラウザだとめんどい(ぉ

2017/11/16 追記
 systemctl edit でうまく編集できない件について

 ExecStartとかListenStreamが複数行あるのが問題だったのだが、空行入れると以前のがキャンセルされるらしい。
ので、override.confに

[Socket]
ListenStream=
ListenStream=[2001:0db8::1]:19532
BindIPv6Only=yes

と一旦キャンセルかけてから書けば良いっぽい。

 日本語マニュアル欲しい……