背景

会社ではjenkinsの相談が良く来るのですが、最近この類の話が２件あったのでメモしておこうと思います。

事象

Aさん「なんだか変です、JENKINS_HOMEが、/var/....にあります！」
Bさん「助けてください、マシンを再起動したら、jenkinsが接続できなくなっちゃいました！」

とのこと。ちなみに、どちらもmacosです。
なんだなんだ、いったいどうしたんだ？
わかりました、一緒に見ましょう。

Aさんの場合

Aさんは、ある程度jenkinsを触ってもらっていた新卒の子だったので、多少知見がありました。
パイプラインジョブも一人で書けます。
違う作業をしていて、マシンを再起動させたところ、どうやら

「JENKINS_HOME」が/var/root/.jenkins に変わっている
/var/root/.jenkinsに元々ホーム設定していたデータをコピーしてみたところローカルからは起動ができた
adminのパスワードで入れなかったので、一旦パスワードなしに設定した
外側から接続できない

ということでした。

HOMEなんて今まで設定しなくてもよかったはずだが

他のサービスでつかっていたマシンを確認しましたが、JENKINS_HOMEを設定した記憶はありませんでした。
そこでいくつか、怪しいと思われるところを確認しました。

Jenkinsの管理 → システム設定 → Jenkinsnの位置 -> 問題なし
/opt/homebrew/Cellar/jenkins-lts/jenkinsバージョン/homebrew.mxcl.jenkins-lts.plistにあるIPアドレス指定

参考：
https://superuser.com/questions/650420/jenkins-not-accessible-through-lan

確認したところ、設定を変更したはずのところがもとに戻っていたので直しました。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>homebrew.mxcl.jenkins-lts</string>
    <key>ProgramArguments</key>
    <array>
      ....
      <string>/opt/homebrew/opt/jenkins-lts/libexec/jenkins.war</string>
      <string>--httpListenAddress=0.0.0.0</string> <-- ★ここが127.0.0.1になっていた
      <string>--httpPort=8080</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

これはなにか変だな、初期化されているのだろうか？と頭をよぎりました。
そこで、一旦以下を目指しました。

外側から接続できるようにすること
JENKINS_HOMEを元ある形にすること

.zshrcで環境変数を定義し、再起動をしてみましたが、JENKINS_HOMEは定義されるもののjenkinsのサービスをリスタートしてみても、HOMEはまだ変わっていないようです。

JENKINS_HOMEとアドレス設定をjenkinsサービス起動時に強制的に変更する

調べていたらこのような記事がでてきました。

この記事によると、
/usr/local/opt/jenkins-lts/homebrew.jenkins-lts.serviceにある変数で、

-DJENKINS_HOME=ほげほげ --httpListenAddress\=0.0.0.0

というように指定してあげます。例のパスは、intel版なので、m1版だと/opt/homebrewの方です。

これでサービスのリスタートや再起動をしていたら治りました。
ログインなどをしてみて気づいたのですが、どうやら、jenkins UIが新しくなっていることに気づきました。ログインページも。

後日、Aさんによくよく話を聞いた結果判明するのですが、
実はAさんはmacosにいれていたjenkinsのbrewの更新をかけちゃったというのです。
慌ててuninstallはしたですが・・とのことでしたが、おそらくそのときに設定周りが初期化されてしまったのでしょう。

Bさんの場合

Bさんの場合は、ほぼjenkinsは触ったことがない、新卒２，３年目ぐらいの若い子です。
聞き込みをすると以下のようになっているとのこと。

外側から接続できない
ローカルから接続できない
macosをアップグレードした

と、ここでちょっと目を疑うのが、
安易なるosのアップグレードでした。
macosをアップグレードした場合、pythonをどこに入れたかによっては、パス設定が消失していたり、ごっそり消えてしまったりする。pyenvなどで入れれば別ですが。

おそらく、あまり良く分からずにjenkinsのmasterが入っているマシンをえいや　とやってしまったものと思います。
内部を確認したところ、

ログイン用のプラグインがうまく動いてなさそうだということがわかりました。
以下のようなエラーが出ていたのです。

com.thoughtworks.xstream.mapper.CannotResolveClassException: com.michelin.cio.hudson.plugins.rolestrategy.RoleBasedAuthorizationStrategy
    at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:81)
    at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:125)
    at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:55)
    at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:125)
    at com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)
    at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:125)
    at com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:79)
    at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:125)
    at com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:74)
    at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:125)
    at com.thoughtworks.xstream.mapper.SecurityMapper.realClass(SecurityMapper.java:71)
    at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:125)
    at hudson.util.XStream2$CompatibilityMapper.realClass(XStream2.java:412)
    at hudson.util.xstream.MapperDelegate.realClass(MapperDelegate.java:46)
    at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:125)
    at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:47)
    at hudson.util.RobustReflectionConverter.determineType(RobustReflectionConverter.java:521)
    at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:346)
Caused: jenkins.util.xstream.CriticalXStreamException:
...

RoleBasedAuthorizationStrategyというのは、ロール定義するプラグインの一種なのですが、これがうまく動いてないようです。

SSOログインなどと連携するときによく使うのですが、ここで予想されたのは以下です。

macosが更新されたときになんらかの問題が有り、おそらくjenkinsが更新されている
プラグインとの不整合が起きて、プラグインがうまく動作していない

まず、ログインしなくてもjenkinsをいじれるようにする

この場合の正攻法としては
login設定をOFFにすることです。

jenkinsサービスを止める
JENKINS_HOMEにあるconfig.xmlを開く
の長い設定をバッサリ消す
false に設定する
jenkinsサービスをスタートする

これで、ログインしなくてもjenkinsサービスをスタートできます。

プラグインの問題が山積みであった

いくつか問題が有りました。

slaveが動かない
ビルド途中のプラグインが停止して、ジョブが最後まで回らない

とかかな。ステージを見てみると、ジョブがどこで止まっていて、なぜ動かないか、ログを見ながら判断するようにしましょう、とBさんに教えました。
プラグインをいくつか更新したところ、jenkinsが復旧するようになりました。

復旧後、Bさんに伝えたこととして

安易にOSを更新しないこと
masterマシンをいじるときは必ずバックアップを取ること
メモも取らずに色々変更しないこと
変更した設定ファイルはバックアップを取るか、undoできる状態にすること、またはスクショを取ること

でした。
あと、上長の方には、部下のことをちゃんと見てほしいなあ・・というのはちょっと思ったかな。
挑戦させるのはいいけど、部下のケツは拭いてほしいぞ・・！！

Bさんは特にちょっとテンパっているようだったので、可愛そうでしたが、本当に気をつけてほしいところです。

ただ、AさんとBさんは、失敗したことで色々学びがあったかな、とも思います。
そういえば、Aさんにバックアップのことを言うの忘れてたので、伝えなくては・・・・。

jenkins:再起動したらjenkinsにアクセスできなくなったと困っているメンバーがいたので見てみた話。

背景

事象