< | >

パーミッションで素朴にはまる
  • (2024-03-11 19:00:18)

フォームメールが作動していない!


あるサイトをロリポップからxserverに移行中。その中の一つ、Perlで書かれたフォームメールが作動しないトラブルを体験。スタッフに指摘されて試すと本当に(500 Internal Server error)

こういうときはまずはパーミッションを疑う → メインの実行ファイルは「644」となっていた。ftpで転送するとデフォルト「644」か? デフォルトパーミッションが何であれ「644」に問題を感じなかった・・

今から思うとここで「700」番代を試せばいいのに、ロリポップのときはなぜか「644」で動作していたものだから、xserverでも当然動作すると思い込んでしまった。


思い込みで数時間はまる


パーミッション以外の原因を探しだそうと数時間もはまって疲れ果ててこの日は仕事を終えた。湯船につかっていれば「あれは試していないな~」などというアイデアが湧くだろうと期待していたが、湯船でもアイデアは出なかった。

どうしても作動しない原因がわからない・・今回のトラブルシューティングは切り分けがスマートでなく体力・時間を消費してしまった。


別のフォームメールで切り分け


けっきょくCGIプログラムを広範囲に公開してくれているKen-webさんから「PostMail」(Perlで書かれたフォームメール)をダウンロードして設置するとこれもだめだった・・この時点で、もはやプログラム側でなくサーバ側の問題と確信した。

それで再度xserverのパーミッション指定を調べ直して唖然・・必要な設定は「755」or「705」。

パーミッション「rwx」の実行部分は必ず「7」で始まるべきであると私も思っているのにこのミスは間抜けだった。


パーミッション&サーバーパス指定



【xserver】


https://www.xserver.ne.jp/manual/man_server_permission.php
---------------
・フォルダ 755, 705
・.html/.php/.zipなど 644
・.htaccess 644
・.cgi/.pl などCGI実行ファイル 755, 705
・.cgi/.pl などライブラリ 600
・.txt/.dat/.logなど 600
---------------
・perl (/usr/bin/perl)
・sendmail (/usr/sbin/sendmail)
※xserverには「/local/」フォルダがない


【ロリポップ】


https://lolipop.jp/manual/hp/cgi/
---------------
・ディレクトリ 705
・HTML、画像ファイル 604
・.htaccessファイル 604
・CGIの実行ファイル 700
・CGIのデータファイル 600
---------------
・perl (/usr/local/bin/perl)or(/usr/bin/perl)のいずれか(サーバによって違う)
・sendmail (/usr/lib/sendmail)or(/usr/sbin/sendmail)いずれもOK

< | >

linuxは底なしの海のような
  • (2024-03-07 06:41:55)

世間はWindowsで最適化されている


会社のPCは業務用ソフトが必要でそれらはたいていWindows用。そのためlinuxに移行できない。可能ならWindowsは止めたいが人質が取られており当面無理だろう。

個人用のPCはlinuxに移行できるが、そう思いつつ何年も経過してもまだ実施していない。

私にとってlinuxは敷居が高いし慣れたWindowsは圧倒的に楽だという点で前に進んでいない。


サイトの引っ越しで味わうlinuxの深み


最近あるサイトをロリポップからxserverへ移行した。数千のファイルを移動に関してlinuxのコンソールをたたきながらlinuxの文化に触れlinuxは深いな~と感じた。

ファイルの移動は通常ftpでやっているが、ファイル数が多くなると問題が起きやすい。エラーで転送できないケースも発生しやすい、あと時間がものすごくかかる。

ftpソフトのログを眺めていると通信セッションをオープンしファイル転送を行い転送エラーなどのチェックを行いセッション終了するという一連のプロセスをファイル一つ一つ順次やっているように見える。ものすごくムダだし、またタイムスタンプもズレる可能性もある。

本数が多い転送はファイル群を1本のzipファイルに圧縮して転送し、sshでサーバにログインしunzipコマンドで展開した方が確実だし速いし安全。

sshでサーバにログインすること自体がなんか敷居が高かったが、何回かやっているうちに慣れてきた。

黒いターミナルに向かって「ls」「pwd」「cd」など数個しか知らないlinuxコマンドを叩いているうちに、なんか凄いな~という感情が湧いてきた。

感じるところは・・

・「なんでもテキストコマンドでやっちゃう」「やれちゃう」という点
・それらの組み合わせで無限にいろいろなことができそうな予感


先輩達が築いた文化と伝統


linuxの開発コミュニティがどんな人々か全く知らないが、イメージとしては偉大な先輩達がゴロゴロいて現役の在校生もすごい人たちであふれている有名校のクラブ。

linuxのコマンドやツールはすべてオープンソースで世界中の誰かが手作りでつくってきたものだろう、その蓄積が深い海のように海底に堆積し現在も止まることなく堆積し続けている。

bashという黒いインターフェースが私には海のように見えてくる。この分野の先輩達が1960年代から脈々と積み上げてきたAIのカケラの巨大集積が現在のlinuxだしどこまで進化するのか空想できない。


手は出しにくいが・・


