chakokuのブログ(rev4)

テック・コミック・DTM・・・ごくまれにチャリ

MinecraftをPythonで制御したい

望み:教育用途にMinecraftが活用されつつあると知り、MODを入れるとPythonMinecraftを制御できるらしい*1。どのようなプログラミングができるのかを理解したい
結果:取り組み中
詳細:Python側のライブラリは、mcpiを使うらしい。pcpiは直接Minecraftと喋れないので、MODを入れて、Minecraft側にAPIの口を設けるようだ。このMODは、Raspberry Jam Mod というらしい。でMODを管理するツールが、Minecraft Forgeらしい。だから、、まずForgeを入れて、ForgeからMOD(Raspberry Jam Mod)を入れる。これでAPIが作られるので、mcpiから叩くと。

まずはForgeのサイトにいって、DLしてインストールする。アーキテクチャの問題はもうmac osに任せる。。*2

■追記
当初、ForgeはMODインストーラと思っていたら、APIも提供しているらしかった。ForgeはMODローダと呼ばれているらしい。Raspberry Jam MODを使いたかったらForgeは必須になるのだろう。MOD開発でもForgeの利用を前提にする場合もあるようだ。落ち着いたら俺MODも作ってみたい。Javaで作るらしい。
以下Minecraft Modding Wikiより引用

Minecraft Forgeとは、Mod間の互換性を保ちつつMinecraftを拡張するために作られたAPIである。
1.8以前はForgeModLoaderが基本部分を担っていたが、統合された。

GitHub - martinohanlon/mcpi: Minecraft: Pi Edition API Python Library
GitHub - zhuowei/RaspberryJuice: A plugin for Bukkit implementing the Minecraft Pi API
GitHub - arpruss/raspberryjammod: Raspberry Jam Mod - a Mod Forge Minecraft mod implementing most of Raspberry Juice/Pi API
Downloads for Minecraft Forge for Minecraft 1.19.2
How to Code Minecraft Mods: Fun Tutorial - Create & Learn
Minecraft Coding Class By Experts from MIT and Minecraft - Create & Learn
Mod開発 - Minecraft with Code Project
Minecraft Forge API - Minecraft Modding Wiki
Minecraft Modding Wiki

*1:小学生がPythonMinecraftをプログラミングするかどうかはおいといて

*2:forgeは jarファイルのようでアーキには依存しないだろう

Mac 上で Ubuntu / java を走らせたい

課題:Mac上でDockerを走らせ、Docker上でUbuntu / javaを走らせたい*1
結果:これがベストかどうかわからないが以下で入った。入ったイメージはaarch64(Arm64bit)である。

% docker pull ubuntu
% docker run -it ubuntu

jdk-19_linux-aarch64_bin.tar.gz をDLして、Docker内の/usr/local/javaを作って展開した。結果、javaを入れられた。本当の目標は、Ubuntu/Java上でJavaMinecraftを走らせることだったが、アーキの壁を超えられずこの取り組みは諦めた。
詳細:
Dockerは走らせた。情報は以下、OS/Archは darwin/arm64になっている

% docker version
Client:
 Cloud integration: v1.0.24
 Version:           20.10.14
 API version:       1.41
 Go version:        go1.16.15
 Git commit:        a224086
 Built:             Thu Mar 24 01:49:20 2022
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.8.2 (79419)
 Engine:
  Version:          20.10.14
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.15
  Git commit:       87a90dc
  Built:            Thu Mar 24 01:45:44 2022
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.5.11
  GitCommit:        3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc:
  Version:          1.0.3
  GitCommit:        v1.0.3-0-gf46b6ba
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

X86アーキのイメージもqemuによるエミュレーションで動かせるらしい。ただ、エミュレートするので実行が遅くなる。できればネイティブで動くArmイメージを選択するのが良いらしい。だから、、Ubuntu ARM版をPullすればいいのかと。
何も指定せずにpullしてみる

% docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
56a2caa6b2c6: Pull complete 
Digest: sha256:7cfe75438fc77c9d7235ae502bf229b15ca86647ac01c844b272b56326d56184
Status: Downloaded newer image for ubuntu:latest
docker.io/library/ubuntu:latest

