Linux-Unix

※2022年6月にcentos8のdockerコンテナ使えないことに気づいたのとauthselectについての記述が欠けてたので、centosではないredhatクローンを使う方法に 切り替えた。 前に一度作ったdockerコンテナでの環境を、普段使いのdocker環境に追記して最近やり直したのでメモ。 ldap版の 方法はここ 。これを足がかりにしてldapsにしてみる。 phpldapadminではldifファイルってのが扱えて、ou以下のグループとユーザIDをエクスポート・インポートできる。 ldap版で作ったouとかはldifにエクスポートしておき、ldaps版にインポートする。 コンテナ起動のための docker-compose.yml内容はここ。 openldapのコンテナ起動 docker-compose.ymlを用意して起動。 自分のルールとしては、練習じゃなくて常時稼働にするサーバにはコンテナ名の頭に"sv_“をつける。 ldapからldapsにするついでに、phpldapadminもhttpsにしてみる。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 sv_ldap-server: ←★sv_つける image: osixia/openldap:latest restart: always container_name: svldap-server ←★svつける environment: LDAP_ORGANISATION: "gvis" LDAP_DOMAIN: "intra-gavann-it.com" LDAP_ADMIN_PASSWORD: "hogehoge" LDAP_TLS_VERIFY_CLIENT: "never" ←★自己証明書使うから証明書チェックさせない ports: - "11389:389" - "11636:636" ### https://nafslinux.intra.gavann-it.com:11802/ ### cn=admin,dc=intra-gavann-it,dc=com ### hogehoge ### ### 参考URL https://github.com/osixia/docker-phpLDAPadmin ### ### httpsを使うときは、証明書が自動作成されているので取得してクライアント側に設定すること ### コンテナ内の保管先：/container/service/slapd/assets/certs ### ### 参考URL https://github.com/osixia/docker-openldap#use-your-own-certificate sv_ldap-admin: image: osixia/phpldapadmin:latest restart: always container_name: svldap-admin environment: PHPLDAPADMIN_LDAP_HOSTS: "ldap-host" ports: - "11801:80" - "11802:443" ←★https提供してもらうため depends_on: - "sv_ldap-server" links: - sv_ldap-server:ldap-host 起動した後のdocker psはこんな感じ。 ...

※2022年6月にcentos8のdockerコンテナ使えないことに気づいたので、centosではないredhatクローンを使う方法に 切り替えた。 とっかかりは業務での運用。 作ったことなかったので、dockerでOpenLDAPサーバを作っておき、centos8で接続できる方法を探し当てて検証し、同じ方法で業務のredhat8からも接続できた。 業務でdocker使えたらこんなまわりくどいことしないのに・・・。 redhat6/7ではnslcd使えてたらしいが、redhat8ではsssd接続のみに変更になってしまったので、sssd.confの書き方を見つけるために作った。 これがなかなかうまくいかず、rhel8のサポートも使わせてくれなかったので、自分で試しながら設定内容を探り当てた。 sssdはredhat7でも使えてて、8になってからnslcd使わなくなったらしい。 ここではopenldapのコンテナと、それを管理させるためのphpldapadminのコンテナを作っておき、コンテナのcentos8から認証接続させるまでの経緯。 前に一度作ったのを、普段使いの環境に追記して最近やり直したのでメモ。 コンテナ起動のための docker-compose.yml内容はここ。 openldapのコンテナ起動 docker使ってldapするにはopenldap使うらしい。 hub.docker.com githubに詳細がある。slapdっていうデーモン使うらしい。 GitHub - osixia/docker-openldap: OpenLDAP container image 🐳🌴 github.com slapdの最新は今見たら2.5.7。 www.openldap.org githubにあるosixiaは1.5で、dockerコンテナ内で使ってるopenldapを見てみたら2.4.57。openldapが最新ではないけど、コンテナ定期的に作り直すし、まぁいいか。 1 2 3 4 root@0e1af753333d:/# slapd -V @(#) $OpenLDAP: slapd 2.4.57+dfsg-1~bpo10+1 (Jan 30 2021 06:59:51) $ Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org> root@0e1af753333d:/# docker-compose.ymlを少し書いて用意する。ちょろい。1分もかからない。 以下、このときのdocker-composeの抜粋。 1 2 3 4 5 6 7 8 9 10 11 12 nari@nafslinux-intra-gavann-it-com:/docker$ docker-compose up ldap-server Pulling ldap-server (osixia/openldap:latest)... latest: Pulling from osixia/openldap 45b42c59be33: Already exists ae7fb8f59730: Pull complete 55443d9da5d5: Pull complete :（中略） ldap-host | 614e0e11 @(#) $OpenLDAP: slapd 2.4.57+dfsg-1~bpo10+1 (Jan 30 2021 06:59:51) $ ldap-host | Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org> ldap-host | 614e0e11 slapd starting phpldapadminのコンテナ起動 docker-compose.ymlを少し書いて用意する。これも１分以内で終わる。 ...

