このページについて

いわゆるBlog的なページですが、

・極端にパーソナルなことは書かない方針です(ご飯くらいは書くかも)

・OS、CMSネタなども掲載しますが、取りまとめた内容はなるべく別個記事にするか、同人誌に取りまとめる予定です。

・なので技術よりの内容に関しては書いた時点の情報であり、最新化されていない場合があるのでその点をご了承下さい。

極北別世界通信

OpenMeetingsのLDAP設定について

2020年9月4日 21時15分

OpenMeetingsのVersion5.0.0でのLDAP設定に罠が潜んでたんで軽く記載。

(ってまだLDAP構築記事書き終わっとらんやんけ)

 

技術書典9に参加予定です。

2020年8月25日 22時42分

https://techbookfest.org/event/tbf09

というわけで参加予定です。

とりあえずマイナーOS系は残念ながらあまりいいネタが仕入れられていないので怪しいです。

どちらかというとリモートワークを主体とした各種サービスの導入についての書籍になると思います。

可能ならなんらかのマイナーOSネタも扱いたいですが。。。

なお基本的にPDFでのダウンロード販売のみになる予定です。

その他の構築物

2020年8月25日 22時28分

こちらも後々詳細を追加する気ではいますが、一応何を書こうと思ってたのかがわからなくならんように記載。

OpenLDAP構築続き

2020年8月25日 22時18分

なかなか時間が取れてないのですが書く気があるのをアピールするためにとりあえず。。

とりあえずやったことを箇条書きにしますがなるべく箇条書きの中身をあとから詳細に書こうと思ってます。

OpenLDAP構築

2020年6月3日 00時35分

以前からやろうやろうと思ってはいたのですがなかなか手が出せなかったOpenLDAP構築にようやく手を出した。

きっかけは前回投稿しているOpenMeetings関連。

社内でテスト利用してもらおうにも、アカウント周りの作成とか管理が課題になる。

んではLDAPで管理すりゃええんちゃう?ということで構築開始。
また、今後もLDAPをサポートしているオープンソースの各種ソフトウェアの試験利用時にもアカウントを使いまわせて試す側も楽になるであろうという考えもあってのことではある。

過去に構築そのものはしたことがあるが、その際には有識者とセットで仕事でやったものなんで、極論を言えばコピペが正しく出来ましたか?レベルだったので、今回はちゃんと自分のとこの環境として考えて構築する。

 

Apache OpenMeetings

2020年5月21日 23時39分

世の中リモートワークばやりでございますが、捻くれ天邪鬼な性格の自分としてはすぐ「zoom使いたくねぇ」とか始まってしまうんですね。

いやまぁなんだかんだ言って仕事なら使うんですがね。

で、オープンソースのWeb会議ツールは敷居が高くてちょっと敬遠してたんですが、まぁせっかくだし流行りに乗って構築してみようかなと。

ただ、当方の場合最終的に「自宅で作ってDDNSでアドレス取ってNginxのリバースプロキシで振り分ける」という単なる構築以上に面倒くさい構成が待っているのでそこはちょっと辛いとこなんですが。

ちなみにNginxはまだ全然ド素人なので、いっかいちゃんと勉強しないといけませんな。

閑話休題

 

直接的には

2020年5月14日 23時07分

被害があるわけではないけど、やはり間接的には影響がありますなあ

新コロ関連でバタバタしてあっという間にいろいろやる時間がごっそり無くなっていました。

コミケも中止になってその後のことはまだまだ予断を許しませんし、どうなることやらですね。

また気を取り直していろいろやっていきたいです。

Shirasagiの扱いが難しい

2020年2月18日 22時36分

まぁRubyやらRailsやらからっきしなのでアレですが。

今回のはRuby関係ないですが。

Shirasagiの常時SSL化をNginxのリバースプロキシ下でやろうとしてハマった話。

インターネット(SSL)⇒Nginx ⇒(ここから先http)(別Serverの)Nginx ⇒ Shirasagi(Unicorn?)

という構成で、公開サイトをsslで表示するのはすぐにできたんですが、管理画面ログインがうまくいかなくて困った。

 

フロント側のNginxのプロキシ(ヘッダー)設定を

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-Proto https;

バックエンド側のNginxはShirasagiインストール時に生成されてるんだけど、

#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-For "$http_x_forwarded_for, $realip_remote_addr";

に書き換えてみた。

ようはフロントで

proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-Proto https;

して、バックエンドで

proxy_set_header X-Forwarded-Proto $scheme;

することでうまくいくらしい。

なおバックエンド側に追記したのは

フロント側で

proxy_set_header X-Forwarded-For $remote_addr;

しておいてバックエンド側で書き換えた

proxy_set_header X-Forwarded-For "$http_x_forwarded_for, $realip_remote_addr";

でアクセス元のIPを取ろうという記述、、、のはず。

Nginx触り始めて1週間でググりまくった結果なのでまたこつこつ調べないといけませんね。

F-Revo CRM patch適用とPHP7.2化

2020年2月17日 21時51分

雑ですが忘れないようメモ

・F-Revo CRMをインストール

無印?版はphp5.6でしか動かないのでオフィシャルなどにある手順通りインストール

https://f-revocrm.jp/2018/08/8273

パッチ3の適用まで書いてありますが、さらに今はパッチ4、5、6、6_1までリリースされていますので、すべて適用します。

基本的にアーカイブを展開してディレクトリごと上書きするだけです。

また、前の記事で書いた includes/main/WebUI.php

がパッチ6で上書きされるので、修正しなおしを忘れないようにしましょう。

パッチ6がphp7対応バージョンとのことなので、合わせてphpを7.2に更新します。
一応apacheとか止めておいたほうが無難なのかな?当方は仮想マシンで丸ごとバックアップしていたのであんまり考えずに実行してしまいましたが。

yum install --disablerepo=base --enablerepo=epel,remi,remi-safe,remi-php72 php php-gd php-mysqlnd php-imap php-mbstring php-devel php-mcrypt php-xml php-opcache

用心でphp.iniとかもバックアップしてましたが、特に何も変更せずとも大丈夫でした。

これでphp7.2環境になりました。

時間が取れそうならもう少し丁寧に書きます。。。

F-revo CRM リバースプロキシ関連のTips

2020年2月16日 23時27分

F-revo CRMをNginxのリバースプロキシの背後に置くとRefererを見られてうまく動いてくれない。

本来ならgetコマンドでRefererを取って反映、とかやるのが正しいのだろうけど、とりいそぎコード変更してみた。

どうなんだろ、一応開発元に質問したりしてみてもいいもんなんだろうか。

なお前提としてNginxでのリバースプロキシは構築済みで、nginx側でのSSL化も済んでる前提です。

■事前:

crm/config.inc.phpの「$site_URL」を以下のように設定

$site_URL = 'http://【サーバのIPアドレス】/crm/';

■以下のように変更

# vi crm/config.inc.php

$site_URL = 'https://【SSL証明書を取得したドメイン名】/crm/';

# vi crm/includes/main/WebUI.php

// if ($site_URL && stripos($request_URL, $site_URL) !== 0){
// header("Location: $site_URL",TRUE,301);
// exit;
// }

ただ、これRequest URLとSite URLが正しくないと接続を許可しないってセキュリティ面を担保する設定のような気がするので、そもそもOFFにするのがいいのかといわれるとちょっと。。という感じ。

一応ログ等見ながら様子見。

。。。あれ、パッチどこまで適用してたっけ。。ちょっと確認しないと。