少し勉強してみたいと気持ちがそそられるが、素質がある人間なら適当に遊んでいるうちに自然身につくだろう。

しかし私のような凡庸な適性の人間が学ぶ場合は業務で必要に迫られるなど、強い目的やある程度の強制力・プレッシャーがないと自分の意思ではかなり厳しい。

自分の仕事にlinuxサーバの管理や開発の仕事が含まれるなら勉強するだろうが、とても正面からlinuxに取り組む理由がないしモチベーションがない。接する機会があるときに少しだけ勉強したい。


< | >

匿名メアドの作り方
  • (2024-03-06 15:53:44)

ネット活動に必須のメールアドレス


メールアドレスはインターネット内での活動に多用される緩いレベルの個人ID。すべての事業者や人間が良識ある使い方をしてくれるなら問題ないが悪用する人々も多い。とくにスパムメールのターゲットにされやすい。

商品として永遠に再販売されるメアド


メアドは悪徳業者にいったん収集されると商品として販売される。この商品は劣化しないので永遠に販売が繰り返される。

私はスパムの対象となったメアドを10年前に廃棄し、10年経過して再登録してスパムが再発するかテストをしたことがあるが、量は減ってもスパムは毎日来た。

何らかのサービスでメアド登録が必要な場合で、かつ相手の信用度が不明な場合、汚れても良いメールアドレスで登録したい、そのためのメアド(ここでは「匿名メアド」と呼ぶ)を使いリスクを軽減したい。

第三者フリーメアドの問題点


昔はGmail、Yahooメールのようなフリーアドレスを配布している事業者のメアドを使っていたが、永続性に問題があるし、内容を読まれる・取られるという行為も行われているだろう。それに業者によってはひどいスパムの対象にされる。

永続性に関しては大手のGmail、Yahooメールレベルだとまあ心配ないだろうが、突然サービスを打ち切る事業者もそれなりに多い。

Yahooメールに関してはスパム業者だけでなく本家のYahoo自体から100種類くらいのスパムが送り込まれる。頭が少々おかしいビジネス手法である、孫さんがああいう手法を許すはずがないのだが、どうしたんだろう?・・

Yahooメールに限らず第三者フリーメアドはいずれも問題が多い。サービス運営者側に最終的なコントロールと主権があるからである、51%以上の株式を他者に押さえられた企業と同じ状態といったところか。


匿名メアドの作り方


(1) ドメイン取得+ロリポップ最安値プラン (Web公開ナシ)
(2) ロリポップ最安値プラン (ドメイン取得ナシ、Web公開ナシ)

独自ドメイン取得を取得した方が「永続性」があるし、どこのホスティング業者にも移れるので「汎用性」も高い。しかし1個か2個の匿名メールのためだけにドメインを管理するのも煩わしい。

その点ドメインを取得せずロリポップのドメインのさらにその下のサブドメインによるメアドなら匿名性は高い。

最安プランで契約すればコストも月額100円程度、これを匿名メアド専用にサイトにする。ロリポップのこのプランに加入し続けることが条件となる。

サブドメインなのでWHOIS検索で詳細が出ない、その点も匿名性という点で非常によい。

ロリポップが提供しているドメイン名は下記の通り100個以上で、このそれぞれに好きなサブドメイン名を設定できるので重宝する:


angry.jp
babyblue.jp
babymilk.jp
backdrop.jp
bambina.jp
bitter.jp
blush.jp
boo.jp
boy.jp
boyfriend.jp
but.jp
candypop.jp
capoo.jp
catfood.jp
cheap.jp
chicappa.jp
chillout.jp
chips.jp
chowder.jp
chu.jp
ciao.jp
cocotte.jp
coolblog.jp
cranky.jp
cutegirl.jp
daa.jp
deca.jp
deci.jp
digick.jp
egoism.jp
fakefur.jp
fem.jp
flier.jp
floppy.jp
fool.jp
frenchkiss.jp
girlfriend.jp
girly.jp
gloomy.jp
gonna.jp
greater.jp
hacca.jp
heavy.jp
her.jp
hiho.jp
hippy.jp
holy.jp
hungry.jp
icurus.jp
itigo.jp
jellybean.jp
kikirara.jp
kill.jp
kilo.jp
kuron.jp
littlestar.jp
lolitapunk.jp
lomo.jp
lovepop.jp
lovesick.jp
main.jp
mods.jp
mond.jp
mongolian.jp
moo.jp
namaste.jp
nikita.jp
nobushi.jp
noor.jp
oops.jp
parallel.jp
parasite.jp
pecori.jp
peewee.jp
penne.jp
pepper.jp
perma.jp
pigboat.jp
pinoko.jp
punyu.jp
pupu.jp
pussycat.jp
pya.jp
raindrop.jp
readymade.jp
sadist.jp
schoolbus.jp
secret.jp
staba.jp
stripper.jp
sub.jp
sunnyday.jp
thick.jp
tonkotsu.jp
under.jp
upper.jp
velvet.jp
verse.jp
versus.jp
vivian.jp
watson.jp
weblike.jp
whitesnow.jp
zombie.jp