% docker images
REPOSITORY     TAG       IMAGE ID       CREATED        SIZE
ubuntu         latest    53f68adfb4a9   3 days ago     69.2MB

どんな素性のUbuntuが落とされたのか不明。
起動してみる。aarch64となっており、 ARM Archtecture 64bit版であることがわかる。だから、、特に指定せずとも普通の操作でARM版のOSが入るようであった。

% docker run -it ubuntu
root@62911f950342:/# hostname
62911f950342
root@62911f950342:/# uname -a
Linux 62911f950342 5.10.104-linuxkit #1 SMP PREEMPT Thu Mar 17 17:05:54 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
root@62911f950342:/etc# cat os-release 
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Arm用のUbuntuを導入できたので、次はJavaを入れてみる。

JDKインストレーション・ガイドより
Linuxプラットフォームに64ビットJDKをインストール
Linux aarch64 (64ビットARM)システム: jdk-16.interim.update.patch_linux-aarch64_bin.tar.gz

上記をUbuntuに入れたらいいのだろうか。

LinuxプラットフォームでのJDKのインストール

Java 19 and Java 17 available now

Arm 64 Compressed Archive	179.90 MB	
https://download.oracle.com/java/19/latest/jdk-19_linux-aarch64_bin.tar.gz ( sha256)

Java Downloads | Oracle 日本

コンテナにcopy

docker cp jdk-19_linux-aarch64_bin.tar.gz  62911f950342:/usr/local/java

コンテナで展開、実行確認

#  cd /usr/local/java/
#  tar xvfz jdk-19_linux-aarch64_bin.tar.gz 

root@62911f950342:/usr/local/java/jdk-19.0.1/bin# pwd
/usr/local/java/jdk-19.0.1/bin

root@62911f950342:/usr/local/java/jdk-19.0.1/bin# ./java --version
java 19.0.1 2022-10-18
Java(TM) SE Runtime Environment (build 19.0.1+10-21)
Java HotSpot(TM) 64-Bit Server VM (build 19.0.1+10-21, mixed mode, sharing)

上記の通り動かすことができて、Java実行環境もできた。ということで、MinecraftJava版(他の Linux ; Minecraft.tar.gz) を入手して展開、起動してみた。すると、Java版と言いながら、x86アーキとなっているようで、x86用のlibが無いと怒られる*2

root@62911f950342:/usr/local/Minecraft/minecraft-launcher# ls
minecraft-launcher
root@62911f950342:/usr/local/Minecraft/minecraft-launcher# file minecraft-launcher 
minecraft-launcher: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=13e4acebc63a3d601754a6481f297389a4d5bc73, stripped
root@62911f950342:/usr/local/Minecraft/minecraft-launcher# ./minecraft-launcher 
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

上記よりJava/Linux版はx86アーキ前提のようである。走らせるには、qemuによるエミュレーションが必要になる。動くのは動くだろうが、遅くなるだろう。エミュレーションが不要なarm用アーキのMinecraftMac用というやつだろう(この場合、普段使っている環境に入れることになる。なお、OSは違うがAndroid版はARMアーキらしい)。M1 MAC用のMinecraftがあるのかどうか不明。自分はネイティブの環境を汚したく無いので、できればややこしいソフトはDocker内で走らせたいのだが。

隔離されたDocker環境にMinecraftをインストールしたかったが、アーキの壁を解消できず、ネイティブの環境(普通につかっているMacOS)に入れることにした。MAC用のMinecraftをDLしてインストールすると普通に動いた(当たり前だが)。ただ、、このアプリがどういう素性で動いているのか不明。Java版だからアーキには依存しないと言えそうだが、Java Runtimeがx86だとエミュレーションしながら動いていることになる。
以下はMacOS上で動いている画面。多分エミュレートしながら動いてるのだろう。(と思ったらこれはラウンチャーだった。ここから実行したいバージョンを選択して本体を起動することになる。。ふむふむ) (現在のバージョンは1.19.2)


Download options for Minecraft | Minecraft

