2018年7月8日日曜日

Android Studio で java.lang.ClassNotFoundException: android.view.View$OnUnhandledKeyEventListener

Android Studio の Design がまともに動かずコンポーネントを配置してもそれが Blueprint 上で見えない...んで以下のエラーが発生してる状態。

java.lang.ClassNotFoundException: android.view.View$OnUnhandledKeyEventListener

どうも SDK 28 の問題らしく 27 にしたらエラーが無くなった。以下の情報参照。

https://stackoverflow.com/questions/50856622/failed-to-find-style-coordinatorlayoutstyle-in-current-theme-in-android-studio

Change the android{ in "build.gradle" in app file
compileSdkVersion 28 to compileSdkVersion 27
targetSdkVersion 28 to targetSdkVersion 27
also, try to change implementations like
implementation 'com.android.support:appcompat-v7:28.0.0-alpha3' to
implementation 'com.android.support:appcompat-v7:27.1.1'

2018年6月21日木曜日

2018年5月17日木曜日

OID が英字って

とある 389 Directory Server 系の LDAP サーバの中を調査しているのだが、どうも OID が英文字列で構成されているパターンがある模様。スキーマ定義を見るとこんな感じ。

attributeTypes: ( foo-oid NAME 'foo' DESC ....)
objectClasses: ( bar-oid NAME 'bar' SUP top STRUCTURAL...)
名前に「-oid」とかついている。

OpenLDAP では OID Macro で oid のマクロを定義できるので 389 でもそういうのがあるんだろうと探し回ったが今のところ見当たらない。古いが以下のドキュメントを発見。

https://www.centos.org/docs/5/html/CDS/ag/8.0/Extending_the_Directory_Schema-Managing_Object_Classes.html

The object identifier of the attribute. An OID is a string, usually of dotted decimal numbers, that uniquely identifies an object, such as an object class or an attribute. If an OID is not specified, the Directory Server automatically uses object-class_name-oid. For example, if the object division is created without supplying an OID, the Directory Server automatically uses division-oid as the OID.
どうも OID が指定されていないと勝手に名前に -oid をつけてそれで良しにしてしまうらしい。OID が無い時点でエラーにして欲しいんだが... 管理 GUI でスキーマ作ったりするとそうなってしまうんだろうか?とりあえず以下のようなお勧めできない系の警告も記されていた。もしかしたら今はそんな仕様は廃止されているのかもしれない。

Using an alphanumeric OID such as division-oid is deprecated and strongly discouraged because it will lead to interoperability problems. Red Hat strongly encourages that you request your own OID prefix from IANA (Internet Assigned Number Authority).
 


2018年4月16日月曜日

libvirt の仮想マシン(qcow2)で root パスワードがわからなくて苦しんでる人へ

libvirt (KVM 利用)上で複数台の CentOS7 仮想マシンのインストールをスクリプトで自動化したのはいいのだが、動的にキックスタート定義ファイルの ks.cfg を作るところで root のパスワードがグチャグチャになって virsh console からもログインできない状態に...
virt-viewer を使えない環境なのがさらに致命的。

まぁスクリプトだから最初からまるごと仮想マシンを作り直せば良いんだけど、せっかく作ってあるのでそれを直すことにした。

single user mode でパスワードをリセットしちゃえばいいやと簡単に考えてたら、virsh console から Grub に入るのが結構面倒。時間もあまり無く、virt-viewer も使えない環境ということで、仕方ないので qcow2 のイメージをホストでマウントして /etc/shadow を直すという荒業?を行うことにした。とりあえず仮想マシンは virsh destroy でも何でもいいので停止しておく。

 http://blogger.fastriver.net/2014/06/qcow2.html に書いたがおさらいしておく。 guestmount というコマンドで qcow2 がローカルマウントできる。これを使うためにホストに libguestfs-tools を yum でインストール。
# yum install libguestfs-tools
したらホストで以下コマンドで、qcow2 ファイルをマウント。今回仮想マシンのホスト名が「client2」というやつの復旧をしたかったので以下のようなコマンドになってるけど、まぁ環境に合わせて適宜修正を。あ、あと以下ではマウントポイントが /mnt/tmp ってことで。


guestmount -a /var/lib/libvirt/images/client2.qcow2 -m /dev/centos_client2/root /mnt/tmp

マウントしたら /mnt/tmp/etc/shadow を修正する。具体的には root の 2 フィールド目を $6$ (crypt-sha512)のハッシュに変換。このハッシュは別のマシンのパスワードがわかってるユーザのやつそのまま持ってきてもいいし、以下の python ワンライナーでも作れる。
python -c 'import crypt; print crypt.crypt("適当なパスワード", "$6$適当なsalt")'
あとは、/mnt/tmp/etc/selinux/config も修正して SELinux を一時的に無効にする(これやらないと初回ログインできない)。終わったらアンマウント umount /mnt/tmp/ 。

最後に仮想マシンを起動して、virsh console からアクセスして root の ID/パスワードを入力すると正常にログインできるはず。/etc/selinux/config で「SELINUX=enforcing」に戻すのを忘れずに。




2018年3月22日木曜日

389 Directory Server Admin コンソールからの Start/Stop Directory Server

個人的には全く無問題なのだが、ちょっとワケありで標題の件についてうまく行かない場合があることに気付いた。

389 Directory Server Admin コンソールから「Start Directory Server」または「Stop Directory Server」のボタンをクリックして dirsrv のデーモンをコントロールしようとすると、SELinux Enforcing な環境で以下のエラーが /var/log/dirsrv/admin-serv/error に記録される。

Failed to get load state of dirsrv@xxxxx.service: Access denied
Failed to stop dirsrv@xxxxx.service: Access denied
See system logs and 'systemctl status dirsrv@xxxxx.service' for details.
Failed to get load state of dirsrv@xxxxxx.service: Access denied

以下の URL によれば、どうも既知の問題らしい。SELinux をチョチョイといじれば治るってものでも無いらしい。



The issue is that to do this, we need to give apache (httpd_t, dirsrv_admin_t) control of the initrc_t, which is basically root on the system. We can't do that just to allow communication to systemd, especially when this is an old java based console.
The alternate is to allow dbus_t and policykit access, but this is extremely complex and time consuming to integrate. We feel our energy is better spent elsewhere, as server restarts can be conducted in other ways.
We have previously decided not to fix this issue, advising either the use of specific permissive contexts (semanage permissive -a dirsrvadmin_script_t), or through out-of-band restart.
Red Hat Directory Server 10.1 の Release Note には、known issue として Admin Server の起動だけ失敗するとあるが、上記 URL によれば Directory Server の方もだよと。まぁ複雑だってことで勘弁してもらおう。



2018年3月3日土曜日

TLP on Thinkpad

TLP 入れたって日記を書いたばかりだけど、Thinkpad の場合は追加のパッケージを入れるべきっぽい。tlp stat したら以下の出力に気付いた。

 +++ ThinkPad Battery Features
tp-smapi   = inactive (unsupported hardware)
tpacpi-bat = inactive (kernel module 'acpi_call' not installed)
     : (snip)
 +++ Suggestions
* Install acpi-call kernel module for ThinkPad battery features
* Install smartmontools for disk drive health info

Suggestions とか親切だなと。acpi-call ってのを入れろと。これに関連した情報は以下の TLP 本家にあり。

http://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management.html#fedora

ThinkPads only

ThinkPad specific components for advanced battery functions are not available from the official Fedora repositories. Instead you need the RPM Fusion and TLP repositories (in a root shell):

ということで書かれている通りに dnf


dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
dnf install http://repo.linrunner.de/fedora/tlp/repos/releases/tlp-release.fc$(rpm -E %fedora).noarch.rpm
dnf install akmod-tp_smapi akmod-acpi_call

ちなみに最新版は  tlp-updates-testing リポジトリにあるとのこと。たまに覗いてみるといいらしい。

この acpi_call を入れたら、tlp stat で以下が出力されるようになった。
tpacpi-bat.BAT0.startThreshold                              =     96 [%]
tpacpi-bat.BAT0.stopThreshold                               =    100 [%]
tpacpi-bat.BAT0.forceDischarge                              =      0


TLP 入れたけど wpa_supplicant が先に起動してないとダメ

5 年経った会社のノート(X1 carbon gen 1)のバッテリーの持ちが悪いので、バッテリーだけ買った(会社の経費)んだけど、新品なのにどうも保ちが悪い感じ。販売店に聞いたら「省電力マネージャを開いて満充電容量が既定値でないなら初期不良」とのこと。

upower で確認すると、「energy-full:  49.06 Wh」ってことで、既定値の「energy-full-design:  47.21 Wh」を超えて満充電されていた模様。超える分には問題無いんだろうなぁ。

しかし、仮にこれが異常だったとして upower の出力を販売店に見せても、サポ外とか言われるよなぁ。あぁあの時 Windows マルチブートにしておけばよかった...

まぁ、新しいバッテリーに換装するまで気にしてなかったのも問題だけど、これを機に TLP 入れることに。

が、私の場合システムが起動してから wpa_supplicant を手動で起動してるんだけど、TLP が先に start してると wpa_supplicant が AP に接続できない。何でか理由は面倒だから調べてない。wpa_supplicant を先に起動してから TLP を start すれば行ける。/usr/lib/systemd/system/tlp.service 見ると「After=multi-user.target bluetooth.service NetworkManager.service」になってて、ネットワークが起動してから tlp init start してる模様。

TLP を手動で起動するのもアレなので、wpa_supplicant との絡みについては今後検討することにする。とりあえずは手動で。

TLP の挙動自体に関してはいい感じで、upower の time to empty の値が以前より増えてる感じ。TLP についてはこのまま様子を見てみることにする。