< | >

ロリポップからXserverへ、一部移転を検討中
  • (2022-12-16 12:35:11)

どこに行っても不満はあるだろうが・・


ロリポップは長年使ってきたし、不満は多くないもののメールが遅くて移転することを考えている。

Xserverを試すことにした。

有名な割には試したことがないベンダーさんだったので、ここらで調べてみることにした。


バックアップ体制のメリットとリスク


ロリポップからの完全移転ということはないが、一部移転でホスティング業者2社契約になるとバックアップという点で有利になる。

バックアップはいいように見えて実際はシステムを複雑にし、いざというとき役立たない事例は多い。

だからバックアップ体制が必ずしもよいことかどうかは悩みどころではあるが。

幸い「10日間の無料お試し」があるので、とりあえず加入し数日使った。

まずまずだったので1年契約をした。


Xserverの第一印象


どこのレンタルサーバーも大差はないと思うが、細部で違っている部分がある。

その部分が人によってはとっても重要というものがある。

私にとってその重要な細部の一つは「DNS設定」。

ロリポップではできないが、Xserverはできることがわかった。

DNS設定はレジストラでできるので、必ず必要というわけではないが、ロリポップではSPFの設定ができなくて「なんでこれしきの設定をユーザーに解放しないの?」と不満である。

XserverのDNS設定はよい第一印象だった。


Xserverの優位点


まずは1年間契約してバックアップ環境を構築することにした。

とりあえず契約して数日試した範囲で、Xserverの優位点は下記:

・サーバ名 自分で命名できる
・MySQL名 自分で命名できる
・DNSレコード設定ができる
・htaccess htaccessファイルに記述する内容(たとえばキャッシュ設定)のいくつかをパネルから操作可能
・PHPのカバーバージョンが広い PHP5.1.6以上、ロリポップは7以上
・メアドの一括登録ができる(影響大きい)
・使用済みドメイン名を仮セットアップ可能(引越時の準備に役立つ)
・DKIMを設定できる


サーバー配置のポリシー違い


また第一印象で違うなと感じた部分は各種サーバーの分散化のやり方。

まるで違う考え方で新鮮である。

ロリポップではサーバごとに各種サーバーは別々のハードで別けられている:

・POPサーバ
・SMTPサーバ
・メーリングリストサーバ
・FTPサーバ
・MySQLをインストールするサーバ


どちらが有利か?


ロリポップではたとえばメールサーバならメールサーバ専用のハードがあるらしく、ロリポップの全ユーザーのメールがこれらのメール専用のハードで運用されているようだ。

一方、Xserverでは各Webサーバのハードと同じハード上にメールサーバやFTPサーバなどが同居しているようである。

たとえば、ロリポップのWordPressならWordPressからMySQLの接続は違うIPアドレスのサーバにネット経由で接続されるが、Xserverでは接続先のデータベースは「localhost」となっている。

これは同じハード上にデータベースがあるという意味だろう。

Xseverではもし自分のハードがダウンするとWebサイトだけでなく、メールもftpも全部ダメになるのだろう。

ロリポップならWebはダメでもメールは生きているという状況もある。

どっちの形態が有利かはわからない。

立場や優先したい目標によって評価は違ってくると思うが、私個人の場合だと、Xserver形式の方がよい。


Xserver方式のメリット


一つのハードにおおむねすべてのサーバサービスが稼働していた方が、ssh接続でもやれることが多そうな気がすること、また各サーバサービス間の通信がネットワークを経由しないことで理論的に速くなこと(体感差が出るか不明)などと予想する。

自分にとって一番のメリットはメールサーバ。

こういうマンモスサーバベンダーではよからぬスパムメールを流し続ける犯罪者やそれに近い人がたくさん存在する。

そういう人たちと同じメールサーバを使っていると世界的に「悪いIPアドレス」として登録されロックされるケースがある。

そうなるとそのメールサーバを使用している全ての人々のメールの送受信に影響が及ぶ。

数十万人のユーザーが同じメールサーバを使っているであろうロリポップのメールサーバには当然、スパム業者も混じっているだろうし、実際、これが原因と思われる理由でたまに止まることがある。

Xserverならロリポップと比較してかなり少ないだろうし当然リスクも圧倒的に低いことになる。


< | >