■追記
もう一台のPCはWindows環境で、WSL上でUbuntuが走る。こっちのUbuntux86アーキなので問題なくラウンチャ―が走って、Java版のMinecraftは走った。10年ぐらい前のノート(CF-F10)なので非常に遅い。だが、、動くには動く。

*1:最終的にはLinuxMineCraftを走らせたい

*2:javaのランタイムが同梱されており、ランタイムがx86なのだそうだ。だが、、minecraft-launcherのサイズは1.6Mと非常に小さく、これが本体とは思えないのだが

マイクラが熱いらしい(今さら?)

とある勉強会に見学に行った。小学生向けのプログラミング教室で、「マイクラが好き」と叫んでいた。マイクラが人気らしい。マイクラは昔からあってなぜ今熱いのか??分からない。自分はあの8ビットの(ような)ドット絵がちょっと苦手で(学生の頃のAppleIIを思い出すから??)少しプレイして飽きてしまってそれ以降まったく触ったことが無かった。だが、、小学生には人気らしく、子供向けの本も一杯出ている様だ。
教育にもマイクラの波??というのがあるようで、改めてマイクラを勉強してみようと思った。もし、小学生にマイクラを教える時が来ても自分がマイクラを楽しんでないと教える資格がない。どっちかというとPythonでマイクラをゴリゴリ動かす方に興味があるのだが。。

イクラは基本有償だが、ラズパイ上で動かすJava版は無償らしい。ちょっとよくわからない。
マインクラフト - Raspberry Pi公式ドキュメントを日本語訳

無料のレンサバもあるようなのだが。。なぜ無料で提供されるのか、さらに分からない*1
https://aternos.org/:ja/

イクラにどっぷりつかってみないと分からないことだらけ。。

試しにUbuntuで走らせてみた。すると以下のエラーが出た

$ java -Xmx1024M -Xms1024M -jar minecraft_server.1.19.2.jar nogui
Error: LinkageError occurred while loading main class net.minecraft.bundler.Main
        java.lang.UnsupportedClassVersionError: net/minecraft/bundler/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 58.0

$ java --version
openjdk 14.0.2 2020-07-14
OpenJDK Runtime Environment (build 14.0.2+12-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 14.0.2+12-Ubuntu-120.04, mixed mode, sharing)

どうやら、Ubuntuに入っているJavaが 14(58.0)なのだが、17(61.0)まで上げる必要があるようだ。

■追記
いろいろあったが、結局Mac用のMinecraftを購入した(ライセンスだけ買った)。やってみたが何をどうやったらいいのかGUIもよくわからず、すぐ死ぬので、公式ガイドブックを買うことにした。
Minecraft for Beginnersというやつ。英語版しかないようなのでしょうがない。YouTubeとかネット上の記事を読んだら分かるのでは?という意見もあるかもですが、公式本では、このゲームをどのような説明をしているのか知りたいという目的もある。広大がゲームだから全部を文書化すると百科事典ぐらいになってしまうだろう。何も知らない人に一冊で伝えるには、ゲームの入口を丁寧に書いているのだろうと思う。


■追記
ガイドブックを買ってしまったが、初心者向けのわかりやすいWiki があった。
チュートリアル/ビギナーズガイド - Minecraft Wiki


Java版マインクラフトを、Macにインストールする方法 – サウンドテック・ラボ
Minecraft のダウンロード: 再ダウンロード方法を確認する | Minecraft
Download server for Minecraft | Minecraft
Tutorials/Setting up a server – Minecraft Wiki

*1:分かった事:マイクラのサーバ版とは、マイクラを持っている人同士をつなぐ中継サーバらしかった。サーバ版のマイクラアプリがワールド?というのかマイクラの世界?を管理しているのかどうかまでは不明

故障したiPhone7を分解:液晶パネルを開ける

目的:故障したiPhone7を修理する
結果:プライヤーを使うことで液晶パネルを開けられた
詳細:
前回キッチンにあった吸盤で液晶パネルを剥がしてみようと思ったが、どこまで力を加えていいのか分からず、液晶パネルを割ってしまうのではないか?と恐れて作業を中断した。今回、専用の工具(オープニングプライヤー)を買ってそれを使ってみた。以下が購入したプライヤー、1000円以下で買える。機構は簡単なのだが、、これがないとやっぱり恐ろしくて力かけられない。