< | >

SQLite3を試す
  • (2024-02-28 16:09:19)

最強コンビ:Wordpress+MySQL


WebサイトにおけるWordpressの比率は相当高いと思われる。CMS全体では7割くらいのシェアがあるのではないか。そのためWordpressのデータ部分を管理保管するMySQLがすっかりネット空間でのデフォルトデータベースになった印象である。

WordpressもMySQLもよく作り込まれていてひたすら凄いとしか言いようがない、しかも無料、機能的にも経済的にも無敵である。

しかし一般の人々や中小企業のわずか100ページにも満たないようなサイトやブログをWordpressで展開する必要ある?と疑問も感じる。


中小企業には大げさなソリューション


Wordpress+MySQLは、歩けば数分のコンビニにちょっと買い物に行くときのイメージに似ている。近所のコンビニだったらスーツ着て車庫から自動車を引っ張り出し運転するまでもないだろう。普段着のまま行けば車庫から車が出る頃には店に着いている。

数百レコードでも数百万レコードでもサクサク動くMySQLは偉大ではあるが、それだけしっかりした構造体でありセキュリティや汎用性を拡げるクライアント・サーバ型の構造になっている。


軽快ワンファイルのSQLite


一方SQLiteはデータベースを含む単一アプリでクライアント・サーバ型ではない。データベースは単一ファイルでありセキュリティはそのファイルに与えられたパーミッションレベルでしか守られないが、反面、ワンファイルで軽快で簡単というメリットがある。

何を優先したいかは利用者毎の要求や目標によって違うが、SQLite派がもう少し増えても良さそうな気はする。


そもそもデータベース必要?という問題もある


中小企業の100ページ未満レベルのサイトなら本当はデータベースなど入れずにプレインなペラhtmlファイルをゴリゴリ書いていった方が断然早いしメンテナンスも圧倒的に楽だと思う。

データベースがあればそれを理解し管理できるスキルが求められる、これはhtmlファイルを書く能力とは別のスキルなので人材的にも追加の助っ人や契約先が必要になる。

しかし事情によりデータベースを使う必要があるならMySQLよりなるべくSQLiteで行きたいのが私の好み。ということでSQLiteの勉強を少しやってみた。


MySQLとSQLiteの違い


こちらの記事がわかりやすかった → 「SQLiteとMySQLの比較

SQLiteの長所


・サーバーの性能とメモリ要件が低い
・エネルギー消費量が削減できる
・自己充足的でポータブル
・すべてのPHPにデフォルトで含まれている

SQLiteの短所


・複数ユーザー環境やXML形式をサポートしない
・一度に一つの接続しか扱えない
・データベースサイズが大きくなるとパフォーマンスが低下する
・クライアントからデータベースへの問い合わせができない


SQLiteインストール


SQLiteは一つのアプリでコマンドラインツールを含む。ここからは「SQLite入門」で勉強させてもらった内容:

・ダウンロード
sqlite.orgから下記をダウンロード
Precompiled Binaries for Windows → sqlite-tools-win-x64-3450100.zip(4.77 MiB)

・インストール
C:\Users\のどこか適当なところに「sqlite3」のようなフォルダーを作成し上記ファイルを解凍すれば、コマンドラインで使えるようになる(インストール自体不要)

・管理画面の入り方
コマンドラインから「sqlite3」とタイプすると管理画面となる。

・データベースを新規作成
(newdb.sqliteという新規データベースの作成例)
C:\Users\USER\sqlite3>sqlite3 newdb.sqlite

・既存データベースに接続
既存データベースが存在しそれを操作するには接続する
(newdb.sqliteという既存データベースの接続例)
C:\Users\USER\sqlite3>sqlite3 newdb.sqlite

・あとはSQL文を打ち込んでいく


SQLite操作用のアプリ


SQL文を打ち込める人は上のSQLiteコマンドで目的の操作ができるが、慣れていない私のような人には操作用のアプリがある。私が利用させてもらっているアプリは「tksqlite.0.9.25」。

SQLiteやtksqlite・・こんな凄いソフトやアプリを無料で使える幸せを感じている。


< | >

ブログでソースコードの表示方法
  • (2024-02-28 10:45:48)
ブログにhtm/css/php/javascriptなどのソースコードを表示したい場合、普通に書き入れるとコードが実行されて予想外の動作となる。

コード前後を「<pre><code>」&「</code></pre>で囲むとよいと教えてくれている記事が多数ある。

<code></code>タグはソースコードであることを明示するのでコード機能回避に使えることが多いが、このブログでは効かない。

<pre></pre>タグはこのブログでは<br>が追加されているので行間が2倍になるので使えない。

タグ開始&終わりの「<」「>」を日本語全角の「<」「>」にしてみたり。

「&lt;」「&gt;」は効くのだが、いったん記事文を編集するとブログが勝手に「<」「>」に編集するようなのでこちらも使えない。

そこで苦し紛れに「<」を「+」に変更して利用することに。その例がwebページのコピー禁止と解除の方法

search
layout
admin

[▲page top]