お名前.com、スパムメールが少なくなったか?
  • (2022-12-08 06:25:04)
お名前.comさんは発狂したようにスパムメールを会員に送りつけることで有名だったが、このところスパムが少ないようだ。

あの腹黒い人々も少しは改心したのかもしれない。

ビジネス上得策でないと判断したのだろう。

表面的な改心であれスパムが少なくなることは歓迎である。

今年2022年の年末までにすべての契約を解約し、お名前.comとはきれいさっぱり分かれるつもりだったが、スパムが来ないなら、解約手続きも面倒だという気持ちになっている。


< | >

(ロリポップ) ssh接続でスクリプトファイル編集
  • (2022-11-23 11:54:39)

Unix系コマンド


Unix系のコマンドは恐ろしいので触りたくないが、webサイトのあるページをある時刻で自動切替したくて勉強した。

前もって準備している「index.LIVE.html」を、たんに「index.html」へと上書きするだけのスクリプト。


「ssh接続」


う~ん、やりたくなかったが、ロリポップ社の解説ページを見ながら、Win10のDOSモードで接続してみた。ちなみにWin7では接続できなかった。

ssh 「アカウント名」@ssh.lolipop.jp -p 2222

あれ!「Crtl + V」が効かない!

恐ろしく長いパスワードをコピペでできないと痛手である。

→ Win10のコマンドモード画面の「プロパティ」で「Ctrl+Shit+C/Vを使用する」にチェックを入れて、これを試すとなぜだか「Crtl + Shift + V」が効く!

(なぜだ~!)


シェルは何?


Unixのインターフェースは複数種類ある。「シェル」とか言っていたような・・

誤字コマンドなど打つと「-bash:コマンドが見つかりません」みたいなエラーがでるから、ロリポップ・サーバーのシェルは「bash」のようだ。

Linuxはおおむねbashが標準シェルのようである。

昔試したシェルはコマンドを途中まで打つと候補が自動的に提案されていたが、bashにはそれはないみたい・・と検索すると

途中まで記入して「Tab」キーで補完される。

「Tab」連続2回で複数候補を表示。


記憶が残っていた唯一のコマンドは「ls」のみ


bashコマンドは前回いつ触ったか記憶がないくらい。

唯一覚えていたコマンドはファイル表示の「ls」。

自分が今どこのディレクトリーにいるか知りたいが、どうしても思い出せない、調べたら「pwd」だった。

pwd・・普通は「powered」の短縮形に見えるが、これが現在のパス表示のコマンド・・先は遠い。

ssh接続で変なコマンド打ち込んで、サーバーを落としたりしたらと思うと恐ろしい。

当然、危険なコマンドは打てないよう制限されていると思うが、バカというのは想定外の天才的なミスを犯すものなので・・・


おお「vi」!


エディター「vi」を触ったのは前回はいつだったか記憶がない、とにかく使いにくくて変なエディターである。

しかし、Unixが生まれて以来、綿々と提供されているとことを見るとUnix使いには便利なんだろうな、きっと嵐のようなキー入力ができるエディターなんだろうと空想する。

知り合いにUnix使いの人がいたら聞いてみたいが、いないので・・

このviでシェルスクリプトを書くことにした。

「シェルスクリプト」とか言ったって、コピーとか削除とかのコマンドを1~2行書くだけだが。


ジョブスケジューリング・・cron


Windowsには「タスクスケジューラ」があるが、Linuxには?・・「cron」かな?
一回きりの動作なら「at」コマンドがあるらしいが、ロリポップのsshでは動作しなかった。
cronで上の「test.sh」を実行させたい日時にセットした。


Linuxの勉強


---------------
viエディタの勉強
---------------
Unix誕生の時から付属しているデフォルトエディターと思われる。

viコマンド → 編集モードと入力モード,切り替えはESCキー

vi test.sh
ESCキー → モード切替
iキー → 入力コード
Rキー →
yyキー → 1行コピー
xキー → 1文字削除
ddキー → 1行カット

:wq → 保存して終了
:w! → 保存せずに終了


---------------
bashコマンドの勉強
---------------
(たぶん、Unix使いの人々は自分でコマンドを作ちゃうんだよな~
その自由度は自分向きだが、自分にはそういう才能がないので
Unixは自分には敷居が高い)