プライヤーの吸盤をスマフォの本体と液晶パネルに吸着させて、プライヤーを使って上下に力をかける。分かったことは、プライヤーを使っても液晶パネルがぱっかりと開くのではなく、1mm以下の隙間ができるので、その隙間に何か工具を差し込んで、すこしずつ隙間を広げていくというやりかたで液晶パネルを開く。手元に竹のへらがあったので、隙間からへらを差し込んで、隙間をじわじわと広げた。結果、1mmぐらいの隙間ができ、その隙間を使って別のへらを差し込んでスマフォの底辺から上部に向かって隙間を作りながらへらを進める。

そんな作業をじわじわ進めることで、防水パッキンでビッチリ粘着していた液晶パネルを開くことができた。コネクタがあるので、90度以上開くのはだめらしい。

なお、、液晶パネルの上部には以下のような爪があるので、開く時も真上には開くことができず、ちょっと下向きに引っ張る必要あり。

なんとか液晶パネルを開けられたので、、今後の作業は細かいパーツをはずしながら、基板を剥がす流れとなる。(新品の基板は1万のようだ。1万払って基板交換の修理するか。蓋を開けたから技適は無効だし(電話としては使えない)、修理しても基板交換のためフラッシュメモリの中身は復旧できないので、あまり意味がないのであった。電波は出せないのでデータビューアとしての使い方ぐらいか)

■追記
手に入る基板は新品ではなく中古品のようであった。高い金払ってまで治す気がなくなったので、、作業は中断

故障したiPhone7を分解してみるー>中断

取り組み:長年使ってきたiPhone7が故障したので修理に向けて分解してみる
状況:液晶パネルが無傷で開けられるとは思えず中断
ご注意:スマフォのケースを開けてしまうと技適マークは無効になるそうなのでご注意ください(自分の場合、機種変更したので、故障したiPhone7は修理しても電波は飛ばしませんの)

詳細:代替品を買ったので修理は必須ではないが、蓋を開けて中身がどうなってるのか知りたいと思い、修理してみることにした。ネジが特殊なので、工具を購入した。星形、Y字、フラットの+の3種類。いずれも分解工房製

液晶パネルを開けるにはiPhoneの底辺の星形ネジを緩める必要がある。


Lightningの両側にある二つのネジは専用工具で緩めると簡単に外れた。

後からどれがどれか分からなくならないように、どこに使うネジか、穴の形状も記録してネジ台帳に貼り付ける。

次は液晶パネルを開けるのだが、、家にあった台所用吸盤でちょっと試してみた。パネルは全く動く気配がなく、どう考えても液晶を割らずに開けられるとは思えない。

気密用シールがあるので実際の作業ではヒータ等で熱を加えて緩くするらしい。力加減も分からず、下手をするとパネルを割りそうなので、専用工具(吸盤の付いたペンチのようなもの*1)を追加発注することにした。と言うわけで、、今日はここまで。

*1:オープニングプライヤーと言うらしい

メモ:Boto3でエラー -> upgradeで解消(多分)

課題: UbuntuにBoto3を入れたがエラーが出て動かない
結論:関連ライブラリを更新することで解消(多分)

以下が発生したエラー

>>> import boto3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/dist-packages/boto3/__init__.py", line 17, in <module>
    from boto3.session import Session
  File "/usr/local/lib/python3.8/dist-packages/boto3/session.py", line 17, in <module>
    import botocore.session
  File "/usr/local/lib/python3.8/dist-packages/botocore/session.py", line 26, in <module>
    import botocore.client
  File "/usr/local/lib/python3.8/dist-packages/botocore/client.py", line 18, in <module>
    from botocore.args import ClientArgsCreator
  File "/usr/local/lib/python3.8/dist-packages/botocore/args.py", line 27, in <module>
    from botocore.config import Config
  File "/usr/local/lib/python3.8/dist-packages/botocore/config.py", line 16, in <module>
    from botocore.endpoint import DEFAULT_TIMEOUT, MAX_POOL_CONNECTIONS
  File "/usr/local/lib/python3.8/dist-packages/botocore/endpoint.py", line 27, in <module>
    from botocore.httpchecksum import handle_checksum_body
  File "/usr/local/lib/python3.8/dist-packages/botocore/httpchecksum.py", line 36, in <module>
    from awscrt import checksums as crt_checksums