IBMがredhatを含めちゃった数年前、なんか嫌～な感じがしてた。 やっぱりというか、centosの役割が変わってdockerhubからcentos8のイメージがなくなってた。 前に作ったldaps接続を、イメージからコンテナ作り直すことができない。 そこに、redhat9が リリース されてた。 業務ではほとんどがredhatとかamazonlinuxを使う。 今はたまたまredhatがほとんど。 十分なテスト環境をいつも使えるわけじゃないから、研究・検証・勉強のためにはdockerを使って環境作って知見を得る。 centosが使えないなら、redhatのクローン探しからやりなおしてldap認証やったろやんけ。 コンテナで ldapsサーバ作る箇所 はそのままで、接続元をredhat8/9のクローンOSで置き換えてみた。 redhatクローンOSの選択 いくつかある。 ただし、dockerイメージがないと自分には使えない。 ubuntu22にベースOSを変えたときusb3のディスクを高速なssdに変えたから、ディスクのI/O性能が数倍よくなって、めっちゃコンテナ作成速度も上がった。 結論 redhat8/9のイメージがdockerhubにあったけど、結局は使えなかった。 理由はパッケージの制限があってsssd/oddjobdがインストールできなかったから。 redhat面倒くさー。 やっぱりクローン使おう。 結局は、openldapのLDAPを使い、クライアント側はredhatクローンとしてalmalinuxの8.6/9.0を使い、OSへのログインをLDAP認証させた。 dockerの作業フォルダ こんな感じ。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 /docker |--docker-compose.yml |--nariDockerDat | |--cl_red8_Dockerfile | |--cl_red8　⭐️１ | | |--download | | |--script | |--cl_red9_Dockerfile | |--cl_red9　⭐️２ | | |--download | | |--script | |--sv_ldap | | |--gvisExport.ldif |--nariDockerSys　⭐️３ ⭐️１と⭐️２のcl_red8/cl_red9はクローンOSのための永続化領域。 ...

unix/linuxで定期的に処理を動かしたいときはcrontab使う。 たとえばcrontab.txtとか適当なファイルを作っておく。 左から、「分」「時」「日」「月」「曜日」「コマンド」を書く。 1 2 3 4 5 #daily rm 00 7 * * * /bin/find /gvis/ -name ".*DS_Store" -print -exec rm {} ";" 01 7 * * * /bin/find /gvis/ -name "Thumbs.db" -print -exec rm {} ";" 02 7 * * * /bin/find /nari/ -name ".*DS_Store" -print -exec rm {} ";" 03 7 * * * /bin/find /nari/ -name "Thumbs.db" -print -exec rm {} ";" この定義使うと、Thumbs.db(windowsが勝手に作るファイルね)とDS_Store(macが勝手に作るファイルね)を/nariのディレクトリ以下から探し出して抹消してくれる。 ...

mariadbにもLTSってのがある。 11.2が2023年2月に出てた。 MariaDB | endoflife.date endoflife.date 去年の暮れから、そろそろやらなアカンなぁって考えてた。 自分が使ってるのは10.5.7やったのを10.11に上げてく。 結果的にはバージョンアップするけど、動作確認しながらなので一時的に２つのバージョンのmariadbを共存させる。 去年まではphpから参照してたのを、djangoから参照するように変えたから、django内のモジュールもついでにバージョン上げてく。 詳細は長いリストになるものもあるから、分割で書いてリンク入れといた。 local-linuxとgoogle cloudの環境 local-linuxが練習環境、google cloudにあるのが本番環境。 djangoのアプリケーション作成と同じやり方。 local-linuxでまずは引越しの練習してからgoogle cloudで同じことやって、google cloudのデータをときどきlocal-linuxにもコピー反映する。 google cloudは本番環境として伝票入力とかドキュメント管理に使ってる。 データの入力や保管に「使う」ことに重点を置いてる。 できるだけ計算時間やディスク利用やダウンロードパケットは抑えながら使う方針。 そのためにlocal-linuxで練習してから実施。 実施のイメージ local-linuxでmariadb10.11のコンテナを作る docker-composeからビルドと起動できるようにする。 前はDockerfileとかconfフォルダ内の整理ができてなかったから、これもあわせて整理した。 ここでdocker-compose.ymlとdjangoのsettigs.pyに何て書けばいいかが確定する。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +------------------------------------+ |local-linux(ubuntu22) | | +--------------------------------+ | | |docker23 | | | | +--------------+ +-------+ | | | | |mariadb10.5 | |django4| | | | | | nari_1st | <-- | | | | | | | nariDB_Django| | | | | | | +--------------+ +-------+ | | | | | | | | +------------+ | | | | |mariadb10.11| | | | | +------------+ | | | +--------------------------------+ | +------------------------------------+ nari_1stってのが本利用のスキーマでgoogle cloudと同じ内容を維持する。 永続化領域をgoogle cloudから丸々コピーして使ってる。 ...