pwd:カレントディレクトリの表示(何の略か全然空想できない)
ls:ディレクトリ内ファイルの表示
cd:ディレクトリ移動
mkdir/rmdir:ディレクトリの作成・削除
cp:ファイルコピー → cp test1 test2
mv:ファイル名変更 → mv test.txt test.old
rm:ファイル削除 → rm test.old
echo:標準出力
パスの表示:echo $PATH


---------------
ロリポップのbash・・/bin/bash
---------------
https://lolipop.jp/manual/user/ssh/


---------------
シェルスクリプトとバッチファイル
---------------
Windowsにはバッチファイルがあるが、Linuxにはあるのかな?・・
というか、WindowsバッチファイルはUnixがお手本だし、
こういうテキストファイルによる操作やプログラミングは当然あると思う


---------------
シェルスクリプト「test.sh」の中身
---------------
mv (フルパス)/welcome.html (フルパス)/welcome.OLD.html
mv (フルパス)/web/welcome.LIVE.html (フルパス)/welcome.html

※test.shの拡張子「.sh」はなくてもよい
※test.shはあらかじめ「chmod 755 test.sh」のように実行権限を与えておくこと
※(フルパス)で書かないと実行してくれないみたい


---------------
シェルスクリプトの実行
---------------
>test.sh

でエンターしても実行されない!

(なんで~)

>./test.sh

で実行された。

「./」の部分はフルパスでもよい。意味ありげな仕様・・


---------------
パスが面倒、パスの通し方は?
---------------
Windowsはパスを気にしなくてもだいたい通っている。

Unixは明示的に通さないと何も動かない印象。

Unixは個人使用を前提としたWindowsと違って、複数の人々でコンピューターを共同利用することが前提だったのだろう。

セキュリティの考え方が全然違っていて、いちいちパスを通さなくちゃいかんし、実行させるためにもいちいち実行権限を与える必要がある。

Windowsのよう何でも簡単にさくっとやれると、なかにはシステムをダウンさせたり暴走させたりする人もいるわけで、そんな人に対するセキュリティなんだろう。


< | >

ドメイン名の取得リスクと廃止リスク
  • (2022-11-23 10:41:20)

運営していたニッチなドメインの話


数年前の経験だが、あるドメイン名を取得しあるテーマで数十ページを公開していた。

その分野はニッチだったので、そのテーマではGoogleさんの評価も高くそこそこ上位表示だった。

トラフィックは調べたことがないが、まあ、Google検索でトップページに来るので多少あったのだろう。

数年運営して、そして気持ちも冷めて更新しなくなり維持するモチベーションも失われた。


運営実績があるドメインは廃止で第三者に渡る


しばらく放置していたが、ある年の契約関連の棚卸しのときクローズすることにした。

コンテンツはいちおうバックアップしたが、使うあてはなかった。

ところが、おもしろいもので廃止から数ヶ月して、何かのキッカケで「あれは必要だ」と思い直し、同じドメイン名を再取得しようと思い立った。

記憶が定かでないが、廃止からわずか数ヶ月のこと。

他人が使いそうなドメイン名でないし、まさか他人に取られているとは思わなかったが、そのまさかだった。

元マイドメインを見に行くと第三者によるサイトではなかったが、リセール業者のページになっており、ボクのドメインは売り出し中だった・・・ドメインを廃棄すると何が起きるのか、どうなるかを体験した瞬間だった。


昔は和やかだった


実は2000年代の前半、あるドメインを取得したものの使い途がないと廃棄したことがある。

そのドメイン名を数年後、またほしくなり再取得できるか?と調べたら偶然できてしまった。

だから、その時の体験から「ドメイン名は一度放棄しても再取得できる可能性がある」と誤解した。

実際、廃棄されたドメインは人気があるドメイン名でない限り、第三者が失効後即座に取得するという状況は多くなかった。

しかし、何年か運用された中古ドメインの価値がネット上、(どちらかと言えばアンダーグラウンド的な活動をしている人々の間)で認知されるようになると「ビジネスとして」それを狙う層が生まれたのだろう。


ドメイン名が残る媒体


JPRSのドキュメントを参考に書くとこんなものが残る:

 ・検索エンジン

 ・他のWebサイトからのリンク

 ・個人orパブリックなブックマーク

 ・DNS設定

 ・アカウント情報(メールアドレス等)


