それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

Mac の文字化けする日本語の文字(濁点)を一括して文字コード変換する

Mac OSXの濁点・半濁点問題。

濁点をどう扱うか問題。Mac OSXの HFS がUTF-8で保存するんだけど、濁点と文字を別に保存する。

ぜっけい→ せ゛っけい
とくべつれっしゃ→とくへ゛つれっしゃ

のように保存する。正しいとか悪いとか別にどうでもいいんだ。コレはコレで有りだと思うし。選択肢が多いのはいいことだし。

けど。文字列一致検索で引っかからなかったり、正規表現で掛からなかったりするのが困る。。。そういうのは、OS側でサポートしてほしいなと思うんだけど、サポートしてないからなんとかするしかない。

変換するコマンド 作った

rubyでぱぱっと濁点を直すように書き換えた。

utf8-mac-normalize

#!/usr/bin/env ruby
if  ARGV.size > 0    then
  ARGV.each{|e|
    str = "#{e}"
    puts str.encode!("utf-8", "utf-8-mac")
  }
else
  STDIN.each_line {  |line|
    puts line.encode!("utf-8", "utf-8-mac")
  }
end

これで簡単にできる。

コマンドの使い方

ls の結果をフィルタリングする。

ls | ./utf8-mac-normalize

find コマンドと組み合わせて

find -mtime 2 -exec  ./utf8-mac-normalize {} \;

などと出来る。

ファイルを名を正規化して、濁点を修正するには

ファイル名を正規化する場合は

for i in $(ls  /path/to/dir ) ;  
do 
    mv  "$i"  "$(utf8-mac-normalize $i  )" ; 
done ;

などとヤって一括してファイル名を揃える。ただし、空白を含むファイル名などには for だけでは対応できないのでIFSか、findを使う。

ファイル名に空白が含まれる場合。

IFS=$'\n'
for i in $(ls  ./ ) ;   do   mv  "$i"  "$( utf8-mac-normalize $i  )" ;  done ;

find/xargs は back quote とともに使えないっぽいので見送り

あれ?iconv を使わないの?

iconvコマンドは環境によって、手に入るてにはいらないかわからないじゃん?てかインストール面倒だし。。。

iconv の場合は次のようにする

ls |  iconv -f utf-8-mac -t utf-8

iconv が NFD に非対応だったので、今回rubyにした。

私のDebianは非対応だった・・・くっそ

ちなみに UTF8-MAC って?

正式名称じゃないです。慣用的に使われているやつです。 MSの932をShfit-JISと読んでる様な感じでしょうね。

HFS/HFS+ のファイルシステムで使われているので、 UTF-8-HFS と呼ばれることもあるようです。

だから、ファイル名 で主に登場します。気にしすぎは禁物、ブログ投稿画面とかでチェック必要ないからね。

2016-08-02

コマンドのミスを加筆修正

参考資料

http://tama-san.com/utf-8-mac_1/

http://blog.sarabande.jp/post/78293914880

php で pam を使う(ってはいけない)

php から ログインに Linuxのユーザー名&パスワードを使ってみよう

Linux のログインには、PAMが使われるのが一般的。 PAM を使うことでLinuxのユーザー名で認証ができる。

今回は PHPの pam を使って認証してみる

ただし、このやり方は試験的にやってるのであっていかなる時も、公開用本番サーバーに適用してはいけない。

準備

準備するのは次のモノを準備する。

  • php-pam
  • php.ini
  • pam.d
  • shadow

php-pam のインストール

インストールはいつものとおり、拡張機能のインストール手順でやる。

curl https://pecl.php.net/get/pam-1.0.3.tgz | tar zxvf -
cd pam-1.0.3
phpize
./configure && make && make test
sudo make install

php.ini の設定を作る

php.ini の設定でextension をロードするように作ります。

sudo sh -c "echo extensions=pam.so > /etc/php/conf.d/pam.ini"

apache の再起動

ここで、Apacheの再起動。

再起動して pam がロードされたか確認する。

pam.d を作る

sudo sh -c "@include common-auth > /etc/pam.d/php"

PAM 側に PHP が利用できる pam の設定を書いておく。PHPがPAMに認証を訊くとき、どのように認証するかここで決める。

最後に apahce が shadow を読めるようにする

ココが危険なんだけどさ。。。

sudo usermod -aG shadow apache

Apache が /etc/shadow ファイルを閲覧できるようにする。

危険すぎて公開サーバーでやると大変な目に遭う。

最後に php から pamを使う

<?php 
$error = "";
$res = pam_auth("takuya_1st", "password", $error) ;

if ( $res ){
 echo "ok"
} else {
var_dump( $error );
}

これで全部できる。

でも、安全に使えない

Apacheに mod_php を入れている状態では、全てのphp コードが、 apacheユーザーで動作している。

だから、apacheユーザーに /etc/shadow の読取り権限を与えると、とても危険。

echo file_get_contents("/etc/shadow");

はい、読めます読めます。

まぁ、shadow ファイルからパスワードが漏れることはないんだけど。

shadow は万が一の危険のために、一般ユーザーから見えない場所に、隔離してハッシュ値を保存しています。

apache は mod_php で任意のプログラムを「容易」に実行できる。容易にshadow ファイルを読めてしまう。

だれでもphpファイルを自由に配置できるってことが多い状況下では

これでは、大変困りますね。安全障壁を1つ減らすのですから。

ハッシュが漏れたら危険なのは、レインボーテーブルの存在です。カンタンなパスワードだと突き止められてしまいます。

ではどうするか。

php でどうしてもやりたいなら php-cgi で setuid ですかね。それか suexec を掛けるしかない。

それか、諦めて、shadowパーミッションをつける。まぁハッシュテーブルだし漏れたとしても。即死レベルの危険じゃないし・・・。

それか、mysql をPAM 化して、 pdo コネクションを作って見る。

それか、true/falseを返すだけのシェルを作る。

php pam で検索すると、Stack overflow などにも pam 使えと気軽な感じに書いてあって、php'er のヤンチャぶりを感じました。

残念。noip 無料DNSが30日毎に confirmation が必須化されたぽい

dyn に続き、 noip も制限がきつくなりました。

30日に一回はログインして confirm をクリックするか、メールで送られてきた、confirmation url にアクセスしないとダメなようだ

詳しくは no-ip の FAQ に youtube動画が貼られている。そこで解説されていた

noip の解説 → https://www.noip.com/support/knowledgebase/confirm-my-hostname-free-account-support-question-day/

どのような手順で更新するのか

メールが送られてきた

f:id:takuya_1st:20160529153718j:plain:w400

クリックすると、課金をurgeされる、課金しないを選ぶ。

f:id:takuya_1st:20160529153737j:plain:w400

re-captcha で not bot だと証明する。

f:id:takuya_1st:20160529153726j:plain:w400

つまり、無料ユーザ追い出しっぽい

無料ユーザは別のところに行けってことらしい。

困りましたねぇ。

買ってるドメイン名でDNSホスティングするにしても、TTL3600の、クソDNSサーバーしか提供されないGM●系とかばっかりだし。

さくらインターネットDNSサーバーか、GoogleDNSホスティング(google domains / google cloud dns ) しかないかなぁ。

クラウド運営するって結局サービス事業者の収益性によるポリシー変更1つで吹き飛ぶんだから、やっぱり過度に依存するのは考えものだわ