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