2023年1月9日月曜日

fluxbox のフォントが表示されない(ただの自分メモ)

なんかいろいろ疲れて全くブログは更新してないところで,自分のためにメモっておきたいことがあったのでたまには更新してみる。

自宅ノートの Fedora をバージョンアップしたら fluxbox の右クリックメニューのウィンドウは出るんだけど,その中の文字が何も表示されない現象にあって困ってた。

/usr/share/fluxbox/styles/*/theme.cfg にフォントの設定があるんだけど,デフォルトのフォント設定はこんな感じ↓

menu.frame.font:                                                sans-9:bold
menu.title.font:                                                sans-10:bold

会社の PC だと問題なく動いているので,入ってるフォントの差分を取ったら自宅の方は open-sans なるフォントが入ってることに気付いた。

これアンインストールしたら表示されるようになった。うーん、open-sans 入れた方が正しい設定な気もするんだが。。。もう面倒だからこれ以上追わない。

2021年8月12日木曜日

ドットファイルのワイルドカード on bash

ネット界隈だと bash においてカレントディレクトリ下のドットファイルをワイルドカードで持ってきたいという解決策として .??* が提案されていることが多いのだが、これだと「.a」みたいな「ドット」+ 1文字がひっかからないんじゃないかと。

 bash ならこれ↓が正解なんじゃないのかと? 

   .[!.]*


2020年8月22日土曜日

The apk for your currently selected variant is not signed.

Android Studio で,mock という名前の自前の Build Variant を作っったのだが,ビルドの際に以下のエラーが出る。

Error: The apk for your currently selected variant (app-mock.apk) is not signed. Please specify a signing configuration for this variant (mock).

 

Mock のための Build Variant なので署名とかいらないし。取り急ぎ build.gradle で以下のように debug 用の署名を参照させることで解決。正しい方法かどうか知らんが。

     buildTypes {
          :
        mock {
             :
            signingConfig signingConfigs.debug
             :
        }

 

2020年8月10日月曜日

2020年7月19日日曜日

Intel AMT を SSL 化したくて MeshCommander 使ったら一発だった件

昨今の COVID-19 騒動によりめっきり自宅でしか仕事をしなくなったので,この環境を整えるべく自宅内仕事検証用サーバ( hp z840 )のコントロールをどこからでもリモートで可能にしようと思い立つ。

手段としては,WoL だとどこかに常時起動のマシンが必要となり,私の自宅環境のポリシー (少しでも火事の危険があるものは排除)としては許し難いので,Intel AMT を使うことに。

しかし,単純に MEBX から設定しただけだと SSL の設定が出来ず,これじゃ外からコントロールするのも不安だなぁと思っていて調べたところ MeshCommander なんていう素晴らしいソフトを発見。これを使うと一発で SSL 設定可能だった。MeshCommander は,一言で言うと AMT のクライアントで,動作的には Node.js を使ったローカルの Web アプリになっている(WIndows には専用のクライアントバイナリ版があるみたいだけど,それ以外の環境では Node.js 版を使ってね的な代物)。


以下は SSL 有効化の作業メモ。
  1. MeshCommander のインストール
    $ npm install meshcommander
  2. MeshCommander 起動
    $ node node_modules/meshcommander
    MeshCommander running on http://127.0.0.1:3000.
  3. 上記のように node コマンドで起動すると接続用 URL が表示されるので,そこに Web ブラウザからアクセスする。
  4.  コントロールするサーバの追加
    画面上の [Add Computer] をクリックして適当にコントロールするサーバの情報を入力して [OK]。

  5. コントロールするサーバに接続
    トップ画面には追加したサーバが表示されているはずで,その右側に[Connect] ボタンがあるのでそれをクリックするとサーバに接続される。
  6. SSLサーバ証明書の発行と登録
    サーバに接続したら,左側のメニュから [Security Settings] をクリックし,[Issue Certificate] で適当に情報を入力。
  7. SSL 接続の設定
    上記の[Security Settings]の画面のまま,上部に [Remote TLS security] という欄があり,そこが Disabled になっているはずなのでこれをクリック。

    [Certificate] で先ほど作成した証明書を選び,[Security] で適当な値を選ぶ。私は[Server-aut, non-TLS allowed]を選択して外からは SSL(16993) ,内部からはどっちでも(16992, 16993) 接続できるような運用にしようと思っている。
  8. これでブラウザから https://<AMTアドレス>:16993/  にアクセスすると,https 経由で AMT の設定ができるようになった。もちろんこのまま MeshCommander の localhost:3000 で作業を継続しても良い。

2020年7月15日水曜日

"git push -f" failed with "You are not allowed to force push code to a protected branch on this project" on GitLab

I would like to push my git branch by compulsion to my GitLab remote repository, but I couldn't do it with the following error.

$ git push -f
 : (snip)
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 8 threads
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 3.22 KiB | 3.22 MiB/s, done.
Total 9 (delta 0), reused 8 (delta 0)
remote: GitLab: You are not allowed to force push code to a protected branch on this project.

Resolution:
Do the following procedure on the web page of your GitLab repository .

1. [Settings] -> [Repository] -> [Protected Branches]
   Push "Expand " button

2. If  a branch is protected, you must see "Unprotect" button. Pushing the "Unprotect" button allows you to force commit.

2020年6月27日土曜日

the container name "xxxx" is already in use by "XXXX....." You have to remove that container to be able to reuse that name.: that name is already in use

手元の OSP (16.0) で galera-bundle-0 が上がらない。昨晩ホストをブッちん切りしたせいだろう。


#pcs status
   : (snip)
 Container bundle set: galera-bundle [cluster.common.tag/rhosp16-openstack-mariadb:pcmklatest]
   galera-bundle-0      (ocf::heartbeat:galera):        Stopped
   galera-bundle-1      (ocf::heartbeat:galera):        Slave controller-1
   galera-bundle-2      (ocf::heartbeat:galera):        Slave controller-2
   : (snip)

podman の galera 見てみる。
# podman ps --all | grep galera
#

いない。

ログ見てみる。
# grep galera-bundle /var/log/messages
   : (snip)
Jun 27 01:36:36 controller-0 podman(galera-bundle-podman-0)[6986]: ERROR: Error: error creating container storage: the container name "galera-bundle-podman-0" is already in use by "dc7e73548aefc2af4193c5a1b34210f45866e6d260b55f65e0a7b6a487fb767d". You have to remove that container to be able to reuse that name.: that name is already in use
   : (snip)
なんか残っちゃったみたいだ。
しかし podman ps --all にはこんなのいないし。

どうやら  /var/lib/containers/storage/overlay-containers/containers.json にこの ID が存在していた。

# cat /var/lib/containers/storage/overlay-containers/containers.json | python -m json.tool  | less
  :
 {
        "id": "dc7e73548aefc2af4193c5a1b34210f45866e6d260b55f65e0a7b6a487fb767d",
        "names": [
            "galera-bundle-podman-0"
        ],
        "image": "4eec1ff919b6164424d15a41a29dec83f812494966ffa54b70e853ffce7a5563",
        "layer": "c951ce8b56b16ef03855d5c19c5c701bc808baee64bc4a094f4374dfc004c34e",
        "metadata": "{\"image-name\":\"undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-mariadb:20200416.1\",\"image-id\":\"4eec1ff919b6164424d15a41a29dec83f812494966ffa54b70e853ffce7a5563\",\"name\":\"galera-bundle-podman-0\",\"created-at\":1593167005}",
        "created": "2020-06-26T10:23:25.985899627Z",
        "flags": {
            "MountLabel": "system_u:object_r:container_file_t:s0:c560,c687",
            "ProcessLabel": "system_u:system_r:container_t:s0:c560,c687"
        }
    }, 
おぉ、、、
このストレージを消す。
# podman rm --storage dc7e735
dc7e735

消えた。 その後 pcs cluster start したら直った。よかた。

2020年6月2日火曜日

cannot enable nested-kvm with 'kvm_intel': Input/output error

# modprobe kvm_intel
modprobe: ERROR: could not insert 'kvm_intel': Input/output error

Resolution:

Modify a value of the "mode" attribute of <cpu> element to 'host-passthroug' like:
  <cpu mode='host-passthrough' check='full'>

2020年5月21日木曜日

libvirt guest CPU doesn't match specification: missing features: hle,rtm

error: Failed to start domain mydomain
error: operation failed: guest CPU doesn't match specification: missing features: hle,rtm


1. virsh edit mydomain
2. add the following elements to <cpu></cpu> element.
 
  <feature name="rtm" policy="disable">
  <feature name="hle" policy="disable">

3. virsh start mydomain

2020年1月27日月曜日

2020年1月22日水曜日

Firefox で 127.0.0.1 や localhost へのアクセスを Proxy 通したい

Firefox は,network.no_proxies_on に何も設定されていなくてもデフォルトで localhost やら 127.0.0.1 の通信を Proxy 通さないようにしている模様。

なので例えば Firefox に Socks Proxy  を設定して,その Socks Proxy のサーバ上の 127.0.0.1 で Listen している Web サーバなんかがあったときにそれにアクセスできないことになる。

この仕様どうなの?とは思うが、回避策は about:config で以下を設定。

network.proxy.allow_hijacking_localhost = true

2019年12月19日木曜日

firewall-cmd --set-log-denied=all してるのにログ吐かない!

標題の件は単に rsyslog の設定が足りない。

/etc/rsyslog.d/firewalld_block.conf を以下の内容で作成して rsyslog を再起動

:msg,contains,"_DROP" /var/log/firewalld_block.log
:msg,contains,"_REJECT" /var/log/firewalld_block.log
& stop

2019年4月14日日曜日

Samba4.8 における idmap からのユーザ毎ホームディレクトリパスに苦しむ(回避策のみで解決せず)

何年ぶりかで Samba(Samba 4.8 on CentOS 7) のファイルサーバ構築をやってるのでメモ。AD と LDAP が混在したような環境の中で,あるユーザが UNIX からも Windows からも自身の同じホームディレクトリにアクセスしたいっていう大学とかにはよくある構成(今回のこの Samba はドメインコントローラの役割は担わない)。

設定はほぼ終えた。が,一点困っているのは,上記のような構成において[homes] セクション内の %H 変数で得られるホームディレクトリのパスが template homedir ディレクティブの設定に固定されてしまうということ。今回はユーザ毎にホームディレクトリのパス形式が違うのでこれだと困る。なので NSS から取得できる値にしたい(getpwnam()で取れるやつ)。LDAP の homeDirectory 属性に設定されているやつでも良い。

しかし,顧客要件から設定は security = ads が前提。この場合 Samba 4.8 からは winbind 必須とのこと(Samba 4.8 のリリースノート参照)。idmap_nss と idmap_rfc2307(LDAPをバックエンドにする) を試したが、どちらも sid-uid のマッピングは成功するものの、ホームディレクトリは template homedir の値になってしまう。どうも winbind はマッピングに関連する属性(uid, uidNumber, cn , gidNumber等)しかバックエンドから取得せず,それ以外は自前で処理(template xxxxから)してしまう仕様ようだ。Web には idmap_rfc2307 なら出来るという情報もちらほらあるが,少なくとも CentOS 7.6 上の Samba4.8.3 では無理なようだ。

証拠をつかもうと samba-4.8.3-4.el7 のソースを見た。すると以下のようなので,根本解決は Samba のソース改変しか無いと思われる。Workaround としては template homedir で表現可能なように,ホームディレクトリのシンボリックリンクを作成するくらいしか無いのではないか。

winbindd の getpwnam() の定義↓
source3/winbindd/winbindd.c:
           :
    578         { WINBINDD_GETPWNAM, "GETPWNAM",
    579           winbindd_getpwnam_send, winbindd_getpwnam_recv },
           :

winbindd_getpwnam_send() の中で wb_lookupname_send() のコールバックとして winbindd_getpwnam_lookupname_done() を定義↓
source3/winbindd/winbindd_getpwnam.c:

           :
     37 struct tevent_req *winbindd_getpwnam_send(TALLOC_CTX *mem_ctx,
     38                                           struct tevent_context *ev,
     39                                           struct winbindd_cli_state *cli,
           :
     80         subreq = wb_lookupname_send(state, ev,
     81                                     state->namespace,
     82                                     state->domname,
           :
     88         tevent_req_set_callback(subreq, winbindd_getpwnam_lookupname_done,
     89                                 req);
     90         return req;
     91 }
           :

winbindd_getpwnam_lookupname_done() で wb_getpwsid_send() をコール↓
source3/winbindd/winbindd_getpwnam.c:

           :
     93 static void winbindd_getpwnam_lookupname_done(struct tevent_req *subreq)
     94 {
           :
    107         subreq = wb_getpwsid_send(state, state->ev, &state->sid, &state->pw);
           :


wb_getpwsid_send() で wb_queryuser_send() をコール↓
source3/winbindd/wb_getpwsid.c:

           :
     34 struct tevent_req *wb_getpwsid_send(TALLOC_CTX *mem_ctx,
     35                                     struct tevent_context *ev,
           :
     56         subreq = wb_queryuser_send(state, ev, &state->sid);
           :


wb_queryuser_send() で wb_sids2xids_send() のコールバックとして wb_queryuser_got_uid() を定義↓
source3/winbindd/wb_queryuser.c:
           :
     39 struct tevent_req *wb_queryuser_send(TALLOC_CTX *mem_ctx,
     40                                      struct tevent_context *ev,
     41                                      const struct dom_sid *user_sid)
     42 {
          :
     63         subreq = wb_sids2xids_send(
     64                 state, state->ev, &state->info->user_sid, 1);
     65         if (tevent_req_nomem(subreq, req)) {
     66                 return tevent_req_post(req, ev);
     67         }
     68         tevent_req_set_callback(subreq, wb_queryuser_got_uid, req);
     69         return req;
     70 }
           :

wb_queryuser_got_uid() の中では wbint_userinfo の homedir 要素に lp_template_homedir() を設定↓
source3/winbindd/wb_queryuser.c:
           :
     72 static void wb_queryuser_got_uid(struct tevent_req *subreq)
     73 {
           :
    106         info->homedir = talloc_strdup(info, lp_template_homedir());
           :
winbind においてホームディレクトリを設定しているのは上記箇所のみと思われる(見落としあったらどなたかご一報を)。 この lp_template_homedir() はおそらく source3/param/loadparm.c の以下から得られる値なので,idmap からの NSS getpwnam() や LDAP (RFC2307) homeDirectory の入る余地は無いと思われる。
source3/param/loadparm.c :
           :
    797         lpcfg_string_set(Globals.ctx, &Globals.template_homedir,
    798                          "/home/%D/%U");
           :

2018年12月5日水曜日

ldap.cidict.cidict

何年前の話してるんだよと言われそうだが、python-ldap で search_s とかで返ってくるディクショナリが case-insensitive じゃないてことで、わざわざ key(属性名)を lower() して reduce() で別のディクショナリ作って in とかで存在確認したりしてたとかもう誰にも言えないけど自分への戒めでここにメモっておきたい。

ldap.cidict.cidict(result[0][1]) で case-insensitive なディクショナリで返してくれるっていや、ホント知らなかった。ググっても意外と少ない。例えば以下のように objectClass の C が大文字でも小文字でも cidict した後なら in で存在チェックできる。

>>> 'objectclass' in ret[0][1]
False
>>> 'objectClass' in ldap.cidict.cidict(ret[0][1])
True

2018年9月28日金曜日

NGINX の proxy_pass のちょっとだけメモ

NGINX の proxy_pass で GET リクエストがどうなっちゃうのかいつもわからなくなるのでメモ。

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

まぁ全ては上記の NGINX に書いてあるんだけど、ここでは前方一致のやつだけ。

  • proxy_pass に URI が含まれる場合
  • location /name/ {
        proxy_pass http://127.0.0.1/remote/;
    }
    上記の NGINX ドキュメントページにおける「URI」という用語はどうも NGINX における $uri と同じで、ホスト名より後ろの文字列のようだ。上記例だと /remote/ という部分と思われる。

    この場合は、normalized URI (URI のデコード後: // を / にしたり %xx をデコードしたり)の location に定義した部分に一致する箇所を、proxy_pass て定義した URI 部分に置き換えて後ろのサーバに渡す模様。上記設定例の場合は例えば以下のようになる。
    http://www.example.com/name/foo?bar=baz

    http://127.0.0.1/remote/foo?bar=baz
    (/name/ を /remote/ に置き換えて GET リクエストはそのまま)

  • proxy_pass に URI が含まれない場合
  • location /some/path/ {
        proxy_pass http://127.0.0.1;
    }
    上記 NGINX ドキュメントには、proxy_pass に定義された値がホスト名部分で終わっちゃう場合は request uri ($request_uri)をそのまんま後ろのサーバに渡すって書いてある(または完全な normalized URI = $uri)。

    つまり上記設定例の場合は以下のような感じ。
    http://www.example.com/some/path/foo?bar=baz

    http://127.0.0.1/some/path/foo?bar=baz
    (ホスト名の後ろからはそのまま)

  • proxy_pass で変数を利用している場合
  • location /name/ {
        set myhost myhost.example.com;
        proxy_pass http://$myhost/;
    }
    この例のように proxy_pass 内で変数を利用してしまうと proxy_pass に指定した値のまま後ろのサーバに渡してしまう。つまり:
    http://www.example.com/name/foo?bar=baz

    http://myhost.example.com/
    (とにかく proxy_pass で指定したものしか渡さない)
    もしリクエストを渡したい場合、proxy_pass は以下のようにすれば良いだろう。
    proxy_pass http://$myhost$request_uri;

2018年9月20日木曜日

Dockerfile の EXPOSE もしくは docker run --expose の意味

どこのサイトとは言わないが、docker の EXPOSE について誤った情報が蔓延しているような気がしてならない。

そのサイトは docker0 で繋がっているコンテナ同士の通信のために EXPOSE が必要と書いている。つまり EXPOSE しないと他のコンテナからそのポートにアクセスできないということを言っている。

しかし Dockerfile に EXPOSE なんて書かなくても(docker run で --expose を与えなくても)、あるポートを listen しているコンテナに対して他のコンテナから接続することは可能だ。

嘘だと思うなら以下のような Dockerfile から作ったイメージを --expose せずに docker run して、他のコンテナから「nc -vz <相手> 8080」でもしてみるといい。普通に connected になるはず。
FROM fedora:28
RUN dnf install -y nc
ENTRYPOINT ["/usr/bin/nc", "-kl", "8080"]

私の EXPOSE の理解は以下。間違ってたらコメント等で指摘ください。

EXPOSE で指定されたポートは docker run に -P (--publish-all) を付与した際の対象ポートとなる。つまりコンテナ内のポートを -P でホストの任意ポートにマッピングしたい場合にEXPOSE でポートを明示する必要がある。

2018年8月30日木曜日

curl で Proxy Protocol

NGINX で proxy_protocol を設定しちゃうと、curl なんかのクライアントから直接 NGINX のサーバにアクセスできなくなっちゃって辛い。
検証やテストなんかのときに応答を確認したいのに、上段のロードバランサ等を介さなくちゃならないのは非常に辛い。
そこで curl に Proxy Protocol オプションが無いかなと探してたらありました。7.60.0 からの実装だそうです。


--haproxy-protocol
(HTTP) Send a HAProxy PROXY protocol v1 header at the beginning of the connection. This is used by some load balancers and reverse proxies to indicate the client's true IP address and port.
This option is primarily useful when sending test requests to a service that expects this header.
Added in 7.60.0.

Fedora はまだ追いついてないや(7.59.0)。バックポートもされてない。


2018年8月25日土曜日

fcitx-mozc for Fedora 28

Fedora Copr で fcitx-mozc を build してみました(fedora-28-x86_64 のみ)。

https://copr.fedorainfracloud.org/coprs/ryohayakawa/fcitx-mozc/

よろしければどなたか使っていただけるとうれしかったり。不安な方は src.rpm 見てみて下さい。怪しいことはしてません。

まぁそのうち epel とか Fedora 29 の chroot もやろうかと。


2018年8月6日月曜日

最近の Fedora でマウスが速い

Fedora 27 にアップデートした頃からだったか、マウスの動きがぴゅんぴゅん速くなってしまい年寄りには結構厳しい状態に...仕方ない、xset m でチョチョイと、、、あれ?遅くならない????

と、その後忙しさにかまけて調べず我慢してそのまま使っていたが、最近会社 PC を X1 Carbon 6th にして Fedora 28 を入れていて良い機会なのでこれを直すことに。

最近の Fedora は Wayland がデフォルトのようだが、私は未だに自分の .xinitrc を設定して startx から起動するって流れで Xorg から抜けきれない老人である。しかし Xorg でも libinput というナウな入力デバイスのドライバが主流のようで、Fedora 28 でも /usr/share/X11/xorg.conf.d/40-libinput.conf にデフォルト設定として定義されている。

この libinput だが、アクセラレーションのモードとして adaptive と flat があり、adaptive の場合 xset m が効かないらしい。このモードは libinput コマンドの list-devices オプションで確認できる。adaptive がデフォルトとのこと。

$ sudo libinput list-devices
   :
Device:           TPPS/2 Elan TrackPoint
Kernel:           /dev/input/event15
Group:            10
   :
Accel profiles:   flat *adaptive
Rotation:         n/a

xset が効かないとなるとどうやって,,, ということでググって xinput でやるべしということがわかった。まず、マウスのデバイス名の確認。

$ xinput --list --short
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                  id=4    [slave  pointer  (2)]
⎜   ↳ Synaptics TM3288-011                        id=12    [slave  pointer  (2)]
⎜   ↳ TPPS/2 Elan TrackPoint                      id=13    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]

X1 Carbon の赤ポチは「TPPS/2 Elan TrackPoint」という名前のようで、この設定情報を見てみる。

 $ xinput --list-props "TPPS/2 Elan TrackPoint"
Device 'TPPS/2 Elan TrackPoint':
    Device Enabled (146):    1
    :
libinput Accel Speed (301):    0.000000
    :
この「libinput Accel Speed」を -0.5 くらいに修正してみる。
$ xinput --set-prop "TPPS/2 Elan TrackPoint" "libinput Accel Speed" -0.5


おぉ、遅くなったぞ。良かった。これを .xinitrc に書いておこう。