このうち「DNS設定」に設定が残された場合のリスクが、私には具体的にイメージできない。

通常のレジストラのDNSならドメインが廃止された際、当然、いっしょに設定を消去していると思うけど、しないのかな?

レジストラがドメイン名廃止の際、どんな作業をするのか不明だが、倫理的に考えても設定消去は当然必要なように思うが、されないこともあるのかもしれない。

また個人のDNSサーバだと忘れる人もでてくるだろう。

DNSに設定が残れば、当然、意図しないIPアドレスを通知されるわけだが、実際のそのウソIPアドレスに飛んだところで、通常のレンタルサーバなら共有サーバなので表示のしようがないと思う。


廃止ドメインのリスク


失効したドメインは第三者に取得されて既存トラフィックを利用されるリスクがある。

自分が知っているブランドだと思ってクリックしたら、まったく無関係なブランドが出現したと消費者が感じたとき、どう思われるだろうか。

とくにブランドを大切にしている企業には痛手である。

「あれ、このドメインはもう○○のドメインでないのか」と判断してくれればよいが、混乱を招いたり、場合によってはよくないイメージを消費者に与えかねない。

運が悪い場合、古いトラフィックを利用した悪意あるフィッシングサイトになっているリスクさえある。

こうなるともはや「悪いイメージを与えかねない」レベルでなく、自社の顧客を犯罪にさらすことにもなりかねない。


永続性が薄いドメインでメールアドレスを作らない


廃止しないドメインなどはないだろうが、永続性に自信がないなら、そのドメイン名でメールアドレスを作るべきでない。

メールアドレスは様々なサービスのIDや連絡先として利用されるので、ドメインを廃止すると、それらのサービスも利用できなくなる。

それどころか、廃止後第三者によって取得されると、そのメールアドレスで登録していた様々なサービスにログインされ、アカウントを詐取されるリスクもある。

永続性が弱いのなら、そのドメインでは絶対にメールアドレスを作るべきでない。


ドメイン取得時に決めておく


「いつまで維持するのか?」「いつクローズするのか?」はドメインの取得時に決めておきたい。

ドメインだけでなく、すべてのモノの購入、すべての契約、すべての約束にも当てはまる。

人間の体質として、終わるときのことは考えずに、そのモノが手に入ったときだけのことを考えて行動することが多い。

たとえば、新しい生活のぼんやりしたイメージだけで車や家を買う人は多いし、綿密なプランもなしに投資として不動産を入手する人も多い。

不要であれば、小さなモノならだいたい捨てられるが、不動産となると捨てられないし売るに売れないケースも案外多い。

値上がりや高く転売することを夢見て買った不動産だが、売れないときのことは想定していなかったという素人投資家の事例は実際に案外多いようだ。

そして、本人が亡くなっても遺族の中にも引き取り手がなく相続拒否される土地も多い。

こうなると自分だけでなく遺族にまで迷惑が及ぶことになる。


一過性ドメイン取得のリスク


大企業さんだと新製品やイベントのためだけに新規ドメインを取得するケースがある。

キャンペーンやイベント終了後、どうするのか事前に決めて取得すると思うが、廃止のタイミングや廃止方法まできっちり見通して取得しているだろうか?

(見落としている企業さんも多いのでは?)

ドメインの廃止はブランド名が刻印された印刷物や廃棄物同様、廃棄には気を遣うしコストがかかる。

短期間で廃棄するつもりなら、そもそも新規取得はせず、既存の永続性のあるドメインの下部にそのキャンペーンなどのページを作成した方が有利に思える。


ドメイン取得があまりにも簡単だから・・


ドメイン名の取得は安価でしかも簡単・即座にできる。それに加え現在ではあまりにもドメイン名のバリエーションが増えてしまった。

よいことではあるが、ついつい軽い気持ちで余計なドメイン名までも取得しがちという副作用も大きい。

さらに似たようなドメイン名のバリエーションが量産されるので、ブランド保護のために自社のドメイン名に似たバリエーションを大量に取得する負担も発生している。


不動産のように一度取得したら・・・


ドメインは一度取得したら長期に維持するものを考えるべきである。

そうすると当然、長期に一定の固定費が発生する。

そういう覚悟と経済的耐性を準備して取得すべきである。