ImportError: cannot import name 'checksums' from 'awscrt' (/usr/local/lib/python3.8/dist-packages/awscrt/__init__.py)

以下の手順で関連ライブラリを最新版に更新*1

sudo python -m pip install --upgrade awscrt
sudo python -m pip install --upgrade awsiotsdk

エラーは解消

>>> import boto3
>>>

EC2 — Boto3 Docs 1.24.89 documentation

*1:root権限で入れるな、VirutalEnvを使えと怒られる(System Package Managerの矛盾を引き起こすリスク)ので、多分良くない操作と思う

メモ: AWS CLIによるEC2管理

AWSの自動運用はBoto3を使っているけど、AWS CLIを使う必要があり調査
ec2 — AWS CLI 1.25.90 Command Reference

describe-instance-attribute — AWS CLI 1.25.90 Command Reference

aws ec2 describe-instance-attribute --instance-id i-1234567890abcdef0 --attribute instanceType


root deviceのSnapshotを取るにはInstanceの停止が必要
create-snapshot — AWS CLI 1.25.90 Command Reference

To create a snapshot for Amazon EBS volumes that serve as root devices, 
you should stop the instance before taking the snapshot.

AMIの作成なら、オプション指定することでrebootなしにAMI作成可能
create-image — AWS CLI 1.25.90 Command Reference

--no-reboot | --reboot (boolean)
You can set the NoReboot parameter to true in the API request, or use the --no-reboot 
option in the CLI to prevent Amazon EC2 from shutting down and rebooting the instance.

(AMI作成時、追加されたEBSの扱い(どうやって取捨選択するのか)がよくわからず)

データはEBSを増設した方に置かれていて、EBSからSnapshotを作るにはEC2の停止が必要
結局、EC2を止めないと現行EC2の複製できないと判断

ENI
create-network-interface — AWS CLI 1.25.90 Command Reference

aws ec2 create-network-interface --subnet-id subnet-9d4a7b6c --description "my network interface" --groups sg-903004f8 --private-ip-address 10.0.2.17

EBS
create-volume — AWS CLI 1.25.90 Command Reference
create EBS from snapshot

aws ec2 create-volume \
    --volume-type io1 \
    --iops 1000 \
    --snapshot-id snap-066877671789bd71b \
    --availability-zone us-east-1a

インスタンス複製はだいたいわかったつもりだが、、アカウントを超えてSnapShotをコピーするのが面倒くさそうだ(セキュリティも重要なので手間がかかるのはしょうがないが)
参考記事:
アカウント間のAMI共有&コピーの方法 - 協栄情報ブログ


AWS Organizationsによってアカウント統合されている。それぞれのOU(Organization Unit)には識別用のアカウントIDが振られている*1

OU間でSnapShotをコピーするには、コピーを渡す側で、ShapShotのセキュリティ設定画面から、アクセスを許すアカウントIDを設定する。コピーを受け取る側は、SnapShot画面で、Private Snapshotで検索?すると、上記提供されている別OUのSnapShotが参照できる。分かるとシンプルだ。シンプル過ぎてこれでいいのかとちょっと不安(アカウントID間違ったら知らない人に渡してしまう??)。

なお、SnapShotからEC2を起動するには、一旦SnapShot->AMIに変換が必要。この変換はコピー元でないとできない(AMIを作成する際に必要となる情報があるのだろう。元のEC2の情報を参照しながらAMIに変換するのかも)

■追記
若手への引継ぎを考えてAWS CLIを試していたけどやっぱりワクワクしないので、、Boto3で作業することにした

*1:OUに属するアカウントを作ったのだが、新アカウントにパスワードを設定する方法が分からなかった。結果としては、、新アカウントでログインまで進み、パスワード忘れのフローに入ってパスワード再設定するようであった