自社ドメインに関連するドメインは使わないにしても近似するドメイン名であればある程度取得してバルクで維持することがブランド全体の価値保全となる。

だから、取得するドメイン名はどんどん増えることになる。

ただでさえ、大量のドメイン名を取得・維持しなければならないこの時代、ムダに無用な新規ドメイン名を増やすことは自分から負担と危険を招く結果になりかねない。


ブランド保全のためだけに取得したドメインはこうする


(1) メールアドレスを作らない
(2) トラフィックを生まない
(3) デフォルトでメインドメインに「301レダイレクト」(恒久的的転送)をかける

一言で言えば「誰にも使わせない」措置を取ること。

「ブランド保全のためだけに取得するドメイン」とは第三者が自社のドメイン名に似た、消費者に誤解を与えかねないドメインを取らせないことが第一の目的。

しかし、廃止時を想定して、メールアドレスなどIDになる可能性のものを存在させないようにしたい。

トラフィックもないのならいつ廃止しても、どうしても自社の他の生きているドメインへの影響もない。

そのためには何かコンテンツを置き、かつ他の生きているサイトからリンクなどを張らないようにしたい。







< | >

ownCloud 削除できないファイル
  • (2022-11-19 09:25:43)

起動ごとに毎回エラーメッセージがうっとうしい


1GBくらいの動画を入れたら、なぜかSyncせずエラーメッセージが毎回表示される。

Syncしない原因は不明。

他のファイルは問題ない、違いがあるとすればファイルサイズが大きいとか?・・など空想したがわからない。

マニュアルを読んでみたが、ファイルサイズの制限などに関する部分は探せなかった。


ファイルがロックされている!


とにかく毎回PC起動ごとのエラーメッセージがうっとおしくてこの動画ファイルを削除することにした。

すると・・(エラーメッセージをメモしておけばよかったが、うろおぼえで書けば)

「can not delete」「file lock」みたいな・・

ファイルがロックされているようだ、いや~めんどくさいな。


ロックテーブルを探す


phpMyAdminでMySQLデータベースに入り、テーブルを探すと

「ocXXX_file_locks」

というテーブルがあってこれがくさいとにらんだが、ロックファイルのファイル名はバイナリーになっており、問題のファイルがここに含まれているか不明だった。

念のためネットで人様の記事を検索すると「oc_file_locksが問題」という人が数人いたので、おそらくこのファイルで問題ないだろう、と中身を消すことにした。


ネット民の削除方法:sshターミナル接続


ちなみにネット民の人々はデータベースサーバーにSSHで接続してコマンドベースで操作していた。

いや~ハッカーさんたちはやはり、コンソールでなんでもやりたいし、そっちが早いよね。

コマンドを知らない自分にはphpMyAdminしか手段がない。


phpMyAdminでSQLコマンド投入


phpMyAdminのテーブルの中にあった「ocXXX_file_locks」を表示すると一画面30件表示で300ページくらいある。

つまり、レコードとしては9,000件くらいあるが、GUIではページ単位の削除はできるが、一括削除の方法はない模様。

SQLコマンドですべて消してみた。

SQLコマンドもよく知らないので、恐ろしかった。

(もし失敗したら、ownCloudそのものが使えなくなるかもしれず、ちょっと恐ろしかったが、いちいちバックアップ取ってたら日が暮れる)


SQLコマンド


DELETE FROM `データベース名`.`ocXXX_file_locks`

結果的にすべて削除されたようだ。

あとはownCloudの挙動が変になっていなければいいのだが、ちょっと見た範囲では問題なさそう。

先はわからないが。


どのデータベースがどのサービスに使用されているか?という問題


ちなみに今回の作業は2時間くらいかけて行ったが、最初の半時間はデータベースを探すことに費やされた。

ロリポップのデータベースではデータベース名などの名称に自分のサービスの名称を入れられない。

しかも、自分自身がきちんと記録していなかったので、これがWordpress用なのか、CMS用なのか、ownCloud用なのか、それを探すためにすべてのデータベースにログインしてaccoutやuserやpostテーブルの中身などを見て、どれがどれを推測する作業を行った。

実にムダだった。

記録はしっかり、かつ、どこに記録して、すぐに取り出せるのか、ルールを決めておけ!と思ったものである。

2時間、お疲れ様でした。



search
layout
admin

[▲page top]